导致 java.lang.OutOfMemoryError: PermGen space 错误的算法

Question

我在 Sun JVM (1.6.0_21-b06) 上遇到 PermGen 空间错误（好吧，这是 Oracle :)）。增加选项 -XX:MaxPermGen 值没有帮助。我知道 PermGen 是一个用于永久对象（例如类元数据）的空间。项目中的类数量不是很大~ 10 000。在崩溃之前，jvisualvm 显示 57MB 作为已使用的 PermGen。

我猜想某些算法占用了所有可访问的内存。有人知道导致 PermGen 溢出的算法示例吗？

UPD。我问这样抽象的问题，因为此刻我无法使用任何探查器 - 代码崩溃如此严重，以至于 jvisualvm 和 eclipse 停止响应。我需要使用kill -KILL {process_numer}从终端杀死java进程。我使用的是组织不良（但商业）的代码，其中包含许多线程和 JMS 消息传递。调试一团糟——我首先需要知道去哪里寻找。

Answer 1

与其说是算法，不如说是实现。这是一种非常愚蠢的方法来生成填充 PermGen 空间的随机字符串：

    Random rnd = new Random();
    List<String> interned = new ArrayList<String>();
    for (;;) {
        int length = rnd.nextInt(100);
        StringBuilder builder = new StringBuilder();
        String chars = "abcdefghijklmnopqrstuvwxyz";
        for ( int i = 0; i < length; i++ ) {
            builder.append(chars.charAt(rnd.nextInt(chars.length())));
        }
        interned.add(builder.toString().intern());
    }

简而言之：实习字符串是一种会耗尽 PermGen 内存的东西。

Answer 2

有两件事可能会导致 PermGen 空间问题：

1. String.intern(String) 方法在 PermGen 堆中创建字符串。如果您进行了大量的驻留操作并直接（或间接）保留对驻留字符串的引用，则可以填充 PermGen。

2. 类加载器在 PermGen 堆中创建 JVM 内部类描述符和代码段。如果您的应用程序执行大量动态类加载，并且类对象没有被垃圾回收，则可以填充 PermGen。

Java Web 应用程序的热重新部署依赖于动态加载，是 PermGen 问题的常见来源。根本原因通常是内存泄漏，涉及从某个对象到旧类加载器的隐藏引用。 （Tomcat 经常因此而“陷入困境”，但真正的问题通常是在正在重新部署的 Web 应用程序中。）

据我所知，@Michael Borgwardt 提到的 Proxy 案例也是 Proxy 实现生成类文件并将其加载到的结果苍蝇。

Answer 3

有人知道导致 PermGen 溢出的算法示例吗？

是的，但这有什么意义呢？如果您想修复此问题，请安装内存分析器工具（例如 jprobe 或 lambda 探针）并检查内存泄漏发生的位置，然后修复该问题。
现在举个例子：有数千种方法可以超过永久代空间。当我们继承一个使用 JMS 的应用程序时，我注意到一个项目。 jms 连接保持打开状态，应用程序在收到大量请求后几分钟内崩溃，并出现与您遇到的类似错误。需要注意的是：当我们从 jboss 迁移到 weblogic（迁移到 beajrockit）时，令人惊讶的是它自行修复了，或者至少承受了技术债务的打击。我的建议是无论如何，应该首先修复具有内存泄漏的错误代码，然后修补应用程序服务器和堆空间分配参数。

这是一个有用的链接，其中包含有关您收到的异常的一些信息。
http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang

编辑

这个链接可能有帮助
http://www.precisejava.com/javaperf/j2ee/JMS.htm

Answer 4

如果您使用 java.lang.reflect.Proxy< /a> 非常密集，这也可能会耗尽你的 PermGen 空间。

Answer 5

查看内存分析器 - http://www.eclipse.org/mat/。它是一个java转储内存分析器。在发生意外错误后，它非常有用。

Answer 6

您是否使用不同的垃圾收集器？

如果花费太多时间进行垃圾收集，吞吐量收集器将抛出内存不足异常。例如，如果 JVM 花费超过 98% 的总时间进行垃圾回收，并且只回收不到 2% 的堆，则会抛出内存不足的预期。此功能的实现在 1.5 中发生了变化。政策是相同的，但由于新的实施，行为可能会略有不同。” “在 J2SE 平台版本 1.5 中，将选择吞吐量收集器作为服务器类计算机上的垃圾收集器。” http://java.sun.com/docs/hotspot/gc5.0 /gc_tuning_5.html

检查 此页面。