Java HeapDumps 表明在 OutOfMemory 异常后使用的堆大小比实际堆定义小 30%

Question

在 JVM 抛出 OutOfMemory 后，我正在分析一些堆转储。异常(exception)情况。我在 Windows 2008R2 平台上使用 Hotspot JDK 1.7(64 位)。应用程序服务器是 JBoss 4.2.1GA，通过 Tanuki Java Service Wrapper 启动。 .

它是通过以下参数启动的:

wrapper.java.additional.2=-XX:MaxPermSize=256m
wrapper.java.initmemory=1498
wrapper.java.maxmemory=3000
wrapper.java.additional.19=-XX:+HeapDumpOnOutOfMemoryError

翻译为:

-Xms1498m -Xmx3000m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError

还有一些其他 GC 和 JMX 配置参数。

我的问题是当我分析由于 OutOfMemoryException 创建的堆转储时使用Eclipse Memory Analyzer ，MAT 总是显示堆大小为 2.3G 或 2.4G。我已经将 MAT 中的选项启用为 Keep Unreachable Objects ，所以我不相信 MAT 正在修剪堆。

java.lang.RuntimeException: java.lang.OutOfMemoryError: GC overhead limit exceeded

或

java.lang.OutOfMemoryError: Java heap space

MAT 中的摘要:

Size: 2.3 GB Classes: 21.7k Objects: 47.6m Class Loader: 5.2k

我的实际堆文件大小约为 3300KB，因此它们符合我的 3000m 最大堆大小设置。

那么MAT中缺失的500-600M内存去哪儿了？为什么 MAT 只显示我的堆大小为 2.4G？

SO 上的其他帖子倾向于表明 JVM 在转储堆之前执行了一些 GC，但如果丢失的 500M 是由于 GC 造成的，为什么它首先会抛出 OOM？如果 GC 实际上可以清理 500M(或者我的堆的近 25%)，那么 JVM 真的内存不足了吗？

有没有办法调整堆转储，以便我可以获得堆的完整/完整图片(包括丢失的 500M)？

如果没有，我发现我真的很难找到为什么会遇到这些 OOM。

根据某人的要求，我附上 jstat -gc <PID> 1000 的输出来自 Activity 节点:http://pastebin.com/07KMG1tr .

Answer 1

您使用的是哪种 GC？您可能缺少 Eden，请尝试使用 jstat - Java Virtual Machine Statistics Monitoring Tool