Предположим, что существует объект a класса A, который содержит ссылку на другой объект b класса B. И это единственная ссылка на b. Итак, если все ссылки на a удалены, то a готов к GC. Означает ли это, что b также готов собирать мусор? потому что, хотя b имеет ссылку (внутри a), она недоступна, потому что a недоступна.Является ли объект мусором, если он ссылается только на мусор?
Как работает этот сценарий? Я имею в виду порядок сбора мусора.
Как только объект недоступен из корня, он будет собран. См. this question для объяснения корней GC.
Все подграфы будут собраны (как вы описали), предполагая, что ни один узел внутри этого подграфа не может быть достигнут.
Java (и .NET) использует mark и sweep сбор мусора, который имеет дело с этой проблемой.
Системы с подсчетом ссылок (например,) могут не работать в случае круговых зависимостей, которые остаются недоступными. Это не проблема для Java/.NET GC.
+1 Я не вижу причин для понижения голосов здесь. –
Если есть один downvoter, который нисходит вниз, то есть другие люди, такие как я, которые поддерживают хороший ответ :) –
Java GC достаточно умен, чтобы собирать острова изолированных объектов, хотя они могут указывать друг на друга. Следовательно, b также получает право на сбор мусора. Здесь следует отметить, что, хотя у вас есть ссылка на b, это не в прямом эфире в том смысле, что он не может быть достигнут из корня вашей программы.
Это хорошее или круговое обращение (A имеет ссылку на B и B на A) никогда не могло быть собранные, но также могут быть недоступны –
Почему голос? –
Кажется, что somesones пускают в ход большое количество хороших ответов в этом вопросе. Некоторые люди такие же, как –
Это зависит от GC. JVM может быть сказано использовать разные GC и обычно использует 3 GC как один (eden, copy, markcompact).
В любом типичном GC и в refcounting ситуации вы Описанная обрабатываются чисто, как OBJS собраны. Подумайте об этом в 2 этапа: сначала «a» получает замеченный и собранный, тогда «b» замечается и собирается. Опять же: конкретные средства уведомления зависят от GC.
Это мой опыт, что refcounting терпит неудачу, если у вас есть круглые ссылки.То есть, если A-> B и B-> A, оба имеют счет одного, но не достижимы. –
Нет ссылки с "b" на "a" в описании OP. –
Правда, но если я не ошибаюсь, ваш ответ не делал этого акцента перед вашим редактированием. Во всяком случае, GC - это огромная тема, по которой OP, по-видимому, нова, и мы можем уйти от вступительных аспектов :) –
Это точно точка GC. Поскольку b недоступен из основного потока, это будет сбор мусора. Дело не только в графе.
Даже если объекты ссылаются друг на друга и у них нет доступной ссылки из программы, они будут иметь право на GC. Существует хорошее объяснение с диаграммами здесь
http://www.thejavageek.com/2013/06/22/how-do-objects-become-eligible-for-garbage-collection/
возможно дубликат [Garbage Collection в Java и Циклические ссылки] (http://stackoverflow.com/questions/1910194/garbage-collection-in-java-and -circular-references) – delnan
Лучше подумать о сборщике мусора, выяснив, что ** не ** подходит для сбора мусора и сбора остального. Если это видно из корня, то это не приемлемо –