Garbage collection by local variable

Question

I am a C ++ programmer in the Java world. And I can't get rid of the bad feeling of letting the Java garbage collector do my cleanup.

How, for example, will this code work in Java?

public void myFunction() { myObject object = new myObject(); object.doSomething(); } 

Will the local variable object be deleted when myFunction () exits?

Should I set the object to zero before exiting, or will it be unavailable and will be deleted by GC? Or, in the worst case, will it flow, as in C ++?

Answer 1

This will be garbage collection at some point after it is no longer in use. I believe that in current Java implementations it will persist until the end of the method, while the .NET garbage collector is more aggressive. (I don’t know if there are any guarantees even in Java. Usually you need the local variable to be kept outside of its last possible reading when you are debugging.)

But no, you do not need to set the variable to null, and this can degrade readability.

It is unlikely that the object will garbage immediately after the method exits; this is until the moment the GC works ... and, of course, if something else keeps a reference to the object, in any case it may not have the right to garbage collection. Remember that the value of a variable is just a reference, not the object itself. (It may take some time to get used to C ++.)

Answer 2

I came across this code:

 { final List myTooBigList = new ArrayList(); ... overfill the list } somethingRunOutOfMemory(); 

somethingRunOutOfMemory () because myTooBigList was not a GCable even though it was no longer in scope.

As in C, local variables are stacked next to frames. The stack pointer reserves as much space as is needed for local variables in scope. The local block variable becomes GCable when the stack is reused. When a pointer moves out of scope, as soon as it is required by new local variables.

They are GCable after:

 try { } catch : after exit by catch because catch reuses stack for { } : after exit loop condition because evaluation reuses stack while { }: after exit loop condition because evaluation reuses stack { } followed by any local declaration that reuses stack 

They are not GCable after:

 try { } finally try { } catch : after nothing caught for { } : after break while { } : after break do { } while : after loop condition if { } { } not followed by a local declaration 

If I want local to be GCable, I write:

 { final List myTooBigList = new ArrayList(); ... overfill the list } Object fake = null; somethingDoesntRunOutOfMemory(); 

Fake affectation moves the stack pointer back and makes myTooBigList GCable. Surprisingly, (at least in jvm testing) we must explicitly use the stack. It would be more expected that the local variables will be GCable as soon as they exit the block, but I think this is a compromise with performance. This will complicate the bytecode.

NOTE. To check if the variable is GCable, I run GC, then compare the value of WeakReference (my variable) to zero.

 final WeakReference gctest; { final List myTooBigList = new ArrayList(); gctest = new WeakReference(myTooBigList); ... overfill the list } Object fake = null; System.gc(); assert gctest.get() == null; 

Answer 3

He will go beyond. In Java, when no one else points to an object, garbage will be collected, or at least it will be available for garbage collection. No null value is required here. Sometimes setting a reference to an object to zero is necessary if your object will live in your application, but the link it holds must be garbage collected. In this case, you want to free the link.