JBoss 7, java.lang.OutOfMemoryError: PermGen space [英] JBoss 7, java.lang.OutOfMemoryError: PermGen space

问题描述

我在 CPU 使用率达到极限并且 JBoss 需要重新启动时遇到了这个错误(java.lang.OutOfMemoryError: PermGen space).

I've hit this error where the CPU usage goes to its limits and JBoss needs a restart (java.lang.OutOfMemoryError: PermGen space).

我找到了一个针对旧 JBoss 版本的解决方案来增加 MaxPermSize.我想 JBoss7 也是如此.

I found a solution for older JBoss version to increase the MaxPermSize. I guess the same goes for JBoss7.

哪个值足够好以免再次遇到任何问题?有什么办法可以永久摆脱这个问题(比如可以说使用不同的虚拟机，比如 JRockit)?

Which value would be good enough in order not to face any problem again? Is there any way to get permanently away from this problem (like lets say use a different VM like JRockit)?

推荐答案

由于这种情况是在多次重新部署后发生的，因此您似乎遇到了 类加载器泄漏，一种常见的permgen 泄漏.

Since this happens after multiple redeploys it sounds like you've encountered a classloader leak, a common kind of permgen leak.

这些可爱的野兽的发生是因为从容器拥有的对象到作为从应用程序类加载器加载的类的实例的对象的正常(非弱)引用.如果在取消部署时未清除这些引用，则仍然存在指向应用程序类加载器的强引用链，因此无法对其进行 GC，并且无法释放已加载的类.

These lovely beasts happen because of normal (non-weak) references from objects owned by the container to objects that're instances of classes loaded from the application classloader. If those references aren't cleared on undeploy there's still a strong reference chain to the application's classloader, so it can't be GC'd and the loaded classes can't be freed.

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

A common cause is static collections in container classes that have non-static references to application classes added.

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

JBoss AS 7 has some fairly strong provisions in its module system to prevent classloader leaks, so I'm surprised you've managed to trigger one. I haven't seen a classloader leak since I moved to AS7 from Glassfish.

增加 MaxPermSize 会为您争取一些时间，但不会解决问题.

Increasing MaxPermSize will buy you some time, but it won't get rid of the problem.

您真的需要弄清楚类加载器泄漏的原因.这样做很有趣".您享受税收、间歇性故障和清洁淋浴，对吗?请参阅一些博客的第一部分中的链接，这些博客将帮助您开始跟踪泄漏.基本上，您需要使用 VisualVM 和 OQL 挖掘对您的应用程序类加载器的引用，或进行堆转储并使用 jhat(JDK 的一部分)来查找引用.无论哪种方式，我们的想法都是通过应用类的实例找出从应用服务器到类加载器的强引用链在哪里.

You really need to work out why the classloader is leaking. Doing this is "fun". You enjoy taxes, intermittent faults, and cleaning the shower, right? See the links in the first par for some blogs that'll get you started on tracking the leak down. Basically, you'll want to use VisualVM and OQL to dig for references to your app classloader, or take a heap dump and use jhat (part of the JDK) to find the references. Either way, the idea is to figure out where the strong reference chain from the app server to your classloader via instances of your app classes is.

或者，它可以帮助您复制您的应用程序，然后开始从中提取一些内容，直到泄漏消失.您可以通过将 VisualVM 或其他监控连接到应用服务器 VM 并观察 PermGen 在两个或多个部署/取消部署周期后是否增加来判断它是否泄漏.考虑自动化部署/取消部署周期.将泄漏的原因缩小到应用程序的一小部分和/或其依赖项之一，并生成一个小的、自包含的测试用例，然后将其作为 (a) JBoss AS 7 的错误报告提交，因为 AFAIK旨在阻止这种情况的发生以及 (b) 持有引用的罪魁祸首.

Alternately, it can help to take a copy of your app then start ripping bits out of it until the leak goes away. You can tell if it's leaking by connecting VisualVM or other monitoring to the app server VM and watching to see if PermGen increases after two or more deploy/undeploy cycles. Consider automating the deploy/undeploy cycles. Narrow down the cause of the leak to a small part of your app and/or one of its dependencies and produce a small, self-contained test case, then submit that as a bug report on (a) JBoss AS 7, since AFAIK it's meant to stop this happening and (b) the culprit that's holding the reference.

如果您将原因缩小到部署存档中捆绑的依赖项，将其移至 JBoss AS 7 模块可能会解决问题.为它创建一个 JBoss 模块，将它部署到 AS7 的 modules 目录，并通过你的 Manifest.MF 或通过一个 添加对它的依赖到你的部署中jboss-deployment-structure.xml.请参阅有关 AS7 类加载器的文档.

If you narrow the cause down to a dependency that's bundled inside your deployment archive, moving it into a JBoss AS 7 module may take care of the problem. Create a JBoss module for it, deploy it to the modules directory of AS7, and add a dependency on it to your deployment via your Manifest.MF or via a jboss-deployment-structure.xml. See the documentation on the AS7 class loader.

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

This is why the fact that Project Jigsaw has been deferred makes me sad. Java needs a strong module system that gets rid of this crud.

这篇关于JBoss 7, java.lang.OutOfMemoryError: PermGen space的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！