没有 GC 历史的 OutOfMemory 线程转储答案

【问题标题】：OutOfMemory thread dump without GC history没有 GC 历史的 OutOfMemory 线程转储
【发布时间】：2013-07-19 14:20:57
【问题描述】：

通常在 OutOfMemoryError 之后生成的线程转储包含有关最后几个垃圾收集器周期的信息（GC 历史记录 部分）。但是我有 OutOfMemory 线程转储没有这些信息。

1STGCHTYPE     GC History  
NULL           
NULL           ------------------------------------------------------------------------
0SECTION       LOCKS subcomponent dump routine
NULL           ===============================

环境：IBM WebSphere 7.0.0.19

有人知道为什么这个转储没有这些信息吗？ GC 根本没有启动？

【问题讨论】：

也许，您可以尝试jstack [java pid] 获取更多信息？
IBM JVM 没有这个实用程序，但我有关于在创建的线程转储中运行线程的信息。我应该调查哪些线程？
部分答案：为了确保 GC 在您的情况下的行为方式（以及一般监控 GC 历史记录），最好设置-verbose:gc 并检查nativestdErr.log 了解详细信息，这会显示更多详情。

标签： java memory-leaks garbage-collection websphere out-of-memory

【解决方案1】：

如果您的程序一次性请求足够大的内存（例如大型数组分配等）而 JVM 无法满足，则会发生这种情况。

【讨论】：

【解决方案2】：

在这种情况下，您应该查看 JVM 与转储一起生成的 Snap.*.trc 文件。这是一个二进制文件，但 IBM 提供了一个 tool 来解码该跟踪文件。

上次我看到没有 GC 历史记录的 javacore 文件，那是因为 OutOfMemoryError 不是由堆（或本机内存）饥饿触发，而是由过多的垃圾收集开销触发。这在跟踪文件中已明确指出。

【讨论】：

在解析的跟踪文件中应该如何准确地指出？
我没有保留跟踪文件，因此无法向您提供确切的信息。无论如何，如果 JVM 决定生成转储，那么跟踪文件会提及原因。