Java OOM 排查操作参考：从告警到根因，MAT 堆分析全流程实战

全局流程图

告警：CPU % / 服务卡死 / OOM 报错
│ ├─ 第一步先：判断是不是 OOM
│ ├─ FGC 暴增、FGCT 耗时长 → 大概率 OOM → 继续
│ └─ GC 正常 → 不是 OOM。走 CPU 排查方法
│ ├─ 接下来：确认 OOM 类型
│ ├─ Java heap space / GC overhead → 方向 A
│ ├─ Metaspace → 方向 B
│ ├─ Direct buffer memory → 方向 C
│ └─ unable to create native thread → 方向 D
│ ├─ 然后：按方向选择工具和排查方法
│ └─ 第四步：MAT 分析 hprof，三步法定位根因

说到第一阶段，从现象发现 OOM

线上最常见的 OOM 场景不是“直接看到 OutOfMemoryError 日志”，而是服务突然卡死或 CPU 飙到 %。因为 OOM 后 JVM 会疯狂做 Full GC 尝试回收内存。GC 线程吃满 CPU，业务线程几乎停滞。

说到第一个命令，jstat

jstat -gcutil

至于输出示例。

 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT…，…，

看什么列？其实，

判断标准：

• 'FGC' 在几分钟甚至几小时出现一次每分钟>10 次即为潜在泄漏；
• 'FGCT' 占比>5% 或单次耗时>1s，则极可能即将触发 OutOfMemoryError；话说回来，
• 'E' 老年代使用率>80% 且 Full GC 后未下降。 则老年代存在泄漏，
• 'M' Metaspace 占用率>80%，提示类元数据溢出。

如果确认是 OOM → 进入第二阶段。如果 GC 正常 → 非 OOM，走 CPU 排查方法。话说回来，

第二个命令这方面。jmap -heap

确认是 OOM 后先看堆整体配置和各代使用情况：

jmap -heap

Heap Configuration:
MaxHeapSize = ← -Xmx
NewSize = ← 年轻代
MaxNewSize =
OldSize = ← 老年代
MaxMetaspaceSize =
Heap Usage:
PS Old Generation
capacity =
used =
% used ← 危险信号！...

至于主要看什么，

• -Xms/-Xmx 太小堆不够。用频繁 GC 把性能拖垮；-Xmn 太小直接晋升老年代；-XX:MaxMetaspaceSize 太小导致 Metaspace OOM；-Xss 较大+线程多会占程序栈空间。
• If 配置明显不合理。请先调参，再做代码分析，
• ⚠️ jmap -heap 在 JDK + 中被 'gc.heap_info'

   ...
  

   ...