Garbage Collection of Threads

[WonderboyFromMars]

Hello everyone.

I have a problem with instanciating many threads and the destruction of
these objects.
Does the garbage collector actually delete threads?
I'm writing a network application which has to create 2 threads which
read and write to PipeStreams on each new conenction. And I have alot
of
connections. the problem is that the application has a big mem.-leak
and
I narrowed it down to the fact that the Garbage Collector actually
won't
clean up stopped or interrupted threads. JProfiler tells me that more
an
more instances of the threads are created although the threads are
inactive (the thread-column in the Windows taskmanager jumps to a
thread-peak but drops down to the actual number of threads). I think
that the thread memory still remains on the heap. I'm actually a c++
programmer who does eventually something in java the code looks
something like this

while(...)
{
socket.accept()

ThreadWorker1 tw1 = new ThreadWorker1(...);
ThreadWorker2 tw2 = new ThreadWorker2(...);
tw1.start();
tw2.start();
}

the threadworkers start their own threads internally which get
interrupted when the work is done. does this construction lead to
mem.-leaks? If I let the app run for let's say an hour and then look at
the instance count of ThreadWorker1 and ThreadWorker2 in JProfiler, I
can see that the instance count never goes down but up (after 1 h i
have
100 instances of TW1 and TW2). The threads are definitly stopped
sometime (or Windows Taskmanager is lying ) but obviously never
released.

Thanks in advance
Anusch

 

[Roedy Green]

Does the garbage collector actually delete threads?

If you create them but never start them, they will hang around
forever. Normally though they die as soon your run method returns and
the Thread along with its whacking great stack is gced.

 

[Roedy Green]

clean up stopped or interrupted threads. JProfiler tells me that more
an

You are not supposed to stop threads. That method is deprecated. Who
knows what happens then.

Interrupted threads are still very much alive so of course should NOT
be gced.

 

[WonderboyFromMars]

First of, thanks for your reply Roedy!

I do actually interrupt the threads! I should just let the threads "run
out" of their run methods? Should this really solve the problem? It
would be great! Is it better to let some sort of ThreadPool manage the
lifetime of the threads? I am really uncomfortable producing so many
threads and fire and forgetting them but this was the easiest and
fastest way to implement this application.

 

[Roedy Green]

I do actually interrupt the threads! I should just let the threads "run
out" of their run methods? Should this really solve the problem? It
would be great! Is it better to let some sort of ThreadPool manage the
lifetime of the threads? I am really uncomfortable producing so many
threads and fire and forgetting them but this was the easiest and
fastest way to implement this application.

Have a look at http://mindprod.com/jgloss/queue.html
and follow the links in into the Sun documentation on the new
concurrent classes. They give you all sorts of ways of managing thread
pools.

 

[Chris Smith]

If you create them but never start them, they will hang around
forever. Normally though they die as soon your run method returns and
the Thread along with its whacking great stack is gced.

It's worth mentioning that there's a big difference between a thread and
an object of class Thread. The object should be understood as a
control-panel that can be used to control the thread... not the thread
itself.

In particular, the release of memory used for a thread's stack is NOT
related to garbage collection. The stack space is in no way associated
with the Thread instance. It is released the very instant that the
thread exits.

This is also important because the Thread object can last far longer
than the thread itself. It's not uncommon, for example, to keep around
a reference to a thread so that you can call join, interrupt, isAlive,
etc. on the object. If the thread were kept around as long as you keep
a reference to that object, then you might start to think that doing so
is a bad idea. It's not, though.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Steve Horsley]

First of, thanks for your reply Roedy!

I do actually interrupt the threads! I should just let the threads "run
out" of their run methods? Should this really solve the problem? It
would be great! Is it better to let some sort of ThreadPool manage the
lifetime of the threads? I am really uncomfortable producing so many
threads and fire and forgetting them but this was the easiest and
fastest way to implement this application.

I strongly suspect that Threads don't become eligible for GC
until after they return from run(). I presume that stopping the
thread prevents it from ever retuning.

I don't see what interrupting it has to do with this though. You
may change its course, wake it from some blocking state, but
until it returns from run() it is alive and cannot be GCd
whatever it is doing.

The normal way to kill threads is to tell them you wish them to
quit - set a flag they look at from time to time (interrupting
sets a flag they can check with isInterrupted IIRC). When they
see they are no longer wanted, then they can clean up, releasing
any locks or other resources they hold and return (run out from
run) in their own time. They don't have to explicitly de-allocate
Objects that they hold, because the GC will clean those up.

Steve

 

[Thomas G. Marshall]

(e-mail address removed) coughed up:

First of, thanks for your reply Roedy!

I do actually interrupt the threads! I should just let the threads "run
out" of their run methods? Should this really solve the problem? It
would be great! Is it better to let some sort of ThreadPool manage the
lifetime of the threads? I am really uncomfortable producing so many
threads and fire and forgetting them but this was the easiest and
fastest way to implement this application.

Could you elaborate a little on why you think you need a great number of
threads?

Most of the times I've seen this, the designer was very much mistaken.

 

[DrChaos]

I would agree that this is the best code safe way to deal with live
threads. Manageable and predictable. From a thread manager, track who
is alive if they where asked to quit and when they have actually
returned/quit.
-DrChaos