Soft reference objects,which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches.
Suppose that the garbage collector determines at a certain point in time that an object is softly reachable. At that time it may choose to clear atomically all soft references to that object and all soft references to any other softly-reachable objects from which that object is reachable through a chain of strong references. At the same time or at some later time it will enqueue those newly-cleared soft references that are registered with reference queues.
All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError. Otherwise no constraints are placed upon the time at which a soft reference will be cleared or the order in which a set of such references to different objects will be cleared. Virtual machine implementations are,however,encouraged to bias against clearing recently-created or recently-used soft references.
Direct instances of this class may be used to implement simple caches; this class or derived subclasses may also be used in larger data structures to implement more sophisticated caches. As long as the referent of a soft reference is strongly reachable,that is,is actually in use,the soft reference will not be cleared. Thus a sophisticated cache can,for example,prevent its most recently used entries from being discarded by keeping strong referents to those entries,leaving the remaining entries to be discarded at the discretion of the garbage collector.
In practice,soft references are inefficient for caching. The runtime doesn't have enough information on which references to clear and which to keep. Most fatally,it doesn't know what to do when given the choice between clearing a soft reference and growing the heap.
The lack of information on the value to your application of each reference limits the usefulness of soft references. References that are cleared too early cause unnecessary work; those that are cleared too late waste memory.
下面测试代码是在JVM的新开的线程中，使用一个map对象将内存耗尽，从而触发GC，回收软可及对象。
publicclassReferenceTestUtil{
/**
* 消耗大量内存
*/
publicstaticvoiddrainMemory(){
new Thread() {
publicvoidrun(){
Map<String,String> map =
new HashMap<String,String>();
Weak reference objects,which do not prevent their referents from being made finalizable,finalized,and then reclaimed. Weak references are most often used to implement canonicalizing mappings.
Suppose that the garbage collector determines at a certain point in time that an object is weakly reachable. At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references. At the same time it will declare all of the formerly weakly-reachable objects to be finalizable. At the same time or at some later time it will enqueue those newly-cleared weak references that are registered with reference queues.
Phantom reference objects,which are enqueued after the collector determines that their referents may otherwise be reclaimed.
Phantom references are most often used for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism.
If the garbage collector determines at a certain point in time that the referent of a phantom reference is phantom reachable,then at that time or at some later time it will enqueue the reference.
In order to ensure that a reclaimable object remains so,the referent of a phantom reference may not be retrieved:
The get method of a phantom reference always returns null.
Unlike soft and weak references,phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable.
