类加载器泄漏 - 它们值得解决吗？

Question

ClassLoader 泄漏通常会导致 java.lang.OutOfMemoryError: PermGen。在使用应用程序服务器的实例中，您可能会看到这是由于公共应用程序多次重新部署而导致的。这个问题的解释和可能的解决方案可以在这两个链接中看到。 （除其他外）

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

现在，大多数情况下它们很容易绕过。只需增加 -XX:MaxPermSize，当不可避免的情况发生时，完全重新启动 JVM。试图解决这个问题的问题是，在大型应用程序中，许多类可能会导致类加载器泄漏，从而导致类保留在永久代中。

由此产生了两个问题：

是否可以合理地说，像这样的问题最好只是增加最大永久大小并在必要时重新启动，还是应该优先考虑找到解决方案？

有没有更简单的方法来解决类加载器泄漏？

Answer 1

这实际上取决于应用程序，或者更确切地说，取决于所使用的部署过程。许多应用程序仅在开发期间重新部署，新版本每隔几个月发布一次，并且应用程序服务器因其他原因重新启动的频率远高于应用程序部署的频率。在这种情况下，追踪类加载器泄漏是浪费时间。

当然，如果您计划实现持续部署过程，特别是在高可用性环境中，那么类加载器泄漏就是问题你确实需要解决。但在这成为一个问题之前，还有很多其他事情需要比大多数项目做得更好。

Answer 2

@biziclop是对的。你需要对此保持务实态度。

如果问题仅出现在测试服务器中，您可能会认为这不值得花精力去解决而忽略它。

如果问题出现在生产服务器中，那么您需要一个解决方案或解决方法。解决方案是一项艰苦的工作，但解决方法可能会更少工作：

• 解决方法#1 - 不要对生产服务器进行热部署；仅进行完全重新部署并重新启动。

• 解决方法 #2 - 定期完全重新启动生产服务器以避免耗尽永久代空间¹。将此与增加永久代空间结合起来。

在资源充足/运行良好的环境中，您应该在单独的服务器上进行所有测试。如果完整部署的停机时间是一个问题，您应该使用服务器复制和渐进式重新部署来最大限度地减少重新部署中断。应该不需要热部署到生产环境。

如果您没有测试环境并且经常对生产机器进行热部署以最大限度地减少停机时间，那么您就如履薄冰。您最终可能会犯一个错误，导致损坏，需要很长时间才能恢复...

---

^{1 - 在 Java 8 及更高版本中，permgen 已消失。但另一方面是类加载器泄漏现在会泄漏常规堆中的内存。}

Answer 3

这些是最严重的泄漏之一……但任何泄漏都是邪恶的。因此，我个人会解决这些问题。分析也有帮助。
本身没有简单的方法，但是：

• 线程进入每个模块的 threadGroups +启动线程，以确保 new Threads() 具有该组。
• 当您需要保留类时，请特别注意 Thread.inheritedAccessControlContext（它保存对类加载器的引用）
• WeakReferences，实际上将 WeakReferences 用于侦听器，因此没有人可以跳过取消注册（并且仅使用 annon.class）。拥有 WeakListeners 框架确实有帮助。
• 对数据库驱动器的额外关注，java.security.Provider
• 还有一些技巧（包括类文件的动态增强，但这通常是矫枉过正的）

底线：

---

泄漏是邪恶的。

Answer 4

是的，有更简单、更正确的方法来解决泄漏问题。将ClassLoader Leak Prevention库添加到您的项目中，它应该可以解决这个问题你！

如果您想自己追踪泄漏，这个博客系列将会有所帮助。

Answer 5

我会务实地解决这个问题：

1. 它是否会在生产环境中引起问题？
2. 您有足够的时间和资源来追踪它吗？

如果这两个问题的答案都是肯定的，那么一定要去做。如果一是，一否，可能由管理层决定，如果两者都不是，那就不用麻烦了。