Is it a good practice to remove references to help

Question

I am wondering whether you would consider it a good practice to remove references (setting them to null) to objects in order to help the Java Garbage Collector.

For instance, let's say you have a class with two fields, one of them being very memory-consuming. If you know you only need it for a particular processing, you can null it right after to help the GC.

Assume I really need those two to be fields, and not only internal variables, so heavyObject1 cannot be out of scope at the end of the method.

Would you do this as a general practice?

public class TestClass {

   public static Object heavyObject1;
   public static Object object2;

   private static void action() {
    object2 = doSomething(heavyObject1);

    heavyObject1 = null; //is this good?
   }
}

Answer 1

In most of the cases, you dont need to set the object to null to be garbage collected.If you decalre the object in proper scope(method level,instance level or class level), the object will be unreachable immediately after its use and will be eligible for garbage collection.

Answer 2

No. It is not generally good practice to null fields or locals.

In most cases the object whose field you are nulling is going to become unreachable before the GC runs. If that happens, the CPU cycles you spent nulling the object's field are going to be wasted.

The only situations where it is necessary / good to null fields / locals are where:

1. it is likely that the parent object will still be reachable when the GC runs, AND
2. the child object (graph) is large enough for the amount of memory retained to be significant ... relative to the total heap size.

You might also do it if you are implementing a class that is intended to be used in a wide range of situations ... and some of those situations could fit the criteria above. (For instance, a data structure implementation where the instances could grow large.)

Answer 3

As a general practice, no, because it is not needed.

There are special cases -- I can imagine a long-lived class, for instance, that has a long list of memory consuming objects with which it does something one time and then waits for a period before replacing that list with another list. Might as well null the list while you're waiting, won't hurt anything, and may prevent the program from having to end up with both lists at the same time.

But therein lies the "not needed" principle again. You can't count on the GC to run during particular period, so the program needs to support having both these lists on the heap at the same time, so it doesn't make your program viable if it was not so before.

And let's PLEASE not encourage people to make a 'rule' about it. When I think of all the code I've read where someone puts "final" in front of (nearly) all the variables that (they think) won't change after initialization, making the code less readable and convincing me that the programmer had no understanding of the speed improvement they were supposedly making...

Answer 4

Dereferencing objects is unnecessary unless your class is managing its own memory or your class is caching resources, then obsolete references should be eliminated.

Answer 5

No, it's unnecessary. As soon as heavyObject1 is out of scoped, it'll be marked for GC anyway.

Answer 6

Usually it isn't needed.

It's a good idea in the following specific circumstance:

• The object is large (i.e. large enough for you to care)
• You are sure the object won't be needed again
• The object won't go out of scope otherwise (e.g. you know the surrounding object won't be garbage collected)

However if you find yourself in this situation I suspect you have a design smell anyway: why does the internal object have such a different scope / lifetime from the enclosing object? This makes me suspicious, because usually when you build up an object graph with composition you expect the composed objects to have similar lifetimes.