Skip to content


August 18, 2008

thread safety: any shared data being accessed makings  the method non thread safe ( Includes the param being sent to the method as well).

weak references to hold its keys, making it one of the few classes able to respond to the fluctuating memory requirements of the JVM.

GC when the — deregisterObject() method is not called, but the registered object is no longer referenced anywhere in the application, except by our internal Map.

the elements of a WeakHashMap cache could be cleared at any time by the JVM, and there is no selectivity

From the forum:

Moderate home helping habits but will not do all.
Religion – how often – what worship?

The only difference that I know between soft references and weak references is that weak references are guaranteed to be garbage collected, however soft references would be garbage collected only if JVM is running out of memory.

Phantom references are objects on which finalize method has been run. So finalize method does not run on phantom references. Now when would you in real life use class java.lang.ref.PhantomReference for large objects which you dont want to take the risk of being resurrected.

As per

Weakly Reachable

An object is weakly reachable when the garbage collector finds no strong or soft references, but at least one path to the object with a weak reference. Weakly reachable objects are finalized some time after their weak references have been cleared. The only real difference between a soft reference and a weak reference is that the garbage collector uses algorithms to decide whether or not to reclaim a softly reachable object, but always reclaims a weakly reachable object.

A phantom reference is quite different than either SoftReference or WeakReference. Its grip on its object is so tenuous that you can’t even retrieve the object — its get() method always returns null. The only use for such a reference is keeping track of when it gets enqueued into a ReferenceQueue, as at that point you know the object to which it pointed is dead. How is that different from WeakReference, though?

The difference is in exactly when the enqueuing happens. WeakReferences are enqueued as soon as the object to which they point becomes weakly reachable. This is before finalization or garbage collection has actually happened; in theory the object could even be “resurrected” by an unorthodox finalize() method, but the WeakReference would remain dead. PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to “resurrect” an almost-dead object.

What good are PhantomReferences? I’m only aware of two serious cases for them: first, they allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. This isn’t generally that useful, but might come in handy in certain very specific circumstances like manipulating large images: if you know for sure that an image should be garbage collected, you can wait until it actually is before attempting to load the next image, and therefore make the dreaded OutOfMemoryError less likely.

Second, PhantomReferences avoid a 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.

With PhantomReference, this situation is impossible — when a PhantomReference is enqueued, there is absolutely no way to get a pointer to the now-dead object (which is good, because it isn’t in memory any longer). Because PhantomReference cannot be used to resurrect an object, the object can be instantly cleaned up during the first garbage collection cycle in which it is found to be phantomly reachable. You can then dispose whatever resources you need to at your convenience.

Arguably, the finalize() method should never have been provided in the first place. PhantomReferences are definitely safer and more efficient to use, and eliminating finalize() would have made parts of the VM considerably simpler. But, they’re also more work to implement, so I confess to still using finalize() most of the time. The good news is that at least you have a choice.

ReferenceQueue rq = new ReferenceQueue();
PhantomReference pr = new PhantomReference(object, rq);

 // Wait until the object is about to be reclaimed.
 try {
   while (true) {
   Reference r = rq.remove();
   if (r == pr) {
     // The object is about to be reclaimed.
     // Clear the referent so that it can be reclaimed.
   } catch (InterruptedException e) {
phantom reference
A reference to a referent from inside a PhantomReference object. The garbage collector does not clear phantom references. The program must do so, by calling Reference‘s clear() method.
reference object
A SoftReference, WeakReference, or PhantomReference object — or any object created from any new subclass of the Reference class.
reference queue
A “first-in-first-out” data structure that holds references to Reference subclass objects. The garbage collector places those references on the queue by calling Reference‘s enqueue() method.
An object that is softly, weakly, or phantomly referenced from inside a SoftReference, WeakReference, or PhantomReference object, respectively.
soft reference
A reference to a referent from inside a SoftReference object. The garbage collector has the option of clearing soft references when heap memory is low.
weak reference
A reference to a referent from inside a WeakReference object. The garbage collector always clears weak references.
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: