Java threads and garbage collector

Question

Possible Duplicate:
Java Thread Garbage collected or not

Consider the following class:

class Foo implements Runnable {

  public Foo () {
       Thread th = new Thread (this);
       th.start();
  }

  public run() {
    ... // long task
  }

}

If we create several instances of Foo by doing

new Foo();
new Foo();
new Foo();
new Foo();

(note that we don't keep a pointer to them).

1. Could those instances be removed by the garbage collector before the thread in run() ends? (In other words: is there any reference to the Foo objects?)

2. And, in the other hand, will those instances be removed by the GC after the thread in `run()' ends, or are we wasting memory ("memory leak")?

3. If either 1. or 2. are a problem, what's the right way to do it?

Thanks

Answer 1

1. Any object which is referenced by an active thread may not be de-allocated.
2. Yes, instances will be removed by the GC after the thread in `run()' ends.
3. No prob.

Answer 2

1. Could those instances be removed by the garbage collector before the thread in run() ends? (In other words: is there any reference to the Foo objects?)

No. While the constructor is running GC won't collect the object. Otherwise even the simplest:

Customer c = new Customer();

could fail while the constructor of Customer is running. On the other hand when you start a new thread, the thread object becomes a new GC root, so everything referenced by that object is not a subject to garbage collection.

1. And, in the other hand, will those instances be removed by the GC after the thread in `run()' ends, or are we wasting memory ("memory leak")?

Once the thread is done, it is no longer a GC root. If no other code points to that thread object, it will be garbage collected.

1. If either 1. or 2. are a problem, what's the right way to do it?

Your code is just fine. However:

• starting a new thread in a constructor is a poor idea from unit-testing point of view

• keeping a reference to all running thread might be beneficial if e.g. you want to interrupt these threads later.

Answer 3

Starting a new thread without specifying a thread group will add it to the default group:

If group is null and there is a security manager, the group is determined by the security manager's getThreadGroup method. If group is null and there is not a security manager, or the security manager's getThreadGroup method returns null, the group is set to be the same ThreadGroup as the thread that is creating the new thread.

The group will keep a reference to the thread as long as it is alive, so it can't be GC'd during that time.

When a thread terminates (= when run() returns for whatever reason), the thread is removed from the thread group. This happens in the private method exit() which is called from native code. This is the point in time when the last reference to the thread is lost and it becomes eligible for GC.

Note that the code indicates that ThreadGroup can be null but that isn't the case. The various null-checks are just to avoid NPEs in the rare case that something goes wrong. In Thread.init(), you would get NPEs if Java couldn't determine a thread group.

Answer 4

1. The Foo object is referenced by the Thread. Thread is referenced during its run all the time. Therefore it will not be garbage collected.
2. No memory leaks. Thread will end and will be garbage collected and Foo object in this process as well.
3. It should work fine.

Answer 5

Assuming you are creating the objects in the run method, the objects will go out of scope when the run method exits and then will be available for garbage collection. Run is just another method. Using threads or not does not change the garbage collection behavior here in any way. All you need to care about is when the objects go out of scope, which is generally tied to block scope (method block, while loop, if block, etc..).

So, since you are not keeping any reference to the object to begin with, you might want to extract the logic that creates the object into its own short lived method. That way the object that is created won't need to be kept beyond the scope of that method.