The bug report included the following program to show the memory leak:
public class ThreadTest {
public static void main(String args[]) {
while (true) {
try {
Thread t = new Thread();
// start thread for memory leak workaround
// t.start();
t = null;
System.gc();
Thread.sleep(500);
} catch (InterruptedException ie) {
ie.printStackTrace();
}
}
}
}
I ran this program on my J2SDK 1.4.1 system. As predicted, the memory usage of the
JVM went up slowly at a rate of about 4K per 15 seconds.
As I mentioned in previous sections, Thread object created without a specific
thread group will be added into the "main" group. So
in the ThreadTest program included in the bug report, all the threads created
will be added in the "main" group, and will stay there until they are started
and ended. If we keep creating new threads, the number of threads in the "main"
group will grow, and memory usage will also grow.
But in my opinion, this is not really a bug. JDK is designed to organize all
Thread and ThreadGroup objects in a single thread group tree. Application programs
are forced to use this structure, and must follow the rules.
However, this designed feature is dangerous if not used properly, as demonstrated
by the bug report. It could be a risk for any server type application, if new threads
are created for new connection requests and the start() calls are not executed for
some reason.
One option to solve this problem is to:
At the Thread object creation time, add it to the thread group with a WeakReference.
At start time (when start() is called), change the WeakReference to a regular reference.
A couple of notes on this option:
The weak reference for an unstarted thread will allow the garbage collector to remove
the thread, if there is no more regular references to this thread in the application.
Replacing the weak reference by a regular reference when a thread is started will
prevent the garbage collector to remove this running thread, even if there is no more
regular reference to this thread in the application.
The implementation of this option could be two separate collections of threads in
a thread group: one for unstarted threads with weak references, and the other for started
threads with regular references.
Without any help from JDK, finding a simple workaround to prevent this from the
application side is not easy.
However, you can put a logic in your application to watch the number of unstarted
threads. If this number is growing, you know that somewhere in your application
threads are created without the start() calls. Here is the code to calculate the
number of unstarted threads:
ThreadGroup g = Thread.currentThread().getThreadGroup();
while (g.getParent()!=null) g = g.getParent();
Thread[] l = new Thread[g.activeCount()]];
int unstartedThreadCount = g.activeCount() - g.enumerate(l,true):
