JBoss 7,java.lang.OutOfMemoryError:PermGen空间

Question

我遇到了这个错误,其中CPU使用率达到极限,JBoss需要重启(java.lang.OutOfMemoryError: PermGen space).

我发现旧的JBoss版本的解决方案可以增加MaxPermSize.我想JBoss7也是如此.

为了不再遇到任何问题,哪个值足够好？有没有办法永久远离这个问题(比如让我们说使用像JRockit这样的其他虚拟机)？

Answer 1

由于这是在多次重新部署之后发生的,所以听起来你遇到了类加载器泄漏,这是一种常见的permgen泄漏.

这些可爱的野兽是由于从容器拥有的对象到从应用程序类加载器加载的类的实例的对象的正常(非弱)引用而发生的.如果在取消部署时没有清除这些引用,那么应用程序的类加载器仍然存在强大的引用链,因此无法进行GC并且无法释放已加载的类.

常见原因是容器类中的静态集合,其中添加了对应用程序类的非静态引用.

JBoss AS 7在其模块系统中有一些相当强大的规定,以防止类加载器泄漏,所以我很惊讶你已经设法触发了一个.自从我从Glassfish搬到AS7后,我没有看到类加载器泄漏.

增加MaxPermSize会给你带来一些时间,但它不会解决问题.

你真的需要解决为什么类加载器泄漏.这样做很有趣.您享受税收,间歇性故障和清洁淋浴,对吗？查看一些博客的第一个标题中的链接,这些链接将帮助您开始跟踪泄漏情况.基本上,您将需要使用VisualVM和OQL来挖掘对应用程序类加载器的引用,或者使用堆转储并使用jhat(JDK的一部分)来查找引用.无论哪种方式,我们的想法是通过应用程序类的实例确定从app服务器到类加载器的强引用链的位置.

或者,它可以帮助您获取应用程序的副本,然后开始从中删除位,直到泄漏消失.您可以通过将VisualVM或其他监视连接到应用服务器VM并观察PermGen在两个或更多部署/取消部署周期后是否增加来判断它是否泄漏.考虑自动化部署/取消部署周期.将泄漏的原因缩小到应用程序的一小部分和/或其中一个依赖项,并生成一个小的,独立的测试用例,然后将其作为错误报告提交给(a)JBoss AS 7,因为它是AFAIK它的意在阻止这种情况发生,以及(b)持有该参考的罪魁祸首.

如果将原因缩小到部署归档文件中捆绑的依赖项,则将其移动到JBoss AS 7模块可能会解决问题.为它创建一个JBoss模块,将其部署到modulesAS7目录,并通过您Manifest.MF或通过一个来为您的部署添加一个依赖项jboss-deployment-structure.xml.请参阅AS7类加载器上的文档.

这就是为什么Project Jigsaw被推迟的事实让我感到难过.Java 需要一个强大的模块系统来摆脱这种问题.

Answer 2

VM参数是:

-XX:MaxPermSize=256M

只要使它足够大,你就不会达到极限.

从广义上讲,perm gen memory用于与Classes和interned Strings相关联的对象.除非你使用了很多不同的类,否则你不应该用完.