这实际上取决于应用程序，或者更确切地说，取决于所使用的部署过程。许多应用程序只在开发期间重新部署，每隔几个月发布一次新版本，并且应用服务器因其他原因而重新启动的频率远远高于应用程序的部署。在这些情况下，追踪Classloader泄漏是浪费时间。
当然，如果你打算实现一个continuous deployment process，特别是在一个高可用性的环境中，那么类加载器泄漏是你真正需要解决的问题。但是在这成为一个问题之前，你还有很多其他事情需要做得比大多数项目更好。

@biziclop是对的。你需要务实一点。
如果问题只发生在测试服务器上，您可能会认为不值得解决这个问题。
如果问题出现在生产服务器中，那么您需要一个解决方案或解决方法。解决方案是艰苦的工作，但解决方法可能会减少工作：

• 解决方案#1 -不要对生产服务器进行热部署;仅执行完全重新部署和重新启动。
• 解决方法#2 -定期完全重启生产服务器，以避免耗尽permgen空间1。将此方法与增加permgen空间结合使用。

在资源充足/运行良好的环境中，您应该在单独的服务器上进行所有测试。如果担心全面部署的停机时间，则应该使用服务器复制和渐进式重新部署来最大限度地减少重新部署的中断。不需要热部署到生产环境。
如果您处于没有测试环境的位置，并且正在对生产机器进行频繁的热部署以最大限度地减少停机时间，那么您就是在如履薄冰。您最终可能会犯错误，导致需要 * 长时间 * 才能恢复的损坏。
1 -在Java 8和更高版本中，permgen已经消失了。但另一方面，类加载器泄漏现在会在常规堆中泄漏内存。

这是最糟糕的泄密事件之一......但任何泄密都是邪恶的。所以，我个人会解决它们。分析也会有所帮助。没有简单的方法，除了：

• 线程进入每个模块的threadGroups +starter线程，以确保new Threads（）具有该组。
• 特别注意Thread.inheritedAccessControlContext（它保存对类加载器的引用）
• WeakReferences当你需要保留类的时候，实际上使用WeakReferences作为监听器，这样就没有人可以跳过注销（并且只使用annon.clasess）。
• 特别注意DB驱动器、java.security.Provider
• 还有一些技巧（包括动态增强类文件，但通常都是矫枉过正）

底线：
泄密是邪恶的

是的，有更简单-也更合适-的方法来解决泄漏。将ClassLoader Leak Prevention library添加到您的项目中，它应该会为您解决问题！
如果您想自己追踪泄漏，this blog series将有所帮助。

我会务实地处理这个问题：
1.它是否会在生产环境中造成问题？
1.你有足够的时间和资源去追踪它吗？
如果这两个问题的答案都是肯定的，那就尽一切努力去做吧。如果一个是，一个不是，那可能要由管理层来决定，如果两个都是否定的，那就不用麻烦了。