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.
