第一步保留现场别急着重启很多人一收到OOM告警第一反应是重启服务恢复业务。这没错业务优先。但重启之前必须把现场留下来。用jmap -dump:live,formatb,fileheap.hprof pid抓取堆快照同时用jstat -gcutil pid 1000持续观察GC状态再把GC日志、监控曲线、线程栈全部归档。重启只能掩盖问题现场才是破案的关键。没有dump文件后面的分析就是无米之炊。亡羊补牢补的是代码不是重启。第二步GC日志是尸检报告拿到GC日志后用GCEasy或GCViewer分析。重点看三个指标Full GC频率、老年代回收效果、单次停顿时间。如果Full GC后老年代占用几乎不降说明有对象一直被强引用典型的内存泄漏。如果Young GC极其频繁且对象晋升老年代速度很快可能是新生代太小或者有大对象直接进入老年代。GC日志不会说谎它忠实记录了堆内存的每一次呼吸。看不懂GC日志就永远在OOM面前当瞎子。第三步堆dump分析顺藤摸瓜用MAT打开hprof文件先看直方图哪个类的实例数量最多、占用内存最大。再看支配树找到持有这些对象的GC Root。常见的泄漏元凶就那么几类静态集合类只增不减、ThreadLocal用完不remove、数据库连接或流未关闭、本地缓存没有淘汰策略。找到GC Root到泄漏对象的引用链就找到了元凶。这一步需要耐心但方向对了剩下的就是时间问题。第四步结合代码对症下药工具告诉你“是什么”代码告诉你“为什么”。拿到可疑对象后看它的类名和字段回溯代码里哪里创建、哪里添加、哪里移除。用Arthas的watch或trace动态追踪方法的调用参数和返回值。比如发现某个HashMap无限增长就查是谁在put却从不remove。工具是放大镜代码才是病灶。不看代码只调参数是治标不治本。第五步修复验证形成闭环定位到根因后修复方案无非三种代码修复泄漏点、调整堆大小和GC参数、优化对象生命周期。修复完必须压测验证观察Full GC是否消失、老年代占用是否稳定、TP99是否达标。没有验证的修复等于没修。把这次OOM的现象、工具、分析、决策、结果整理成案例下次面试直接讲比背十道八股文管用。面试怎么答才算到位按“保留现场→分析GC日志→分析堆dump→定位代码→修复验证”五步走每一步带上具体工具和关键指标。再补一个你亲手处理过的真实案例讲清楚现象、排查路径和最终效果。面试官要的不是标准答案是你脑子里有没有一张排查地图。把这张地图画出来offer自然来。