Предположим есть два объекта, в них есть кросс-ссылки друг на друга, больше ссылок нигде нет. Соберет ли Сборщик Мусора такие объекты?

Судя по документации - должен собрать.

Можно ссылочку? Или в двух словах, что там написано?

Вроде как там написано, что если на объект существует хоть одна ссылка, то он будет жить.

Естественно, соберёт - JVM не дураки писали. Если бы не собирал - зачем тогда GC вообще был бы нужен? Грубо говоря, практически у любого объекта есть какое-нибудь String-поле, а это - отдельный объект, ссылка на который располагается в исконном объекте. Это означает, что если бы эта конструкция не собиралось - практически ничего вообще бы не собиралось вообще.

Это не аргумент   

Ну пусть и не дураки. И приведенный пример: 

не подходит под описание. В этом случае Строка содержит ссылку на Объект, к которому она принадлежит, однако у Объекта ссылки никуда не будет. Поэтому естественно предположить, что ветка дерева отсыхает. 

Тут вопрос чуток сложнее, если у объектов ссылки друг-на-друга. Очевидно, что это тоже отсохшая ветка дерева, однако это зависимость может быть транзитивной. Т.е. кольцо в графе будет не элементарное.

И всё-равно вопрос остался. Есть ли кусочек в документации, который сказал бы, что соберет?

P.S. Интуитивно понятно, что должно собраться.


Это сообщение отредактировал(а) SID_M - 18.5.2009, 14:30

Ну я думаю что сборщик мусора имеет список всех объектов,
берёт i-й элемент этого списка и начинает ходить по всем ссылкам рекурсивно раскрашивая объекты в "i-й" цвет.
Потом смотрит какие цвета отличаются от цвета  стартовавшего класса (который с методом "main(args[])") и их стирает.

А я думаю, что вообще там строится граф и по теории графов ищутся несвязные подграфы и т.д.

Но это всё наши с Вами догадки. А хотелось бы знать, как думали разработчики Java API и GC в частности. 

Рою документацию, кто чего узнает, пишите 

Да собсно это "она" (теория графов) и есть:

Softly, weakly и phantom reachable объекты могут быть собраны сборщиком мусора.

О! Lsd справедливо заслужил [+]. Который с радостью ему и вручаю.

А теперь хотелось бы немного обсудить. А то ихние буржуйские термины до меня немного не доходят. 

Получается, что Strongly reachable объекты - это те, которые только что созданы, и по сути ссылок на них еще ни у кого нет, кроме Thread-a в котором они созданы.

Softly reachable объекты - это те, которые не Strongly reachable, но можно найти по ссылкам. 
Тут интересный момент - это же подавляющее большинство объектов рабочей программы. И если они могут быть собраны Сборщиком Мусора, то это же "В корни не верно" ((с) дядюшка ленин). 

Weakly reachable бъекты - это те, которые ни одни из вышеперечисленных, но их можно получить с помощью прохода по weak отношениям (ссылкам). Когда weak ссылки на weak-reachable объекты обнуляются, то объект становится пригодным к финализации. (А раньше он таковым не был?)
Тут непонятно, что это за "слабые" ссылки и чем они существенно отличаются от "легких", описаных в предыдущем пункте? 

Ну дальше не интересно...

Попросим Многоуважаемого Lsd прокомментировать.   

Соберет, потому что GC убивает недоступные объекты.
Очень грубо:
Строит дерево доступных, сверяет с ссылками на выделенную память и помечает недоступные (то есть вне списка)

Такой же грубый пример сбора доступных объектов:
1. Начинаем просмотр с статических объектов, в объектах ищем ссылки-поля.
2. Просматриваем ссылки в стеке main'а, по ним также исследуем получаем ссылки на объекты
3. Смотрим стеки вызовов методов в потоках, собирая ссылки оттуда.

Сверяем полученный список с списком ссылок под которые выделена память.
Если нет в списке - освобождаем память.

Таким образом GC просто не заметит что есть ссылки друг на друга. Он не проверяет ссылки которыми владеет недоступный объект. Ибо - незачем.

P.S. 
Weak ссылки и вызов финализаторов - просто нюансы процесса сбора ссылок.

Это сообщение отредактировал(а) Skynin - 18.5.2009, 20:49

Согласен, не удачный пример. Но в общем. я хотел сказать, что такие ситуации - обычное дело при программировании и возникают часто, хотя я сейчас и затрудняюсь привести пример.

Двусвязный список. Обрезаем ему хвост - получаем висящие в памяти объекты и ссылающиеся друг на друга, на которые ссылок из программы не будет.

Skynin, лови [+].
Ну, более-менее разобрались. Считаю тему исерпанной и как таковую закрываю.

Спасибо всем, кто участвовал в дискуссии.