How setting an Object to null help Garbage Collection?

Priyanka Dandekar

Ranch Hand

Posts: 52

posted 9 years ago

I was reading through some forums and found suggestion that setting an object to null helps Garbage collection? Is it true. How does it matter for GC whether a reference is already set to NULL or not, GS has to still do its check on the reference right??

Actually the garbage collector checks if an Object has any reachable reference in any threads. If it has then the Object is not garbage collected.

And about setting the Object to null..See this example

In this code the object will be destroyed after the call at (2) returns. So the memory occupied by the object created at (1) remains occupied for no reasons. To avoid this change this program to-

The addition of (x) will make the object eligible for garbage collection before the call to sleep. So the object can be destroyed anytime during the execution of the method(). [ August 07, 2008: Message edited by: AnkitJi Garg ]

you are referring another object to the previously created object. Note that item and itemCopy are links to one object, that is they are not the object!

Now, suppose you progam runs for 100 years, even if you DO NOT use both item or itemCopy for 100 years the garbage collector will never throw away the object because item and itemCopy refer to it. To authorize the garbage collector to destroy the object it should be necessary that 1) the virtual machine is going out of memory then the garbage collector try to clean something 2) garbage collector can delete the object previously created only if item = null; intemCopy = null;

in this situation no link refer to the previously created object so the garbage collector is authorized to take back its memory space. Anway remember: the garbage collector runs ONLY when IT WANTS to run

So the final verdict that can be made is that whenever you don't need an object any more you must set it to null. This is applicable if you still have a lot of working to do. Eg. method() { SomeClass o = new SomeClass(); : : o = null; //no need as the object will be eligible for garbage collection any way }

but here method() { SomeClass o = new SomeClass(); : : //o is not needed any more o = null; //good as you still have a lot of processing to do : ://a lot of processing }

Also, To emphasise the point, one needs to remember that garbage collection cannot be forced by calling System.gc().

What calling System.gc() does is to give a chance for the garbage collector to collect as much memory it can depending on how much opportunity the GC has to do it. In Ankits' code you increase the opportunity to collect by putting the current thread to sleep.

I am unclear what you are tyring to say here. But there is no GC cycle as such. And how have you observed it?

The generational GC has two types of cycle minor and major...

When the new generation fills up, it triggers a minor collection, in which surviving objects are moved to the old generation. When the old generation fills up, it triggers a major collection, which involves the entire object heap.

There are JVM options which can be provided to print verbose GC logs....this tell you when a Major or minor GC is run and how much time it took.

method() { SomeClass o = new SomeClass(); : : //o is not needed any more o = null; //good as you still have a lot of processing to do : ://a lot of processing }

I'd rather say that that method is likely too big and should be splitted into at least two smaller methods. Which would likely solve the problem without having to explicitly set a reference null.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus