阶段一：事前预防与基础配置（未雨绸缪）
在 OOM 发生前，必须做好以下基础配置，否则排查将寸步难行：
- 配置 OOM 自动快照：在 JVM 启动参数中加入以下配置，确保 JVM 崩溃时能自动保留“犯罪现场”：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/你的日志路径/heapdump.hprof
- 搭建监控与告警体系：通过 Prometheus + Grafana 等工具监控 JVM 核心指标。设置合理的告警阈值（例如：老年代使用率 > 80%、Full GC 频率 > 1次/小时），在 OOM 真正发生前收到预警。
阶段二：紧急止损与保留现场（黄金5分钟）
当线上服务出现 OOM 告警或响应卡顿时，按以下顺序操作：
- 保留现场（第一优先级）：
- 如果服务还没完全崩溃，立刻手动导出堆快照：
jmap -dump:live,format=b,file=/tmp/heap_oom.hprof <pid>。 - 注意：导出快照会触发 Full GC 并导致服务短暂卡顿（STW），但为了定位问题这是必须的。如果服务已完全卡死无法导出，只能依赖“阶段一”中配置的自动快照。
- 如果服务还没完全崩溃，立刻手动导出堆快照：
- 重启恢复业务：现场保留后，立即重启服务以恢复线上业务可用性。
- 临时扩容（可选）：如果业务压力极大，在重启时可临时调大堆内存参数（如
-Xmx）作为过渡，为后续排查争取时间。
阶段三：定位根因与深度分析（抽丝剥茧）
拿到堆快照（.hprof）和 GC 日志后，开始离线分析：
- 确认 OOM 类型：查看异常日志，明确是堆内存（
Java heap space）、元空间（Metaspace）、还是直接内存（Direct buffer memory）溢出。 - 分析堆快照（核心步骤）：
- 使用 Eclipse MAT 或 JProfiler 打开
.hprof文件。 - 查看 Dominator Tree（支配树）：按深堆（Retained Heap）降序排列，找出占用内存最大的前几个对象。
- 查看 Leak Suspects（泄漏疑点报告）：工具会自动给出最可疑的内存泄漏点。
- 使用 Eclipse MAT 或 JProfiler 打开
- 追踪引用链：
- 右键点击可疑的大对象，选择
Path to GC Roots -> with all references。 - 分析是谁（例如某个静态的
HashMap、未关闭的线程池或监听器）强引用了这些对象，导致 GC 无法回收。
- 右键点击可疑的大对象，选择
- 结合 GC 日志分析：观察 OOM 发生前，Full GC 是否频繁触发，且每次回收后内存下降不明显（说明存在大量顽固的存活对象）。
阶段四：修复方案与验证上线（对症下药）
根据分析出的根因，采取针对性的修复措施：
| 根因分类 | 常见场景 | 修复方案 |
|---|---|---|
| 代码内存泄漏 | 静态集合无限增长、ThreadLocal 未 remove、资源未关闭 | 优化代码逻辑，增加清理机制，使用 try-with-resources，改用带淘汰策略的缓存（如 Caffeine）。 |
| 大对象加载 | 一次性查询全表数据、大文件/Excel 导出 | 改为分批/分页处理（如 MyBatis 游标）、流式处理（Stream）。 |
| JVM 参数不当 | 堆内存或元空间本身设置过小 | 合理调大 -Xmx、 -XX:MaxMetaspaceSize等参数。 |
验证上线：
- 本地/预发验证：修复代码后，在测试环境模拟高并发或大数据量场景，观察内存曲线是否平稳。
- 灰度发布：先在小部分节点上线，配合监控平台观察内存和 GC 指标，确认无异常后再全量发布。
阶段五：复盘与长效预防（亡羊补牢）
- 完善监控看板：将本次 OOM 的特征指标（如特定缓存的大小）加入日常监控大盘。
- 代码规范落地：在团队内同步此次故障，将“禁止无上限静态集合”、“大对象必须分页”等纳入代码评审（Code Review）的必查项。
- 定期巡检：定期（如每月）使用 MAT 扫描预发环境的堆快照，提前发现潜在的内存泄漏隐患。
附录 A：常见 OOM 异常类型速查表
| 异常类型 | 常见原因 | 核心解决方向 |
|---|---|---|
| Java heap space | 内存泄漏、一次性加载数据量过大 | 分析 Heap Dump，修复泄漏代码或分批处理数据 |
| GC overhead limit exceeded | GC 耗时超过98%但回收不到2%内存 | 本质也是堆内存不足，优先排查内存泄漏 |
| Metaspace | 动态代理类过多、类加载器泄漏 | 检查 CGLib/ASM 动态生成类逻辑，调大 -XX:MaxMetaspaceSize |
| Unable to create new native thread | 线程数超限、线程池配置不当 | 使用 jstack分析线程，限制线程池大小，检查 ulimit -u |
| Direct buffer memory | NIO 直接内存泄漏（如 Netty 使用不当） | 检查 ByteBuffer是否正确释放，调整 -XX:MaxDirectMemorySize |
附录 B：容器化环境（K8s/Docker）排查要点
在现代微服务架构中，Java 应用常部署在容器内，排查 OOM 时需额外注意以下几点：
- 区分 JVM OOM 与 OS OOM Kill：
- 如果容器日志中没有
java.lang.OutOfMemoryError，但 Pod 频繁重启，很可能是被操作系统的 OOM Killer 强杀了。 - 可以通过
kubectl describe pod <pod-name>查看 Pod 事件，如果Reason为OOMKilled，则说明是容器内存超限。
- 如果容器日志中没有
- JVM 内存与容器限制的对齐：
- JDK 8u191 之前的版本无法自动识别容器的内存限制（Cgroup），可能会错误地使用宿主机的内存作为基准，导致实际占用远超容器配额。
- 解决方案：务必在启动参数中开启容器感知，并设置合理的堆内存占比。例如：
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0
这表示 JVM 最大堆内存将自动设置为容器内存限制的 75%，为元空间、线程栈等预留出足够的安全余量。
评论区