java ClassLoader Leak -值得解决吗?

li9yvcax  于 2023-03-28  发布在  Java
关注(0)|答案(5)|浏览(135)

ClassLoader泄漏通常会导致 java.lang.OutOfMemoryError:PermGen。在应用程序服务器上工作的示例中,您可能会看到这是由于对公共应用程序进行了多次重新部署的结果。可以在这两个链接上看到对此问题的解释和可能的解决方案。(以及其他)
http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_javahttp://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/
现在大多数情况下,它们很容易解决。只需增加-XX:MaxPermSize,当不可避免的情况发生时,完全重新启动JVM。试图解决这个问题的问题是,在大型应用程序中,许多类可能导致类加载器泄漏,从而使类留在permgen中。
由此产生了两个问题:
是否可以合理地说,像这样的问题是更好地增加最大perm大小,并在必要时重新启动,或者应该找到一个解决方案是一个更高的优先级?
有没有更简单的方法来解决类加载器泄漏?

mrwjdhj3

mrwjdhj31#

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

mjqavswn

mjqavswn2#

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

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

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

qyswt5oh

qyswt5oh3#

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

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

底线:
泄密是邪恶的

dwbf0jvd

dwbf0jvd4#

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

ztmd8pv5

ztmd8pv55#

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

相关问题