1. OOM问题本质与排查全景图

当Java应用突然崩溃并抛出"java.lang.OutOfMemoryError"时，就像飞行员突然看到油表归零——系统内存这个"油箱"已经见底。但不同于飞机的是，JVM提供了完整的"黑匣子"工具链让我们事后复盘。OOM的本质是JVM内存管理中对象分配失败，但背后诱因可能包括：

• 堆内存泄漏（对象无法回收）
• 内存配置不合理（Xmx设置过小）
• 非堆内存耗尽（Metaspace/直接内存）
• 系统资源限制（容器环境常见）

完整的排查需要结合现场快照和动态监控，典型工具链包括：

1. 即时诊断：Arthas（不重启Attach）
2. 内存分析：MAT/Eclipse Memory Analyzer
3. 监控基线：Prometheus + Grafana
4. 日志分析：GC日志 + 应用日志

关键认知：OOM不一定是代码Bug，可能是流量突增等正常场景。排查时需先确认是瞬时峰值还是持续增长。

2. 现场保留与初步诊断

2.1 必存的现场证据

当OOM发生时，按优先级保存以下数据：

1. 完整错误栈（包含OOM类型）
   • Heap OOM: "Java heap space"
   • Metaspace OOM: "Metaspace"
   • 直接内存OOM: "Direct buffer memory"
2. GC日志（需提前配置）

   -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log

3. 堆转储文件（自动生成配置）

   -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof

2.2 Arthas即时诊断

当无法立即重启服务时，使用Arthas进行在线诊断：

# 查看内存整体情况 dashboard -i 2000 -n 5 # 监控对象创建 monitor -c 5 org.example.LeakClass toString # 追踪类加载 trace *ClassLoader loadClass

典型异常特征：

• Old区使用率持续>80%且FullGC无效
• 某个类的实例数异常增长
• 线程栈中存在大量相同堆栈

3. 堆内存深度分析

3.1 MAT分析实战

使用Eclipse Memory Analyzer分析堆转储文件时，重点关注：

1. Dominator Tree视图
   • 找出占用最大的对象链
   • 注意"with incoming references"查看引用源
2. Leak Suspects报告
   • 自动检测的泄漏点
3. OQL查询

   SELECT * FROM java.util.HashMap WHERE size > 1000

3.2 典型内存泄漏模式

4. 非堆内存排查要点

4.1 Metaspace溢出

表现特征：

• 伴随"Metaspace"的OOM错误
• 频繁的FullGC（Metadata GC Threshold）

常见原因：

1. 动态类生成过多（如CGLib）
2. 重复加载同类（OSGi环境）
3. 反射滥用（MethodHandles）

解决方案：

-XX:MaxMetaspaceSize=512m -XX:+TraceClassLoading

4.2 直接内存泄漏

诊断方法：

1. NMT监控

   -XX:NativeMemoryTracking=detail jcmd <pid> VM.native_memory detail

2. 堆外分配检测

   // 示例：ByteBuffer泄漏 ByteBuffer.allocateDirect(1024); // 未显式释放

5. 生产环境防护体系

5.1 监控预警配置

推荐监控指标：

• JVM内存使用率（分区域）
• GC频率与耗时
• 对象创建速率
• 线程状态统计

Prometheus示例配置：

- pattern: 'jvm_memory_used_bytes{area="heap"}' name: 'jvm_heap_usage' thresholds: warning: 0.7 critical: 0.85

5.2 防御性编码规范

1. 资源管理原则

   // 反面示例 public void readFile() { FileInputStream fis = new FileInputStream("file.txt"); // 可能抛出异常导致未关闭 } // 正确写法 try (FileInputStream fis = new FileInputStream("file.txt")) { // 自动关闭 }

2. 缓存使用约束

   // 使用Guava的权重控制 Cache<String, Object> cache = CacheBuilder.newBuilder() .maximumWeight(1024 * 1024 * 100) // 100MB .weigher((key, value) -> calculateSize(value)) .build();

6. 进阶排查技巧

6.1 GC日志深度解读

关键日志模式分析：

[Full GC (Metadata GC Threshold) ...] [Times: user=1.23 sys=0.12, real=0.45 secs]

• user时间 > real时间：存在GC线程竞争
• 多次FullGC后内存不降：强引用泄漏

6.2 内存分配热力图

使用JFR定位分配热点：

-XX:StartFlightRecording=settings=profile jcmd <pid> JFR.dump filename=alloc.jfr

分析Allocation Sample事件中的调用栈。

7. 容器化环境特别处理

7.1 内存限制适配

Kubernetes环境常见问题：

• JVM未感知容器内存限制
• OOM Killer先于JVM触发

解决方案：

-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0

7.2 cGroup内存监控

容器内查看真实内存限制：

cat /sys/fs/cgroup/memory/memory.limit_in_bytes

需确保Xmx小于此值的80%。