Java类（PermGen）内存泄漏（Web应用程序） - 通用解决方案？ [英] Java Class (PermGen) Memory Leak (Web Applications) - Generic Solution?

问题描述

我知道，我有一个烫发内存泄漏。使用jvisualvm进行分析表明，在进行热部署时（例如在不杀死JVM的情况下停止和启动应用程序，在tomcat，WebSphere，WebLogic等中） - PermGen空间不断增加。

<阅读后，使用jhat和其他高级工具，我意识到我可能从其父类加载器中的某个类的 WebAppClassLoader 引用。

即使我在jhat上进行了一些基于JavaScript的大规模查询，我仍无法确定它的结果。

找出谁负责你的类加载器不被垃圾收集（从而允许垃圾回收由它加载的类）的实用程序？

我试过JProfiler，jvisualvm，jhat和很多Google

给所有LMGTFY朋友 - 我花了大约一天半的时间阅读论坛，逐步说明，没有运气。我正在寻找一个输出的实用程序或代码：

类Y的对象X是唯一保留您的类不被删除的GC根。

解决方案

有一个令人无法满足但很容易的解决方案：不要在生产环境中进行热部署。您可以设置两个servlet容器的集群，并且每次更新一个，并重新启动。

I have a perm gen memory leak, that I know. Profiling using jvisualvm shows that when doing hot deployment (e.g. stop and start an application without killing the JVM, in tomcat, WebSphere, WebLogic etc) - the PermGen space is constantly increasing.

After reading, using jhat, and other advanced tools I realized that I probably have a reference to the WebAppClassLoader from a class somewhere in its parent class loaders.

I couldn't pin it down even though I did some massive JavaScript based queries on jhat

Isn't there a simple utility that finds out who is responsible for you class loader to not be garbage collected (thus allowing garbage collection of classes loaded by it)?

I tried JProfiler, jvisualvm, jhat, and a lot of Google

to all the LMGTFY friends - I've spent about a day and a half reading forums with step by steps instructions, no luck. I'm looking for a utility or code that outputs:

Object X of class Y is the sole GC root that keeps your classes from being removed.

解决方案

There is an unsatisfiying but easy solution: Don't hotdeploy in production environments. You could setup a cluster of two servlet containers and them update one at a time with a restart.

这篇关于Java类（PermGen）内存泄漏（Web应用程序） - 通用解决方案？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！