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://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/ http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java

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

Yes, there are easier - and more proper - ways to resolve the leaks. Add the ClassLoader Leak Prevention library to your project, and it should take care of the problem for you!

In case you want to track down the leaks yourself, this blog series will be of help.

Answer 2

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 3

I'd approach the problem pragmatically:

1. Is it causing problems in production environments?
2. Have you got enough time and resources to track it down?

If the answer to both these questions is yes, then by all means go for it. If it's one yes, one no, it's probably up to the management to decide, if both are nos, don't bother.

Answer 4

@biziclop is right. You need to be pragmatic about this.

If the problem is only in test servers, you can probably dismiss this as not worth the effort to solve.

If the problem is in production servers then you need a solution or a workaround. The solution is hard work, but the workarounds may be less work:

• Workaround #1 - don't do hot deploys to production servers; only do full redeployments and restarts.

• Workaround #2 - periodically do a full restart of the production servers to avoid running out of permgen space. Combine this with increasing the permgen space.

In a well resourced / well run environment you should be doing all of your testing on separate servers. If the downtime of a full deployment is a concern, you should be minimizing redeployment disruptions using server replication and progressive redeployment. Hot deployments to production should be unnecessary.

If you are in the position where you have no test environment and are doing frequent hot deploys to a production machine to minimize downtime, you are skating thin ice. The chances are that you will eventually make a mistake that results in damage which takes a long time to recover from ...

Answer 5

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.