Java 类 (PermGen) 内存泄漏（Web 应用程序）- 通用解决方案？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1996088/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java Class (PermGen) Memory Leak (Web Applications) - Generic Solution?
提问by Eran Medan
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.
我知道，我有一个 perm gen 内存泄漏。使用 jvisualvm 进行分析表明，在进行热部署时（例如，在不杀死 JVM 的情况下停止和启动应用程序，在 tomcat、WebSphere、WebLogic 等中） - PermGen 空间不断增加。
After reading, using jhat, and other advanced tools I realized that I probably have a reference to the WebAppClassLoaderfrom a class somewhere in its parent class loaders.
在阅读、使用 jhat 和其他高级工具后，我意识到我可能WebAppClassLoader在其父类加载器的某处引用了来自类的引用。
I couldn't pin it down even though I did some massive JavaScript based queries on jhat
即使我在 jhat 上做了一些基于 JavaScript 的大量查询，我也无法确定它
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
我尝试了 JProfiler、jvisualvm、jhat 和很多谷歌
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:
致所有 LMGTFY 的朋友 - 我花了大约一天半的时间阅读论坛，并按步骤进行说明，但运气不佳。我正在寻找输出的实用程序或代码：
Object X of class Y is the sole GC root that keeps your classes from being removed.
类 Y 的对象 X 是防止您的类被删除的唯一 GC 根。
采纳答案by user242772
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.
有一个不太令人满意但很简单的解决方案：不要在生产环境中进行热部署。您可以设置一个由两个 servlet 容器组成的集群，它们通过重新启动一次更新一个。
回答by julius
The realities of frequent redeployments... Best you can do is increase the size of perm gen using -XX:MaxPermSize=256m. This may buy you some redeployments more per jvm restart. Or read on at http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back
频繁重新部署的现实......你能做的最好的事情是使用 -XX:MaxPermSize=256m 增加 perm gen 的大小。这可能会在每次 jvm 重启时为您带来更多的重新部署。或继续阅读http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back
Beware that if the classloaders can't be gc-ed at all, fiddling with the jvm won't help at all. You'd better forget about frequent deployments, especially in production, for dev it's handy, nevertheless.
请注意，如果类加载器根本无法进行 gc-ed，那么摆弄 jvm 根本无济于事。你最好忘记频繁的部署，尤其是在生产中，但是对于开发来说它很方便。
回答by Sana
I used the method from this site and it helped. http://www.mkyong.com/tomcat/tomcat-javalangoutofmemoryerror-permgen-space/
我使用了这个网站的方法，它有帮助。 http://www.mkyong.com/tomcat/tomcat-javalangoutofmemoryerror-permgen-space/
回答by MM.
Few pointers here as well, http://minmaxmim.blogspot.com/2010/01/javalangoutofmemoryerror-java-heap.html
这里也很少有指针， http://minmaxmim.blogspot.com/2010/01/javalangoutofmemoryerror-java-heap.html
also check the javalangoutofmemoryerror-permgen-space article.
另请查看 javalangoutofmemoryerror-permgen-space 文章。
