jakarta-ee - JBoss 7，java.lang.OutOfMemoryError : PermGen space

Question

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

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

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

Answer 1

由于多次重新部署后会发生这种情况，听起来您遇到了 classloader leak ，一种常见的 permgen leak .

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

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

JBoss AS 7 在其模块系统中有一些相当强大的规定来防止类加载器泄漏，所以我很惊讶您竟然成功触发了这一规定。自从我从 Glassfish 迁移到 AS7 以来，我还没有见过类加载器泄漏。

增加 MaxPermSize 可以为您赢得一些时间，但并不能解决问题。

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

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

如果您将原因缩小到捆绑在部署存档中的依赖项，则将其移至 JBoss AS 7 模块可能会解决该问题。为其创建一个 JBoss 模块，将其部署到 AS7 的 modules 目录，然后通过 Manifest.MF 或通过 将其依赖项添加到您的部署中jboss-deployment-struct.xml。请参阅documentation on the AS7 class loader .

这就是为什么 Project Jigsaw 被推迟的事实让我感到难过。 Java需要一个强大的模块系统来消除这些麻烦。