ClassLoader Leak - Are they worth solving?

我的未来我决定 提交于 2019-12-03 05:45:57

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.

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

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.

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.

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!