Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java: Общие вопросы > Проблема с finalize() и циклическими ссылками


Автор: afiskon 14.11.2011, 08:11
В языке Python есть такая известная проблема. Представьте, что у вас есть два объекта, ссылающиеся друг на друга и имеющие прописанные программистом деструкторы. Пришло время для сборки мусора. Вопрос - какой объект удалить первым? Мы ведь не знаем точно, что происходит в деструкторах. А вдруг он использует ссылку на объект, который мы только что удалили? Python в таких случаях ничего не делает и оставляет объекты в памяти до завершения программы. Решается проблема с помощью weakptr.

Скажите, а что делает Java с в аналогичной ситуации? Да, я знаю, что finalize() - это не деструктор, но все же, согласитесь, что ситуация аналогичная. Может, перед вызовом finalize() всем внешним ссылкам присваивается null?

Автор: Kangaroo 14.11.2011, 09:47
Я думаю, что сначала finalize() вызывается для 2 объектов и только потом они удаляются.

А вообще не надо использовать finalize().

Автор: afiskon 14.11.2011, 09:50
Kangaroo, а нет ли способа узнать более точно? Экспериментальным образом или обратившись к некой документации? А то я небольшой спец по Java.

Автор: Skynin 14.11.2011, 10:04
finalize() настолько не деструктор что проблема такая непонятно откуда возникает. Он может вообще не вызваться за все время работы программы.
2ое - порядок его вызова неопределен. Сборщик мусора при первом освобождении объекта ставит его в очередь
3е - http://blogs.oracle.com/vmrobot/entry/странности_финализации

Цитата

Может, перед вызовом finalize() всем внешним ссылкам присваивается null?

Не может. Сборщик мусора таких не занимается.

Если ваши объекты ссылаются друг на друга да еще почему-то используют finalize(), которому нужны работающие ссылки на другие объекты, то сами и разбирайтесь, зачем так сложно понакрутили?
Можно еще глянуть на фантомные ссылки:
Гугл: Java фантомные ссылки

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)