references to that object. Then, during the next GC cycle, the indefinite reference object will
get freed. In the worst case, that reference queue will not be processed immediately, and
there can be many GC cycles before everything is cleaned up. Even in the best case, though,
the indefinite reference has to go through two GC cycles before it is freed.
Depending on the type of indefinite reference, there are some important variations to this
general algorithm, but all indefinite references have this penalty to some degree.
GC LOGS AND REFERENCE HANDLING
When running an application that uses a lot of indefinite references, consider adding the -
XX:+PrintReferenceGC flag (which is false by default). This allows you to see how much time
is spent processing those references:
[GC[SoftReference, 0 refs, 0.0000060 secs]
[WeakReference, 238425 refs, 0.0236510 secs]
[FinalReference, 4 refs, 0.0000160 secs]
[PhantomReference, 0 refs, 0.0000010 secs]
[JNI Weak Reference, 0.0000020 secs]
271630K->17566K(1004928K), 0.0797140 secs]
[Times: user=0.16 sys=0.01, real=0.08 secs]
In this case, the use of 238,425 weak references added 23 ms to the young collection.
Soft references are used when the object in question has a good chance of being reused in the
future, but you want to let the garbage collector reclaim the object if it hasn't been used very
recently (a calculation that also takes into consideration how much memory the heap has
available). Soft references are essentially one large, least recently used (LRU) object pool.
The key to getting good performance from them is to make sure that they are cleared on a
Here is an example. The stock servlet can set up a global cache of stock histories keyed by
their symbol (or symbol and date). When a request comes in for the stock history of TPKS
from 6/1/13 to 8/31/13, the cache can be consulted to see if the result from a similar request
is already there.