Apparently ever since we had access to Java 1.4 we have lived along with a classloader leak built right in to the JDK. It is patched in the most recent Java 7 releases, but no backports exist for older JDKs. So at least 80% of us can still be affected by it.

You encounter the bug most often during redeployments in your Java EE application. But not always, but on circumstances when you have innocently used a sun.net.www.http.KeepAliveCache under the hood. It's so because the "keepAliveTimer" daemon thread created in sun.net.www.http.KeepAliveCache inherits the context class loader of the parent thread, and therefore holds a reference to that class loader. This is fine if the thread's context class loader is the system class loader, but it's bad if the context class loader is a custom class loader that may need to be unloaded at some future point. Which is exactly what your application server's classloaders would be doing every once in awhile during redeploys. The reference held by this thread means that the class loader can never become eligible for GC.

We have taken a look into the issue, analysed it's symptoms and described the consequences in this blog post.

If you keep running with an older JDK, then implicitly you've made the decision that its current behavior, bugs and all, is good enough.

If that's not good enough, then you made the wrong decision and should move the application to a new JVM.  That may also means moving to a recent version of a vendor's stack, of course.

The need for such updates of underpinning pieces of your environment (Java version, app server stack, etc) should be assumed and planned on rather than avoided like the plague -- unless, of course, the application is a short-term, throwaway.  These updates are best done early and often rather than when things are actively falling apart and no one remembers the application's internals anymore.  Failing to plan for such effort is planning to fail.

Your words to the managers' ears... As market researches and over-the-beer talks show: huge part of our industry is stuck with old versions of the infrastucture. Only about 20% are migrated to JDK7, and some are still using JDK5, which is just plain dead.

It gets worse.  My company writes banking software on an IBM stack, and we just move *TO* JDK 1.5 (due to moving IBM stacks up a version) about a year ago.  To say "banks are conservative" doesn't even begin to describe it.

It's the same as updating the OS on a server. Updating implies risk. Until you perform a lot of tests, you can't be sure you will land up with regressions. You sometimes prefer dealing with the bugs as you can contain them rather than dealing with new ones. I'm happy to use the latest and greatest, but the cost of down time of my applications due to bugs is significantly less than that of a bank.

This is why I don't work for banks.

I thought it was WebLogic Server doing this.

When a Java thread is created, it copies the protection domain (security context or AccessControlContext) of its parent thread.

Please see java.security.ProtectionDomain; it has reference to a class loader.

So thread.setContextLoader(null) is not enough for the solution.

If you use PrivilegedAction, a thread does not copy the security context of its parent.