Dave Landers

One of the most surprising memory leaks I found looked like this:

Thread t = new Thread();

Of course, that’s not exactly the whole story, but it illustrates the point that just knowing where the leaky object is referenced is not always enough to find the cause of the leak.

So why does new Thread() leak? It turns out that WLS puts some important (internal) information on the thread as InheritableThreadLocal instances. Some of these references may contain references to the application’s ClassLoader. Since they are inheritable, they will be passed to the new thread.

And if that new thread outlives the application ClassLoader (that is, the application is undeployed before the thread stops), then you have a leak.

Of course, a good J2EE developer will recognize that creating threads is not allowed by the specification - you should instead use something like WorkManager. And that is correct.

But I am in a somewhat different environment, where we are building what amounts to a container. So, while we are doing J2EE, we are also building the container to support J2EE components. So we sometimes walk a fine line on issues like this.

Technorati Tags: leak, memory, WebLogic