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

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。尝试解决此问题的问题在于,在大型应用程序中,许多类可能导致类加载器泄漏,从而导致类保留在 permgen 中。

由此产生了两个问题:

是否可以合理地说,像这样的问题最好只是增加最大烫发大小并在必要时重新启动,或者应该找到更高的优先级?

有没有更简单的方法来解决类装入器泄漏?


答案 1

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

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


答案 2

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

如果问题仅存在于测试服务器中,则可能会将其视为不值得努力解决而忽略。

如果问题出在生产服务器中,则需要解决方案或解决方法。解决方案是艰苦的工作,但解决方法可能工作量更少:

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

  • 解决方法 #2 - 定期完全重新启动生产服务器,以避免 permgen 空间不足。将此与增加烫发空间相结合。

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

如果您处于没有测试环境的位置,并且经常对生产机器进行热部署以最大限度地减少停机时间,那么您就是在薄冰上滑冰。您最终可能会犯一个错误,导致损坏,这需要很长时间才能从...


推荐