Нужно ли мне сохранять сильную ссылку на WeakReference, которая используется только для выполнения финализации?

Я хотел бы использовать WeakReference в качестве более эффективного метода finalize () с целью освобождения собственных ресурсов, связанных с объектом, как только это станет возможным, без использования финализации (что имеет значительно более высокие затраты, чем использование WeakReference).

Поскольку это единственная цель WeakReference (я никогда не буду использовать WeakReference для получения объекта, на который указывает ссылка), кажется бесполезным тратить время и пространство на ведение списка моих WeakReferences, чтобы предотвратить их сборку мусора.

Но если создается нормальный объект, и на него не сохраняется сильная ссылка, он просто будет освобожден сборщиком мусора, и я не могу найти в документации Javadoc ничего, что предполагало бы, что это другое для WeakReference.

Необходимо ли сохранять ссылку на WeakReference, чтобы предотвратить его сборку мусора, или, если он будет помещен в очередь в ReferenceQueue, будет ли это поддерживать его до тех пор, пока он не будет собран из очереди?


person Theodore Murdock    schedule 20.08.2015    source источник
comment
Я бы хотел использовать WeakReference как более эффективный метод finalize () Подождите, как?   -  person Sotirios Delimanolis    schedule 20.08.2015
comment
@SotiriosDelimanolis Это включает в себя наличие потока, выделенного для очистки вашего псевдо-финализатора WeakReferences, и сохранение собственных ресурсов не в псевдо-финализируемом классе, а вместо этого в объекте WeakReference. Псевдо-финализируемый класс хранит ссылку на WeakReference, который содержит его собственные ресурсы. Когда оказывается, что на псевдо-финализируемый класс имеется только слабая ссылка, WeakReference помещается в очередь в ReferenceQueue, которую вы указываете при построении WeakReference. Ваш поток очистки берет из ReferenceQueue и предлагает вашему WeakReference выполнить очистку.   -  person Theodore Murdock    schedule 20.08.2015
comment
Это не дешевле с точки зрения времени разработки, но может быть с точки зрения производительности, если глобальная блокировка, используемая при подсчете финализируемых объектов, становится узким местом, и может помочь, если JVM становится особенно ленив при сборе ваших финализируемых объектов, что приводит к чрезмерному удержанию памяти.   -  person Theodore Murdock    schedule 20.08.2015
comment
Я все еще не понимаю. Ваша очередь будет содержать только ссылку на объект WeakReference. Как можно очистить исходную обернутую мишень?   -  person Sotirios Delimanolis    schedule 20.08.2015
comment
Вопрос не имеет смысла. Если у вас нет сильной ссылки на слабую ссылку, у вас тоже нет слабой ссылки. Или вы спрашиваете между сильной ссылкой и слабой ссылкой слабой ссылкой?   -  person user207421    schedule 21.08.2015
comment
@EJP Нет, создание и хранение сильной ссылки, которую я использую только в качестве флага для предотвращения сборки мусора, кажется такой пустой тратой времени, поэтому мне интересно, действительно ли это необходимо.   -  person Theodore Murdock    schedule 21.08.2015
comment
@SotiriosDelimanolis Вы храните информацию, необходимую для очистки ваших собственных данных, подключений к базе данных и т. Д. В своем подтипе WeakReference, так что вам не нужно ничего, кроме самого объекта WeakReference, чтобы выполнить очистку. Если эти данные изменяются в течение времени существования вашего реального объекта, то реальный объект, который используют потребители, становится чем-то вроде прокси-сервера, хранящего свои собственные данные через другой объект, который является WeakReference для самого себя. Когда реальный объект становится недоступным, WeakReference с высвобождаемыми ресурсами добавляется в указанную вами очередь.   -  person Theodore Murdock    schedule 21.08.2015


Ответы (1)


Необходимо ли хранить ссылку на WeakReference, чтобы предотвратить сборку мусора?

Взгляните на java.lang.ref описание пакета, целый абзац посвящен ответу на ваш вопрос:

Связь между зарегистрированным ссылочным объектом и его очередью односторонняя. То есть очередь не отслеживает ссылки, которые в ней зарегистрированы. Если зарегистрированная ссылка сама становится недоступной, она никогда не будет помещена в очередь. Программа, использующая ссылочные объекты, несет ответственность за то, чтобы объекты оставались доступными до тех пор, пока программа заинтересована в их референтах.

person the8472    schedule 20.08.2015