tags:

views:

337

answers:

6
+5  Q: 

Explicit nulling

In what situations in java is explicit nulling useful. Does it in any way assist the garbage collector by making objects unreachable or something? Is it considered to be a good practice?

+7  A: 

In general it isn't needed (of course that can depend on the VM implementation). However if you have something like this:

private static final Map<String, String> foo;

and then have items in the map that you no longer need they will not be eligible for garbage collection so you would need to explicitly remove them. There are many cases like this (event listeners is another area that this can happen with).

But doing something like this:

void foo()
{
    Object o;

    // use o

    o = null; // don't bother doing this, it isn't going to help
}

Edit (forgot to mention this):

If you work at it, you should find that 90-95% of the variables you declare can be made final. A final variable cannot change what it points at (or what its value is for primitives). In most cases where a variable is final it would be a mistake (bug) for it to receive a different value while the method is executing.

If you want to be able to set the variable to null after use it cannot be final, which means that you have a greater chance to create bugs in the code.

TofuBeer
Good point about the 'final' part. +1 . However, I know some programmers who seem to consider adding final as 'clutering' their code! See this answer: http://stackoverflow.com/questions/132777/do-you-prefix-your-instance-variable-with-this-in-java/135407#135407
VonC
There are many programmers who think this. It is pretty much a religious argument.
Robin
I like anything that makes writing bugs instead of code harder :-)
TofuBeer
Like readability? As I said, it comes down to a religious argument. No real right and wrong, just personal opinions and preferences. I don't expect others to change their opinion, I am just expressing mine.
Robin
I don't find readability an issue with final, but as you basically said, to each their own. (also the :-) generally means that I am joking around)
TofuBeer
I realize you were joking around, my question was also meant tongue in cheek. Forgot the smiley. ;-) There it is!
Robin
+12  A: 

In Java it can help if you've got a very long-running method, and the only reference to the an object is via a local variable. Setting that local variable to null when you don't need it any more (but when the method is going to continue to run for a long time) can help the GC. (In C# this is very rarely useful as the GC takes "last possible use" into account. That optimization may make it to Java some time - I don't know.)

Likewise if you've got a member field referring to an object and you no longer need it, you could potentially aid GC by setting the field to null.

In my experience, however, it's rarely actually useful to do either of these things, and it makes the code messier. Very few methods really run for a long time, and setting a variable to null really has nothing to do with what you want the method to achieve. It's not good practice to do it when you don't need to, and if you do need to you should see whether refactoring could improve your design in the first place. (It's possible that your method or type is doing too much.)

Note that setting the variable to null is entirely passive - it doesn't inform the garbage collector that the object can be collected, it just avoids the garbage collector seeing that reference as a reason to keep the object alive next time it (the GC) runs.

Jon Skeet
+2  A: 

If you are nulling an object that is about to go out of scope anyway when your method block closes, then there is no benefit whatsoever in terms of garbage collection. It is not unusual to encounter people who don't understand this who work really hard to set a lot of things to null needlessly.

Charlie Flowers
+1  A: 

See also WeakReference in J2SE.

Andrew Swan
+3  A: 

From "Effective Java" : use it to eliminate obsolete object references. Otherwise it can lead to memory leaks which can be very hard to debug.

public Object pop(){
    if(size == 0)
        throw new EmptyStatckException();
    Object result = elements[--size];
    elements[size] = null; //Eliminate Object reference
    return result;
}
jsha
+3  A: 

One special case I found it useful is when you have a very large object, and want to replace it with another large object. For example, look at the following code:

BigObject bigObject = new BigObject();
// ...
bigObject = new BigObject(); // line 3

If an instance of BigObject is so large that you can have only one such instance in the heap, line 3 will fail with OutOfMemoryError, because the 1st instance cannot be freed until the assignment instruction in line 3 completes, which is obviously after the 2nd instance is ready.

Now, if you set bigObject to null right before line 3:

bigObject = null;
bigObject = new BigObject(); // line 3

the 1st instance can be freed when JVM runs out of heap during the construction of the 2nd instance.

Bartosz Klimek
A very rare case, but true none the less.
MBCook
Though if this does occur, i suspect you'd have bigger problems in terms of design.
Chii