Цитата(AntonSaburov @ 18.5.2009, 13:14  ) |
| Судя по документации - должен собрать. |
Можно ссылочку? Или в двух словах, что там написано?
Вроде как там написано, что если на объект существует хоть одна ссылка, то он будет жить.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Соберет ли GC такие объекты? |
| Автор: SID_M 18.5.2009, 13:12 |
| Предположим есть два объекта, в них есть кросс-ссылки друг на друга, больше ссылок нигде нет. Соберет ли Сборщик Мусора такие объекты? |
| Автор: AntonSaburov 18.5.2009, 13:14 |
| Судя по документации - должен собрать. |
| Автор: SID_M 18.5.2009, 13:22 | ||
Можно ссылочку? Или в двух словах, что там написано? Вроде как там написано, что если на объект существует хоть одна ссылка, то он будет жить. |
| Автор: Се ля ви 18.5.2009, 13:45 |
| Естественно, соберёт - JVM не дураки писали. Если бы не собирал - зачем тогда GC вообще был бы нужен? Грубо говоря, практически у любого объекта есть какое-нибудь String-поле, а это - отдельный объект, ссылка на который располагается в исконном объекте. Это означает, что если бы эта конструкция не собиралось - практически ничего вообще бы не собиралось вообще. |
| Автор: Fieral 18.5.2009, 14:11 | ||
Это не аргумент  |
| Автор: SID_M 18.5.2009, 14:29 | ||
Ну пусть и не дураки. И приведенный пример:
не подходит под описание. В этом случае Строка содержит ссылку на Объект, к которому она принадлежит, однако у Объекта ссылки никуда не будет. Поэтому естественно предположить, что ветка дерева отсыхает. Тут вопрос чуток сложнее, если у объектов ссылки друг-на-друга. Очевидно, что это тоже отсохшая ветка дерева, однако это зависимость может быть транзитивной. Т.е. кольцо в графе будет не элементарное. И всё-равно вопрос остался. Есть ли кусочек в документации, который сказал бы, что соберет? P.S. Интуитивно понятно, что должно собраться. |
| Автор: Fieral 18.5.2009, 14:45 |
| Ну я думаю что сборщик мусора имеет список всех объектов, берёт i-й элемент этого списка и начинает ходить по всем ссылкам рекурсивно раскрашивая объекты в "i-й" цвет. Потом смотрит какие цвета отличаются от цвета стартовавшего класса (который с методом "main(args[])") и их стирает. |
| Автор: SID_M 18.5.2009, 14:49 |
| А я думаю, что вообще там строится граф и по теории графов ищутся несвязные подграфы и т.д. Но это всё наши с Вами догадки. А хотелось бы знать, как думали разработчики Java API и GC в частности. Рою документацию, кто чего узнает, пишите  |
| Автор: Fieral 18.5.2009, 14:54 |
Да собсно это "она" (теория графов) и есть: |
| Автор: LSD 18.5.2009, 15:45 | ||
Softly, weakly и phantom reachable объекты могут быть собраны сборщиком мусора. |
| Автор: SID_M 18.5.2009, 16:48 |
| О! Lsd справедливо заслужил [+]. Который с радостью ему и вручаю. А теперь хотелось бы немного обсудить. А то ихние буржуйские термины до меня немного не доходят. Получается, что Strongly reachable объекты - это те, которые только что созданы, и по сути ссылок на них еще ни у кого нет, кроме Thread-a в котором они созданы. Softly reachable объекты - это те, которые не Strongly reachable, но можно найти по ссылкам. Тут интересный момент - это же подавляющее большинство объектов рабочей программы. И если они могут быть собраны Сборщиком Мусора, то это же "В корни не верно" ((с) дядюшка ленин). Weakly reachable бъекты - это те, которые ни одни из вышеперечисленных, но их можно получить с помощью прохода по weak отношениям (ссылкам). Когда weak ссылки на weak-reachable объекты обнуляются, то объект становится пригодным к финализации. (А раньше он таковым не был?) Тут непонятно, что это за "слабые" ссылки и чем они существенно отличаются от "легких", описаных в предыдущем пункте? Ну дальше не интересно... Попросим Многоуважаемого Lsd прокомментировать.  |
| Автор: Skynin 18.5.2009, 20:48 |
| Соберет, потому что GC убивает недоступные объекты. Очень грубо: Строит дерево доступных, сверяет с ссылками на выделенную память и помечает недоступные (то есть вне списка) Такой же грубый пример сбора доступных объектов: 1. Начинаем просмотр с статических объектов, в объектах ищем ссылки-поля. 2. Просматриваем ссылки в стеке main'а, по ним также исследуем получаем ссылки на объекты 3. Смотрим стеки вызовов методов в потоках, собирая ссылки оттуда. Сверяем полученный список с списком ссылок под которые выделена память. Если нет в списке - освобождаем память. Таким образом GC просто не заметит что есть ссылки друг на друга. Он не проверяет ссылки которыми владеет недоступный объект. Ибо - незачем. P.S. Weak ссылки и вызов финализаторов - просто нюансы процесса сбора ссылок. |
| Автор: Се ля ви 18.5.2009, 20:49 | ||
Согласен, не удачный пример. Но в общем. я хотел сказать, что такие ситуации - обычное дело при программировании и возникают часто, хотя я сейчас и затрудняюсь привести пример. |
| Автор: NightmareZ 18.5.2009, 21:01 | ||
Двусвязный список. Обрезаем ему хвост - получаем висящие в памяти объекты и ссылающиеся друг на друга, на которые ссылок из программы не будет. |
| Автор: SID_M 19.5.2009, 06:33 |
| Skynin, лови [+]. Ну, более-менее разобрались. Считаю тему исерпанной и как таковую закрываю. Спасибо всем, кто участвовал в дискуссии. |
| Автор: LSD 19.5.2009, 11:10 | ||||
Strongly reachable это объекты которые только созданы, т.е. такие для конструктор еще не отработал или уже отработал но еще не произошло присваивание. Т.е. это гарантирует, что
объект не будет убран сборщиком мусора пока не произойдет присваивание. Плюс strongly reachable это любой объект на который есть ссылка из другого strongly reachable объекта. |