Смешивание разных типов ссылок в одной коллекции - PullRequest
Новая
       37

Смешивание разных типов ссылок в одной коллекции

1 голос
/ 24 июня 2011

SoftReference, WeakReference, PhantomReference могут использоваться для настройки процесса сбора мусора. Все они распространяются Reference<T>, поэтому их можно смешивать в одну коллекцию. Жесткие ссылки (наиболее распространенные) не расширяются Reference<T>, поэтому невозможно объединить жесткие и другие типы ссылок в одну коллекцию. Прав ли я, и мы должны поместить CustomReference<T> extends Reference<T> в коллекцию, чтобы достичь желаемого результата смешивания всех типов ссылок на объекты в одной коллекции (Collection<Reference<T>>)?

ОБНОВЛЕНИЕ: Поэтому при написании SSCCE я обнаружил, что невозможно расширить Reference<T> обычным способом (конструктор является локальным для пакета).

Таким образом, теперь вопрос обновляется следующим образом: могу ли я с помощью single class collection создать кеш, который всегда содержит некоторые объекты (скажем, 10), а другие возвращаются GC, когда память не позволяет? Существуют ли другие способы сделать это, кроме предоставления пользовательских оберток для жестких и мягких ссылок и сохранения их в коллекции?

Ответы [ 2 ]

2 голосов
/ 24 июня 2011

К сожалению Reference<T> большинство не может (и не может) быть разделено на подклассы напрямую, согласно его JavaDoc :

Поскольку эталонные объекты реализованы в тесном сотрудничестве с сборщиком мусора, этот класс не может быть напрямую разделен на подклассы.

Таким образом, вы не сможете легко (т.е. без уродливого instanceof + приведения) обрабатывать мягкие / слабые / фантомные ссылки и нормальные ссылки в одном и том же Collection.

Вы могли бы написать оболочку, которая либо использует два отдельных Collection объекта для обработки обычных и мягких / слабых / фантомных ссылок или , которые помещают их все в один Collection<Object> и использует соответствующие instanceof проверки с приведением типов для дифференциации объектов.

2 голосов
/ 24 июня 2011

Вы используете SoftReference , когда хотите, чтобы указанный объект оставался в живых до тех пор, пока процесс хоста не исчерпает память. Объект не будет пригоден для сбора, пока сборщику не понадобится освободить память. Проще говоря, привязка SoftReference означает «Закрепить объект, пока вы больше не сможете».

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

Последний - PhantomReference - сложнее охарактеризовать. Как и WeakReference, такая привязка PhantomReference не оказывает влияния на время жизни ссылочного объекта. Но в отличие от других ссылочных типов, невозможно даже разыменовать PhantomReference. В некотором смысле, это не указывает на то, на что он указывает, насколько звонящие могут сказать. Он просто позволяет связать некоторые связанные данные со ссылочным объектом - данные, которые впоследствии могут быть проверены и обработаны, когда PhantomReference ставится в очередь в связанном ReferenceQueue. Обычно каждый получает тип из PhantomReference и включает некоторые дополнительные данные в этот производный тип. К сожалению, для использования такого производного типа требуется некоторое уныние.

больше информации в этой ссылке

http://download.oracle.com/javase/7/docs/api/java/lang/ref/package-summary.html

Добавлена ​​еще одна ссылка http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html

...