Как делает Сборку "мусора" в работе Java?
Я задавался вопросом, как сборщик "мусора" в Java имеет дело со следующей ситуацией.
Объект A имеет ссылку для Возражения B, и Объект B имеет ссылку для Возражения C. Основная программа имеет ссылку для Возражения A. Таким образом, можно использовать Объект B Объект канавки A и Объект C Объект канавки B Объект канавки A.
Что, оказывается, Возражает B и Объекту C, если ссылка между Объектом A и Объектом B устанавливается в NULL?
Должен Возразить B и Объекту C теперь собранный Сборщиком "мусора"? Я подразумеваю, что существует все еще соединение между Объектом B и Объектом C.
9 ответов
Должны ли теперь объекты B и C собираться сборщиком мусора?
Да. Что ж, они являются кандидатами на сбор, потому что нет способа добраться до объектов B и C через корень A.
Да, B и C имеют право на сборку мусора, если к ним нельзя получить доступ из какого-либо корня GC (корни GC обычно - это все потоки и все ссылки в стеке).
Я думаю, что логика другая. Если объект недоступен из потока, его можно собрать.
Вы не можете рассчитывать на то, что сборщик мусора сработает в определенное время, поскольку его поведение непредсказуемо, все, что вы можете сказать, это то, что объекты B и C подходят только для сборки мусора
Как обычно, эту статью необходимо прочитать всем, кто хочет понять, что делает сборка мусора. Он хорошо написан и имеет пояснительные рисунки.
На самом деле, сборка мусора в java - очень сложная вещь, гораздо более сложная, чем, например, в интерпретаторе Ruby.
Так или иначе, теоретическая основа та же.
Сборщик мусора определяет графы объектов, которые больше не достижимы для программного кода (то есть на них больше нет ссылок в активном коде). Говоря о графах объектов, я говорю именно о графах объектов B-> C. как только он становится недоступным, его можно использовать для сборки мусора, но вы не можете сказать, когда это произойдет, поскольку сборщик мусора пытается максимально оптимизировать свою работу, чтобы избежать замедления работы приложения.
B и C подходят для сборки мусора, потому что вы больше не можете получить к ним доступ. Учитывая непредсказуемость сборщика мусора, все, что мы знаем, это то, что они, скорее всего, будут собраны в какой-то момент в будущем.
Если нет ссылки на объект, то для ГК будет целесообразно продолжить
B не имеет ссылки на него, поэтому сначала он будет собран сборщиком мусора, затем он поймет, что C не имеет ссылки на него, поэтому C будет сборщиком мусора . Это для иллюстрации, Jvm достаточно умен, чтобы собрать их одним махом.