SoftReference、WeakReference、PhantomReference可用于自定义垃圾收集的过程。它们都扩展了Reference，因此可以将它们混合在单个集合中。硬引用（最常见的）不会扩展 Reference，因此不可能在一个集合中混合硬引用和其他类型的引用。我是对的吗？我们应该将 CustomReference将 Reference 扩展至集合，以实现在单个集合中混合所有类型的对象链接的所需结果 (Collection>)？
更新：因此，在编写 SSCCE 时，我发现无法扩展 Reference 以通常的方式（构造函数是包本地的）。
所以现在的问题更新为：我可以使用单个集合类创建始终保存一些对象（比如10个）的缓存，而其他对象在内存不允许时由GC回收吗？除了为硬引用和软引用提供自定义包装并将它们存储在集合中之外，还有其他方法可以做到这一点吗？
SoftReference, WeakReference, PhantomReference may be used to customize the process of garbage collection. All of them extend Reference<T> therefore it is possible to mix them in single collection. Hard references (most common ones) do no extend Reference<T> therefore it is not possible to mix hard and other types of references in one collection. Am I right and we should put CustomReference<T> extends Reference<T> to the collection in order to achieve the desired result of mixing all types of object links in single collection (Collection<Reference<T>>)?
UPDATE: So when writing SSCCE I've found that it is not possible to extend Reference<T> in a usual way (constructor is package-local).
So the question now updates to the following: can I with single collection class create cache which always holds some objects (say 10) and the others are reclaimed by GC when memory not allows? Is there any other means to do this except providing custom wrappers for hard and soft references and storing them in the collection?
发布评论
评论（2）
不幸的是，根据其 JavaDoc：
因此，您将无法轻松（即没有丑陋的
instanceof+ 转换）处理同一Collection 中的软/弱/幻像引用和普通引用。您可以编写一个包装器，使用两个单独的
Collection对象来处理普通引用和软/弱/幻像引用，或者将它们全部放入相同的CollectionUnfortunately
Reference<T>most not (and can not) be subclassed directly, according to its JavaDoc:As such you won't be able to easily (i.e. without ugly
instanceof+ casting) handle both soft/weak/phantom references and normal references in the sameCollection.You could write a wrapper that either uses two separate
Collectionobjects to handle normal and soft/weak/phantom references or that puts them all into the sameCollection<Object>and uses the appropriateinstanceofchecks with casts to differentiate the objects.当您希望引用的对象保持活动状态直到主机进程内存不足时，您可以使用软引用。在收集器需要释放内存之前，该对象将不符合收集条件。宽松地说，绑定 SoftReference 意味着“固定对象，直到不能再固定为止”。
相比之下，当您不想影响引用对象的生命周期时，请使用WeakReference；您只想对引用的对象进行单独的断言，只要它仍然存在。对象的收集资格不受绑定弱引用的存在的影响。类似从对象实例到相关属性的外部映射（其中只要相关对象处于活动状态就需要记录属性）是 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
You use a SoftReference when you want the referenced object to stay alive until the host process is running low on memory. The object will not be eligible for collection until the collector needs to free memory. Loosely stated, binding a SoftReference means, "Pin the object until you can't anymore."
By contrast, use a WeakReference when you don't want to influence the referenced object's lifetime; you merely want to make a separate assertion about the referenced object, so long as it remains alive. The object's eligibility for collection is not influenced by the presence of bound WeakReferences. Something like a an external mapping from object instance to related property, where the property need only be recorded so long as the related object is alive, is a good use for WeakReferences and WeakHashMap.
The last one -- PhantomReference -- is harder to characterize. Like WeakReference, such a bound PhantomReference exerts no influence on the referenced object's lifetime. But unlike the other reference types, one can't even dereference a PhantomReference. In a sense, it doesn't point to the thing it points to, as far as callers can tell. It merely allows one to associate some related data with the referenced object -- data that can later be inspected and acted upon when the PhantomReference gets queued in its related ReferenceQueue. Normally one derives a type from PhantomReference and includes some additional data in that derived type. Unfortunately, there's some downcasting involved to make use of such a derived type.
more info in this link
http://download.oracle.com/javase/7/docs/api/java/lang/ref/package-summary.html
Added one more link
http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html