There are basically four different degrees of reference
- Strong Reference
- Weak Reference
- Soft reference
- Phantom Reference
Lets discuss about the four in detail.
Strong Reference
Strong Reference are the one which is you see everyday in your code , an example below.
StringBuilder sb= new StringBuilder();
The above creates a new StringBuilder and stores the strong reference in variable "sb".The most significant part is what makes them strong, that can be determined how they interact with garbage collector. If the object is reachable via a chain of strong references then those objects are not eligible for garbage collection. This are objects that you are currently working on and this is what is needed. So strong references are the references of the objects which are forced to remain in memory.
Weak Reference
The Weak reference are reference of the objects which are almost useless and are eligible for clean up. So the reference which are not strong enough to force an object to be in memory. This allows you to leverage the garbage collector ability to determine the reachability. We can use the "WeakHashMap" , the WeakHashMap is just like the HashMap but the keys in the WeakHashMap uses weak reference. If the Key is no longer used then the entry is removed automatically.
Soft Reference
The Soft Reference are just the same as Weak Reference but they are not eager to release the object as the Weak Reference does. The Objects which with soft references will stick around in the memory for a while. They remain in memory as long as memory is available for expansion.
Phantom Reference
Phantom reference completely different from weak and soft references. The hold on the object is so tenuous that the object cannot be retrieved. The get method on the reference always returns null.The Phantom reference are enqueued only when the object is removed from memory. The advantages of using phantom reference , one it allows you to determine when the object was exactly removed from the memory. second to avoid the fundamental problem with finalization. Finalize() methods can "resurrect" objects by creating new strong references to them. So what, you say? Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the (slim, but unfortunately real) possibility that the object was "resurrected" during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can get OutOfMemoryErrors even when most of the heap is garbage.
Nice post Sachi! Would like to discuss a bit more on the Soft Reference.
ReplyDeleteDoes GC hold on to the softly referenced objects until heap memory is about to go out, even in Client JRE? If it does, then I think soft references are inefficient for mobile clients where the heap is limited.
Any idea in which order does GC clear the softly referenced objects? Is it based of Principle of locality or FIFO?
Hi Debaprio,
ReplyDeleteIn java there is a global clock variable that is set with the current time (in millis) every time a garbage collection occurs. Every SoftReference has a timestamp field that is set to the current value of clock when it is accessed (when it is constructed or the get()) method is called. This gives a very coarse ordering over the SoftReferences; the timestamp indicates the last GC before they were accessed.
When a garbage collection occurs, the decision to clear a SoftReference is based on two factors:
a.How old the reference's timestamp is
b.How much free space there is in memory.
The decision is made on the calculation of interval <= free_heap * ms_per_mb.
1.free_heap is the amount of free heap space in MB,
2.interval is the time between the last GC's clock and the timestamp of the ref we are currently examining, and
3.ms_per_mb is a constant number of milliseconds to keep around a SoftReference for each free megabyte in the heap
Well the underlying data structure used by SoftReference is a queue . The GC Polls the queue to see if a reference object is available. If one is available without further delay then it is removed from the queue and returned. Otherwise this method immediately returns null .The next reference object in this queue, are blocked until either one objects becomes available or the given timeout period expires.
Hope this answers your question. Happy learning !!
Thanks Sachi for the insight.
ReplyDeleteOkay so it seems that "SoftRefLRUPolicyMSPerMB" flag can be used to manage the softly referenced memory in Java. Lesser the value of this flag, faster the soft references get cleared. I think it might be tricky to determine an optimum value for this flag.
Android provides an interesting alternative for caching using soft references in order to tackle this shortcoming. Its called 'android.util.LruCache'. Its based on Least Recently Used algorithm.