This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Suppose that you want to keep track of the references of a bunch of objects. So you stick a reference to each of them in a HashMap or whatever. These would be Strong References. Now all those zillions of objects CAN NOT be garbage collected - just because of YOU. Clogging up the system again :roll: So now what if you don't want to be the CAUSE of them not getting gc'd? Instead you create a WeakReference object for each of them and put THAT in your Map. Then then if there are no references to one of those guys except your WeakReference (or if that was always the only reference), the gc knows that it is OK to go ahead and do the clean up. Of course this means that you have no control over keeping hold of your references - but that may be OK, especially if you are building tools or IDEs or whatnot. From the API:
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.
OK, now suppose that you are keeping a bunch of references just to keep things more efficient. Good idea. Unless of course you run out of Memory. Then it is a BAD idea. Instead you can keep them as SoftReference objects, and then if things get clogged up, the gc has permission to get rid of these references. (As long as there are no Strong References to them somewhere else). This could keep the system from crashing right at a critical moment, even if you do lose some efficiencey or whatever.
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.
Reachability Going from strongest to weakest, the different levels of reachability reflect the life cycle of an object. They are operationally defined as follows: An object is strongly reachable if it can be reached by some thread without traversing any reference objects. A newly-created object is strongly reachable by the thread that created it. An object is softly reachable if it is not strongly reachable but can be reached by traversing a soft reference. An object is weakly reachable if it is neither strongly nor softly reachable but can be reached by traversing a weak reference. When the weak references to a weakly-reachable object are cleared, the object becomes eligible for finalization. An object is phantom reachable if it is neither strongly, softly, nor weakly reachable, it has been finalized, and some phantom reference refers to it. Finally, an object is unreachable, and therefore eligible for reclamation, when it is not reachable in any of the above ways.
Phantom References are tricky. There are mostly there for clean up purposes. What if you HAVE TO do some stuff before an object is completely gc'd? The original Finalization stuff in Java had it's problems and this is one of the solutions to it. Instead you can create a PhantomReference object that tracks the object that needs finalization. Lets call it Herby. When the gc notices that there are no Strong References to Herby, it will enqueue it for getting rid of. However, if there is a PhantomReference to it, it will not actually get gone. It will get Finalized but not reclaimed. At that point the PhantomReference also gets enqueued and does it's finalization which is basically to do any clean up for Herby that it couldn't do for itself. That would mostly be stuff that requires that Herby be unreachable first. A typical thing might be to de-allocate something that is outside of the Java Heap. The application has to call a clear() on the PhantomReference or both it and Herby will stay stuck in the queue forever . When you clear() the PhantomReference both it and Herby get reclaimed (well, you know . . whenever the gc gets around to it). The order of operations is: (All Strong references must be gone first) Soft references are gc'd Weak references are gc'd Finalization on Herby Phantom references are gc'd Reclamation (bye Herby) Of course the fun really starts happening if you have a PhantomReference to a WeakReference to a SoftReference to an Object
"JavaRanch, where the deer and the Certified play" - David O'Meara
It sounds like the only difference between Weak and Soft references is that weakly-reachable objects are reclaimed as soon as feasible, while softly-reachable objects are reclaimed only when the system is about to run out of memory. Is that correct?
Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Joined: Jun 06, 2002
And I still don't see what phantom references are good for. If get() always returns null, how can I get to the object to do any cleanup?
hi Cindy thanks for your explanation. i remeber that i went to the link you provided here long back (before 2.5 yrs if i am right) but at that time i didn't quite understand the article at all. may b i's dumb at that time OR i'm smarter now....:-) whatever... i also am not very clear about Phantom Ref but i don tend to worry abt things too much unless they r points guns at me regards maulin