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

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

@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 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

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 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.