Adding on to Mohit's response, an object can actually still have some references pointing to it, and still be eligible for garbage collection. All that matters is that there must be no reachable references, i.e. references that can still be used by the current program. Two objects may have mutual references to each other, but as long as there are no reachable references to either object, then they're both eligible for garbage collection. For example:
(Things get a bit more complicated once we also start talking about soft/weak/phantom references, but those are thankfully outside the scope of the SCJP.)
You can also write some code where you override the finalize method of a given class so you see some output from the garbage collection:
But when you are really looking at some code,
the best thing is to draw a little pic with your variables pointing to the objects created. Then you should see when an object is no longer referenced and therefore eligible for GC.
In this example after line 3 it should look like:
After line 4 one is nulled, but that does not mean that the object is nulled, regard this as if the variable points to a null object:
Both Bananas are still there and none is eligible for GC.
After line 5 however there is no arrow pointing at the second banana and therefore it is eligible for GC.
If the GC (a background thread) runs you got the output from the finalize method if you have overridden it:
You may try to paint the situation from the code with the island of isolation provided by Kelvin.
By the way, drawing:
In the prometric test centers they will give you something to draw on, but you have to leave this at the testing center.
all events occur in real time
Kelvin Chenhao Lim
Joined: Oct 20, 2007
I whole-heartedly second the diagram drawing advice. As a matter of fact, that's exactly how I go about solving these garbage collection problems too. Excellent tip, Bu! (Cool drawings, too.)