Does a running thread in an object prevent it from being garbage collected in java ?

Question

Given the code:

 new Thread(new BackgroundWorker()).start();

Intuitively it feels like the BackgroundWorker instance should be safe from GC until the thread exits, but is this the case ? And why ?

Edit:

All this heat is basically generated by me asking at least two different questions in the same post. The question in the title has one answer, the code sample leads in a different direction - with two possible outcomes depending on inlining.

The answers posted are really excellent. I will be awarding Software Monkey the green checkbox. Please note that Darron's answer is equally valid, but Software Monkey explained the problem I was having; it was the answer that worked for me.

Thank you all for making this a memorable affair ;)

Answer 1

Yes, because the Thread keeps a reference to the Runnable internally (it has to know what to run, after all).

Answer 2

Yes, it is safe. The reason why is not as obvious as you might think.

Just because code in BackgroundWorker is running does not make it safe -- the code in question may not actually reference any members of the current instance, allowing "this" to be optimized away.

However, if you carefully read the specification for the java.lang.Thread class's run() method you'll see that the Thread object must keep a reference to the Runnable in order to fulfill its contract.

EDIT: because I've been voted down several times on this answer I'm going to expand upon my explanation.

Assume for the moment that it was not legal for anyone except Thread itself to call Thread.run(),

In that case it would be legal for the default implementation of Thread.run() to look like:

void run() {
    Runnable tmp = this.myRunnable;  // Assume JIT make this a register variable.
    this.myRunnable = null;          // Release for GC.
    if (tmp != null)
        tmp.run();         // If the code inside tmp.run() overwrites the register, GC can occur.
}

What I keep saying is that nothing in the JLS prevents an object from being garbage collected just because a thread is executing an instance method. This is part of what makes getting finalization correct so hard.

For excruciating detail on this from people who understand it much better than I do, see this discussion thread from the concurrency interest list.

Answer 3

I am willing to bet that the JVM includes a reference to each thread object that is active or can be scheduled in its root set, but I don't have the spec with me to confirm this.

Answer 4

Yes, because GC can only collect objects not reachable by any thread, and Thread must hold a reference to it's runnable (or it would not be able to invoke it). So, clearly, your Runnable object is reachable while your thread is running.

Regardless of the semantics required for execution, your object will not be GC'd until it is no longer reachable by this new thread or any other; that will be at least long enough to invoke your Runnable's run(), and for the entire life of the thread if that thread is able to reach the Runnable instance, so your construct is guaranteed to be safe by the JVM specification.

---

EDIT: Because Darron is beating this to death, and some seem convinced by his argument I'm going to expand upon my explanation, based on his.

Assume for the moment that it was not legal for anyone except Thread itself to call Thread.run(),

In that case it would be legal for the default implementation of Thread.run() to look like:

void run() {
    Runnable tmp = this.myRunnable;  // Assume JIT make this a register variable.
    this.myRunnable = null;          // Release for GC.
    if(tmp != null) {
        tmp.run();         // If the code inside tmp.run() overwrites the register, GC can occur.
        }
    }

I contend that in this case tmp is still a reference to the runnable reachable by the thread executing within Thread.run() and therefore is not eligible for GC.

What if (for some inexplicable reason) the code looked like:

void run() {
    Runnable tmp = this.myRunnable;  // Assume JIT make this a register variable.
    this.myRunnable = null;          // Release for GC.
    if(tmp != null) {
        tmp.run();         // If the code inside tmp.run() overwrites the register, GC can occur.
        System.out.println("Executed runnable: "+tmp.hashCode());
        }
    }

Clearly, the instance referred to by tmp cannot be GC'd while tmp.run() is executing.

I think Darron mistakingly believes that reachable means only those references which can be found by chasing instance references starting with all Thread instances as roots, rather than being defined as a reference which can be seen by any executing thread. Either that, or I am mistaken in believing the opposite.

Further, Darron can assume that the JIT compiler makes any changes he likes - the compiler is not permitted to change the referential semantics of the executing code. If I write code that has a reachable reference, the compiler cannot optimize that reference away and cause my object to be collected while that reference is in scope.

I don't know the detail of how reachable objects are actually found; I am just extrapolating the logic which I think must hold. If my reasoning were not correct, then any object instantiated within a method and assigned only to a local variable in that method would be immediately eligible for GC - clearly this is not and can not be so.

Furthermore, the entire debate is moot. If the only reachable reference is in the Thread.run() method, because the runnable's run does not reference it's instance and no other reference to the instance exists, including the implicit this passed to the run() method (in the bytecode, not as a declared argument), then it doesn't matter whether the object instance is collected - doing so, by definition, can cause no harm since it's not needed to execute the code if the implicit this has been optimized away. That being the case, even if Darron is correct, the end practical result is that the construct postulated by the OP is perfectly safe. Either way. It doesn't matter. Let me repeat that one more time, just to be clear - in the end analysis it doesn't matter.

Answer 5

No, I don't think it is not safe.

In practice you will almost certainly get away with it. However, the Java Memory Model is surprising. Indeed there was only last week discussion on the JMM mailing list about plans to add a method to "keep objects alive". Currently the finaliser can be run without a happens-before relationship from the execution of a member method. At the moment, you technically need to introduce a happens-before realitionship by synchronising all over the place or writing some volatile at the end of each method and a read of that volatile in the finaliser.

As Darron points out, if you can get of the Thread object (through Thread.enumerate for instance) then you can call run on it, which calls the Runnable's run. However, I still don't think there is a happens-before in there.

My advice: Don't try to be too "clever".

Answer 6

It is safe. The JVM holds onto a reference to each thread. The Thread holds on to an instance of the Runnable passed into its constructor. So the Runnable is strongly reachable, and will not be collected for the life of the Thread.

We know that the Thread holds a reference to the runnable because of the javadoc for Thread.run():

If this thread was constructed using a separate Runnable run object, then that Runnable object's run method is called; otherwise, this method does nothing and returns.