ClassLoader Leak - Are they worth solving?

Question

ClassLoader leaks usually result in java.lang.OutOfMemoryError: PermGen. In the instance of working on application servers you may see this as a result of many redeploys of a common application. The explanation and possible resolutions to this problem can be seen on these two links. (among others)

http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/

Now for the most part they are easy to get around. Simply increase the -XX:MaxPermSize and when the inevitable happens, restart the JVM completely. The problem with trying to solve this is that in large applications many classes can cause the classloader to leak and thus the classes to stay within the permgen.

Two questions arise from this:

Is it reasonable to say that an issue like this is better to just increase the max perm size and restart where necessary or should finding a resolution be a higher priority?

Are there easier ways to resolve a classloader leak?

Answer 1

It really depends on the application, or rather, the deployment process being used. Many applications are only ever redeplyoed during development, new releases happen once every few months, and the application server is restarted for other reasons far more often than the app is deployed. In those circumstances, chasing Classloader leaks is a waste of time.

Of course, if you plan on implementing a continuous deployment process, especially in a high-availability environment, then Classloader leaks are something you really need to tackle. But there are a lot of other things you need to do better than most projects before that becomes an issue.

Answer 2

Those are one of the worst leaks... but any leak is evil. So, I, personally, resolve them. Profiling helps as well. There are no easy ways per se but:

• Threads go into threadGroups +starter thread for each module to ensure new Threads() have that group.
• Special care of the Thread.inheritedAccessControlContext (which holds a reference to the classloader)
• WeakReferences when you need to keep classes, actually use WeakReferences for listeners, so no one can skip de-registers (and use only annon. clasess). Having the framework for WeakListeners does help.
• Extra care for DB drives, java.security.Provider
• few more tricks (incl. dynamic enhance of class files but that's overkill usually)

bottom line:

---

leaks are evil.