ClassLoader泄漏 - 他们值得解决吗？

Question

ClassLoader泄漏通常会导致java.lang.OutOfMemoryError:PermGen.在处理应用程序服务器的过程中,您可能会看到这是许多重新部署常见应用程序的结果.可以在这两个链接上看到对此问题的解释和可能的解决方案.(其中包括)

现在大部分时间他们很容易绕过.只需增加-XX:MaxPermSize,当不可避免的情况发生时,完全重启JVM.尝试解决这个问题的问题是,在大型应用程序中,许多类可能导致类加载器泄漏,因此类仍然保留在permgen中.

由此产生两个问题:

是否合理地说这样的问题更好地增加最大烫发大小并在必要时重新启动或者应该找到更高优先级的解决方案？

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

Answer 1

它实际上取决于应用程序,或者更确切地说,取决于所使用的部署过程.许多应用程序只在开发期间进行了重新调整,新版本每隔几个月发生一次,并且应用程序服务器因其他原因重新启动,远远超过部署应用程序.在这种情况下,追逐Classloader泄漏是浪费时间.

当然,如果您计划实施持续部署过程,尤其是在高可用性环境中,那么Classloader泄漏是您真正需要解决的问题.但是,在成为问题之前,还有许多其他事情需要比大多数项目做得更好.

Answer 2

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

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

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

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

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

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