• Post Reply Bookmark Topic Watch Topic
  • New Topic

What happens when a thread completes?

 
Jiafan Zhou
Ranch Hand
Posts: 193
Fedora Linux Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suppose the following code to create a simple thread a usage client:

class MyThread extends Threads
{
public void run()
{
// some code logic, but completes after a second
}
}

public class ApplicationRunner
{
public static void main(String[] args)
{
Thread t = new MyThread();
t.start();

// main thread waits for a long time before finishing...
}
}

Now the above code demonstrates that MyThread completes shortly, but main thread is running for a longer time period.
What happens to the object instance of MyThread pointed by the object reference t?

I don't think the object instance will be garbage collected since t is still pointing at it. So how the instance will be garbage collected ever?
 
Jiafan Zhou
Ranch Hand
Posts: 193
Fedora Linux Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also what happens when a thread completes (finishes running) in the ThreadPoolExecutor? Will that thread be removed from the thread pool executor and garbage collected?
 
Paul Clapham
Sheriff
Posts: 21876
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jiafan Zhou wrote:I don't think the object instance will be garbage collected since t is still pointing at it. So how the instance will be garbage collected ever?


That's correct. There's an active reference to the object, so it won't be garbage collected. This is perfectly normal behaviour for Java objects, so it's up to you to explain why Thread objects should be treated differently.
 
Jiafan Zhou
Ranch Hand
Posts: 193
Fedora Linux Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
Jiafan Zhou wrote:I don't think the object instance will be garbage collected since t is still pointing at it. So how the instance will be garbage collected ever?


That's correct. There's an active reference to the object, so it won't be garbage collected. This is perfectly normal behaviour for Java objects, so it's up to you to explain why Thread objects should be treated differently.


So in order to garbage collect a completed thread instance, we need to explicitly nullify the object instance.
for example....
MyThread myThread = new MyThread();
Thread t = new Thread(myThread);
t.start();

// once the thread t completes, we need to do
myThread = null;
t = null;

OMG, that's great...
 
Paul Clapham
Sheriff
Posts: 21876
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not really. You just wait for the variable to go out of scope. The Thread only requires a few bytes of memory and there's only one object, so there is basically no point in making a fuss about having it garbage-collected right away.

And you seem to have missed my point, which is that the rules about garbage collection apply to all classes equally. There is nothing special about Thread that requires you to treat it differently.
 
Jiafan Zhou
Ranch Hand
Posts: 193
Fedora Linux Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:Not really. You just wait for the variable to go out of scope. The Thread only requires a few bytes of memory and there's only one object, so there is basically no point in making a fuss about having it garbage-collected right away.

And you seem to have missed my point, which is that the rules about garbage collection apply to all classes equally. There is nothing special about Thread that requires you to treat it differently.


I should have said that the thread instance variables have a wider scope. I understand your point that the garbage collection apply to all classes including Thread object. This is why I think we should nullify the object instance after the thread completes.

I will not make a fuss if I only create a small amount of thread object instances in memory and uses some local variables. In my case, I created a large amount of thread instances and all of them have "wider" variable scope than local. If I don't treat them separately, I am sure it is going to cause some sort of memory leak. I can't rely on the "going out of scope" to have them garbage collected.

I am now more convinced to solve the issue using a thread pool solution, for example, the JDk5 ThreadPoolExecutor. Thanks.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jiafan Zhou wrote:Also what happens when a thread completes (finishes running) in the ThreadPoolExecutor? Will that thread be removed from the thread pool executor and garbage collected?

That depends on how the TPE was initialized, and how many threads it currently has. The relevant parameters are: core pool size, keep alive time, and current pool size.

The thing to understand is that threads in the pool can be kept around indefinitely, and one thread can handle many different tasks, one at a time, over its lifetime. So when one task is completed, the TPE needs to decide whether the worker thread that completed the task should be kept in the pool, or released. It will retain the thread in the pool for the duration of the keep alive time. After that, if the current pool size is greater than the core pool size and there's not another task immediately available in the queue, then the thread is released from the pool, and the Thread is available for GC.

If you want to make all the threads available for GC (including the core number of threads), then you have to call shutdown() or shutDownNow() and wait until all jobs have completed or been cancelled, and the pool is terminated.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!