踩坑记录：一次生产环境 OOM 排查全流程复盘

2026年8月2日踩坑记录苏三

一、那个半夜的报警

某日生产环境突然大面积超时，监控显示 JVM 堆内存 100%，Full GC 每秒一次，服务几乎停滞。本文复盘完整排查链路。

二、第一步：确认是不是 OOM

# 看进程内存
top -p $(pgrep -f app.jar)
# 看 GC 频率
jstat -gcutil $(pgrep -f app.jar) 1000

EU/OU 接近 100% 且 FGCT 持续增长，基本锁定堆内存问题。

三、第二步：抓堆转储

# 自动在 OOM 时 dump（推荐提前加）
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof
# 或手动抓
jmap -dump:live,format=b,file=/tmp/heap.hprof $(pgrep -f app.jar)

四、第三步：用 MAT 分析

打开 Eclipse MAT，看 Dominator Tree，谁占的内存最多一目了然。本次发现 ConcurrentHashMap 里塞了几百万条缓存对象，且从不过期。

五、根因：缓存没设上限

代码里用普通 HashMap 做本地缓存，key 随时间无限增长。修复：

// 改用 Caffeine，带容量和过期
Cache<String, Data> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .build();