JBoss 7，java.lang.OutOfMemoryError：PermGen空间 [英] 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)?

推荐答案

因为这个在多次重新部署之后发生这听起来就像你遇到了 classloader leak ，一种常见的 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的模块目录，并通过 Manifest.MF <为您的部署添加依赖项。 / code>或通过 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.

这就是为什么Project 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空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！