第1章：OOM故障现象识别 — 从错误日志到故障类型速判
OOM（OutOfMemoryError）是JVM最严重的故障信号。不同OOM类型对应完全不同的内存区域和根因，错误识别将直接导致排查方向跑偏。本章建立“现象识别 → 数据采集 → 原因定位 → 修复动作 → 复测 → 预防”全流程的第一环，训练你在10秒内从错误日志锁定OOM类型、判断紧急程度并启动正确的采集命令。
1. 现象识别：四大OOM错误特征速查表
JVM在内存区域耗尽或GC失效时会抛出java.lang.OutOfMemoryError，并在错误信息中携带具体区域标识。下表对比最常见的四种类型：
| 错误类型 | 错误信息关键字（日志中精确匹配） | 典型触发场景 | 紧急程度 |
|---|---|---|---|
| Java heap space | java.lang.OutOfMemoryError: Java heap space |
大对象分配、对象泄漏、堆过小 | 高（服务可能立即中断） |
| GC overhead limit exceeded | java.lang.OutOfMemoryError: GC overhead limit exceeded |
频繁Full GC但回收效果极差，吞吐量接近0 | 高（CPU飙升，服务接近挂起） |
| Metaspace | java.lang.OutOfMemoryError: Metaspace |
类加载器泄漏、动态类生成（CGLib/ASM）过多 | 中（服务不一定立即挂，但持续消耗） |
| Direct buffer memory | java.lang.OutOfMemoryError: Direct buffer memory |
NIO/Netty缓冲区未释放、配置不合理 | 中（伴随堆外内存持续上涨） |
实战避坑：不要在日志中只搜索“OutOfMemoryError”，必须精确匹配“Java heap space”或“GC overhead limit exceeded”等后缀，因为不同后缀的处理方案几乎完全不同。将GC overhead limit exceeded当成堆溢出处理（直接加堆大小）通常会恶化问题。
2. 故障树：OOM诊断决策流程
下面这张故障树引导你从错误信息出发，快速分流到对应的排查动作：
决策要点：错误信息中明确包含“Metaspace”时，不要采集 heap dump（对排查帮助不大），应优先抓取类加载器活动与 GC 日志。Direct buffer memory 则需额外关注 NIO 相关包引用。
3. 数据采集（第1步）：锁定类型后的快速取证命令
一旦通过错误信息确定 OOM 类型，立即执行对应的数据采集命令。犹豫越久，现场证据丢失越多。
通用日志定位：
# 搜索应用日志中的 OOM 记录（含前后10行上下文）
grep -n -C 10 "OutOfMemoryError" /path/to/app.log
按类型采集指导：
| OOM 类型 | 优先采集的数据 | 核心命令/参数示例 |
|---|---|---|
| Java heap space | Heap Dump、对象直方图 | jmap -dump:live,format=b,file=heap.hprof <pid> |
| GC overhead limit exceeded | GC 日志、CPU 栈、堆使用率 | jstat -gcutil <pid> 1000 5 |
| Metaspace | 类加载统计、Metaspace 容量 | jstat -gcmetacapacity <pid> |
| Direct buffer memory | 堆外内存映射、NIO 缓冲区 | pmap -x <pid> | grep anon |
4. 初步原因定位（日志模式匹配）
不同 OOM 类型的日志栈顶特征有明显差异，可直接指向问题组件：
- Java heap space + 栈顶为 HashMap/ArrayList： 优先怀疑数据缓存泄漏或请求体未释放。
- Java heap space + 栈顶为 Thread/Runnable： 优先怀疑线程栈分配过多或 ThreadLocal 泄漏。
- GC overhead limit exceeded + GC 日志中 Full GC 占比 >90%： 堆中大部分为不可回收对象（泄漏），或堆大小远小于存活集。
- Metaspace + 栈顶为 CGLib/ASM/反射： 优先检查动态代理、AOP 类生成逻辑。
- Direct buffer memory + 栈顶为 Netty/OIO： 优先检查缓冲区是否在 finally 中释放，或 NIO 配置是否正确。
5. 修复动作（第1章快速干预）
在深挖根因之前，以下动作可以帮助集群止血：
应急处置黄金规则：
1. 保留现场： 在重启前完成
2. 扩容隔离： 将问题实例从负载均衡摘除，避免流量持续触发 OOM。
3. 参数调整（临时）： 如果确认是 Metaspace 不足（非泄漏），可临时调大
注意： 调整参数前必须确认是“容量不足”而非“内存泄漏”，否则只会延缓问题而不会解决根因。
1. 保留现场： 在重启前完成
jmap -dump 和 jstack 采集（如果进程还能响应）。如果进程已挂，检查启动参数是否开启了 -XX:+HeapDumpOnOutOfMemoryError。2. 扩容隔离： 将问题实例从负载均衡摘除，避免流量持续触发 OOM。
3. 参数调整（临时）： 如果确认是 Metaspace 不足（非泄漏），可临时调大
-XX:MaxMetaspaceSize；如果是堆空间不足（非泄漏），可临时调大 -Xmx。注意： 调整参数前必须确认是“容量不足”而非“内存泄漏”，否则只会延缓问题而不会解决根因。
6. 复测与预防（第1章基线）
复测的核心在于验证“修复是否改变了 OOM 错误类型”或“是否完全消除了 OOM”：
- 复测触发条件：使用相同或更重的负载压测，观察错误日志是否重现。
- 预防基线：在监控系统中为各个内存区域设置告警水位线（如堆使用率 >85% 持续5分钟即告警）。
- 建立档案：记录每种 OOM 类型发生时的存活对象大小、GC 频率、类加载器数量等基线数据，用于比较后续变化。