深夜告警：一次线上 OOM 的完整排查实录

上个月我们组有台服务半夜挂了，监控短信把同事从睡梦里叫起来，一看日志：java.lang.OutOfMemoryError: Java heap space这种情况我自己也遇到过不止一次，每次第一反应都是"先重启再说"。但重启完问题还在，过几个小时又挂，反复折腾。后来我整理了一套相对固定的排查流程，从保留现场到找到根因，基本上能在半小时内定位到问题。这篇就把这个过程完整记录下来，遇到 OOM 的时候可以对着查。一、先别乱动，第一步是保留现场很多人犯的第一个错误：立刻重启服务。重启确实能快速恢复，但 OOM 现场就消失了，下次还会再出现。正确姿势是在重启前先 dump 内存快照。如果服务还活着（内存耗尽但进程未退出）：#找到 Java 进程 PIDjps-l#或者ps-ef|grepjava生成堆转储文件（会有几秒卡顿，线上慎用，但值得）jmap -dump:format=b,file=/tmp/heap_dump.hprof更优雅的方式：提前配置自动 dump在启动参数里加上这两行，OOM 发生时 JVM 会自动生成 dump 文件：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/heap_dump.hprof强烈建议所有线上服务都加上这个配置，成本几乎为零，关键时刻救命用。二、快速判断：是哪种 OOM？Java 的 OOM 不止一种，报错信息不同，方向完全不一样：我这次遇到的是 Java heap space，最典型的一种，继续往下走。三、用 jstat 看 GC 状态，三秒摸清内存走势dump 文件通常比较大，分析需要时间。先用 jstat 快速看一眼 GC 情况：#每1秒输出一次GC统计，输出20次jstat-gcutilPID100020输出示例：S0 S1 E O M CCS YGC YGCT FGC FGCT GCT0.0099.12100.0097.8394.1291.233128.2344532.15640.3900.0099.12100.00