在 -Xmx 选项设置为 4 GB 的 64 位操作系统中，Java 应用程序用完了大约 1.4GB 的堆空间

Question

在编写必须分配许多对象的应用程序时，我收到异常 java.lang.OutOfMemoryError: Java heap space。关于读书How to deal with “java.lang.OutOfMemoryError: Java heap space” error (64MB heap size)和 java.lang.OutOfMemoryError: Java heap space我尝试运行 java -jar myJar.jar -Xms1024m -Xmx4096m 命令，但应用程序崩溃，无论它分配了大约 1.457 GB。这是在 64 位 Win XP 框中。使用或不使用 -Xmx，崩溃时刻在 java.exe 进程的内存使用方面保持不变。 64 位应用程序不应该能够在 64 位操作系统中使用 4 GB 的 RAM 吗？

Answer 1

这是一个非常复杂的话题。没有一个简单的方案可以通过一个或两个参数来避免OOM。尽管如此，我们还是可以应用一些非常有用的概念和技术来解决问题。

事实上，您可以使用来自 OOM 的转储文件执行初始分析，方法是使用 -XX:-HeapDumpOnOutOfMemoryError 等参数。你的分析应该集中在哪一部分被用完了。是堆，还是烫发代？以及堆中的对象如何分布，例如发生 OOM 时最大对象/类的大小是多少。 MAT 等工具是一个很好的工具。

1. OOM 可能发生在堆中。

   将堆大小增加 -Xmx。 (看来这不适用于您的情况)。但是我建议您也将 -Xms 设置为 4G，以查看您是否有足够的内存并可以为您的 JVM 进程预留。如果您仍然可以遇到 OOM，则可能是碎片问题。这意味着，在分配和释放内存块的情况下运行了相当长的时间后，您的堆是碎片化的，并且没有大的连续空间用于大对象的分配请求。例如，如果堆中最大的连续空闲空间是 200M——尽管堆中的总空闲空间是 2G——并且如果你的应用程序请求一个大对象，比如一个大小为 250M 的数组，你就会遇到 OOM。启用 gc 日志并使用 GC 日志分析器可以为您提供这方面的信息。另请引用This blog以获得更好的理解和关于如何避免碎片化的建议。

2. 烫发区可能会发生OOM。

   将 perm 大小增加 -XX:MaxPermSize=384m。 Perm 表示用于类元数据和静态变量的区域。如果您的应用程序(或您的程序使用的库)加载大量类，或动态加载许多类，您可能需要更大的 perm 大小。如果增加大小不起作用，您可能会在类加载中出现泄漏。然后应使用 MAT 或内存泄漏检测器进行调查。

最后，不同的JVM品牌和版本在内存结构和参数上也有所不同。例如，”在 JDK 7 中，interned 字符串不再分配在 Java 堆的永久代中，而是分配在 Java 堆的主要部分(称为年轻代和老年代)，以及应用程序创建的其他对象。” 因此，请务必检查您正在使用的 JDK 版本的文档。