JVM 究竟何时抛出 OutOfMemoryError

Question

我们正在运行一个有时会“冻结”的 Java 应用程序，因为某些线程正在使用几乎所有的堆。 尽管 JVM 执行的 Full GC 持续超过 60 秒，但应用程序永远不会因 OutOfMemoryError 而死。

我从 Java 文档中读到：

如果花费太多时间进行垃圾收集，吞吐量收集器将抛出内存不足异常。 例如，如果 JVM 花费超过 98% 的总时间进行垃圾收集并且回收不到 2% 的堆，它将引发内存不足的预期。

我想了解更多关于这 98% 的时间意味着什么的信息（时间框架是多少？），以及是否可以降低这个值，即如果应用程序在 GC 中花费了 90% 的时间，则抛出 OOME并且不能释放超过 10% 的堆。

我们的目标是确保应用程序会因 OOME 而死（而不是只运行 GC），以便我们可以在 OOME 上生成转储。

以下是我们使用的内存和 GC 设置（操作系统是 Solaris）：

-Xms2048m -Xmx2048m \
-Xmn512m \
-XX:PermSize=256m 
-XX:MaxPermSize=256m \
-XX:+UseParNewGC 
-XX:ParallelGCThreads=16 \
-XX:+UseConcMarkSweepGC 
-XX:+CMSParallelRemarkEnabled \
-XX:+DisableExplicitGC \
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps \
-XX:+PrintClassHistogram \
-Xloggc:/gcmonitor.log \
-XX:+HandlePromotionFailure \
-XX:SurvivorRatio=4 
-XX:TargetSurvivorRatio=90 
-XX:MaxTenuringThreshold=10 \
-XX:+UseTLAB 
-XX:TLABSize=32k 
-XX:+ResizeTLAB \
-XX:+UseMPSS \

Answer 1

我想了解更多关于这 98% 的时间意味着什么的信息（时间范围是多少？）

这个问题的答案：GC overhead limit exceeded 建议是 1 分钟。

可以降低这个值

再次查看上述问题，看来您可以使用GCTimeLimit 和GCHeapFreeLimit 参数。

Answer 2

如果您只是希望强制 OOM 获得堆转储的附带好处，您现在可以随时在正在运行的 java 进程上执行此操作：

查找进程：

jps -v

强制转储

jmap -dump:file=heap.bin

然后在您选择的工具中分析 heap.bin。

Answer 3

在 OOME 上或使用 jmap 以交互方式进行堆转储可能会导致 JVM 暂停几分钟。通常使用 gcore 手动创建核心转储，然后使用 jmap 从核心获取堆转储更有效。

我会分配更多堆，看看这是否有助于缓解问题。还要注意过度的 GC 调整 - 通常收集器具有出色的默认值，如果您确定这些选项基于应用程序的对象分配/保留模式显着提高了 GC 性能，我只会推荐 Xloggc 之后的选项。并行收集器线程也可能太高，具体取决于可用硬件线程的数量。

您应该能够从 GC 日志中确定堆使用的模式，并确定这是单个线程的快速使用、执行快速耗尽堆的操作，还是一个较慢的“泄漏”模式，其中有许多对象随着时间的推移被提升，导致终身代被竞争，几乎没有候选对象可供收集 - 直方图也会有所帮助。

综上所述，专注于堆转储绝对是要走的路。 Eclipse MAT 是 IMO 最好的分析工具。如果您以前没有使用过它，这里是一个很好的起点：

http://kohlerm.blogspot.com/2009/07/eclipse-memory-analyzer-10-useful.html