JVM OOM 不是把堆调大、重新启动、补一个监控阈值就结束了。话说回来，

一次合格的 OOM 复盘。至少要回答四个问题：

1. 到底是哪一种内存耗尽？其实，
2. 哪个业务动作或程序变化触发了它？
3. 为什么现有机制没有提前拦住？
4. 后续如何降低同类问题 发生的概率？

资深工程师和普通工程师的差别，往往不在于能不能看懂 heap dump而在于能不能把一次故障从“单点技术问题”还原成“容量、代码、流量、发布、监控、应急机制”的程序性问题。

问题背景 & 痛点直击

痛点1：只会盲目扩堆，根本看不清到底是哪里泄漏。其实，

痛点2：缺少现场数据。事后只能靠猜测，按理说，

痛点3：复盘过程碎片化。技术指标与业务行为脱节，

很多团队处理 OOM 的流程是：

• 报警出现 → 服务不可用 → 直接重启。不过，
• 恢复后把堆从 4G 调到 6G；再出现再调到 8G，…等业务不再报警，就认为解决了。

这种做法短期有效，却埋下更大的风险。OOM 是结果，不是原因。堆内存不足可能是正常增长后的容量不足。也可能是对象泄漏、批量任务失控、大查询返回过多、缓存无边界、线程堆积、直接内存耗尽，甚至一次看似无关的流量策略变化。

第一步先的观点是，先确认 OOM 类型。不要默认是堆

看到 OutOfMemoryError 时第一反应往往是 Java 堆不够。但 JVM 里的 OOM 不只有一种。其实，

常见类型一览

1. java.lang.OutOfMemoryError: Java heap space 至于典型原因。大对象、集合无限增长、缓存无淘汰、批处理一次性加载过多数据、对象无法被 GC 回收。不过，
2. java.lang.OutOfMemoryError: GC overhead limit exceeded 说明 JVM 大部分时间都在 GC。但回收效果很差，通常是堆空间不足或对象存活率过高的表现。其实，
3. java.lang.OutOfMemoryError: Metaspace 常见于类加载过多、动态代理生成类失控、热部署或插件化机制释放不完整。
4. java.lang.OutOfMemoryError: Direct buffer memory 经常出现在 Netty/NIO/压缩解压/文件传输/消息中间件客户端等场景。话说回来，仅看堆监控可能看不到异常。不过，
5. unable to create new native thread 不是 Java 堆里的对象太多。而是线程数或程序资源耗尽。根因可能是线程池配置错误、阻塞调用堆积或连接超时设置不合理。

关键：复盘第一步先不是“为什么堆不够”，而是“这次耗尽的是哪块资源”。 只有定位资源种类，后面的分析才有方向。

接下来这方面，保留现场。而不是只保留重启记录

痛点4：没有现场证据，只剩下“服务被杀了”。按理说，

The most valuable evidence appears at moment of OOM. Without it。post‑mortem analysis becomes pure speculation.

• 应用日志​
• GC 日志​
• -XX:+HeapDumpOnOutOfMemoryError/-XX:HeapDumpPath=…​
• 线程栈快照​
• Cgroup / 容器层面的内存/CPU/线程/文件句柄指标​
• 事故窗口内的发布记录、配置变更、定时任务和流量波动​

A robust emergency SOP should dictate:

1. #1 抓取线程栈；#2 保存完整 GC 日志；#3 导出 heap dump；#4 标记并归档所有关联日志；#5 再决定是否重启，

P.S.: 重启只是止血手段，不是复盘手段。怎么说呢，止血前后必须尽量保留能够解释问题的证据。

：用时间线把技术现象和业务行为对齐

Pain point 5：技术指标与业务动作分离导致根因难以定位。

If you only look at JVM side you’d conclude “objects are too many”. Adding business side reveals ***** those objects suddenly exploded.

The full chain should be:

说到第四步。定位对象来源，而不是只看最大对象

A common mistake is to stop at “ArrayList consumes X MB”. The deeper questions are:

• This object is still alive – ***?

从示例来看，

Heap dump shows a huge ArrayList.
Tracing its ref chain reveals:
- Excel export task loads millions of rows into memory
- Rows are converted to DTOs
- DTOs are stored in List before streaming to file
Root cause = Export logic lacks streaming & size limit.

The same applies to large caches – verify capacity limits,key cardinality,eviction policy effectiveness,and wher temporary user data is mistakenly cached in‑process.

从第五步来看。区分修复 / 缓解 / 治理 三类动作

可落地的 OOM 复盘模板

1. "故障概述"—发生时间、影响范围、使用者感知及恢复时长。按理说，

   * 故障概述 - 时间：2026‑08‑05 14:23 - 范围：order-service 所有查询接口超时 - 使用者感知：下单失败率 ↑12% - 恢复时间：14 分钟

   • OOM 类型 - Java heap space

   • 时间线 - 13:55 发布 v1.4.7 - 14:02 流量峰值 +28% - 14:10 Full GC 持续 ≥300ms …

   
   Each bullet must be accompanied by:
   • Evidence source
   • Owner responsible for verification
   The “改进项” section shall list concrete tickets。assignee and due date.
   

   常见错误做法

   说到错误一，只调大堆

   仅增大 Heap 会把 OOM 延后但根本泄漏仍然存在而且 Full GC 成本会随之提高。其实，

   说到错误二，只贴几张监控图

   监控图展示现象。却无法解释 为什么 对象激增。缺少业务维度导致分析碎片化。

   至于错误三。“怪罪个人”

   如果设计允许无限导出或缓存无限增长，即使代码写得再好也会触发 OOM。说起来，责任应当落在流程与防护上，而非单个人。

   错误四这方面，改进项太空洞

   “增加监控”“提高代码质量”“完善流程”这些描述不可执行。合格改进项必须具备 可验证 的验收标准。

   – 从事故到能力提高的闭环

   普通处理方式关注「怎么恢复」——扩容‑限流‑重启。l i> .l i l i l i

   • 用程序视角回答「为什么发生」「为什么未被提前发现」「为什么影响扩大」「下次如何更早拦住」。说起来，

   • 建立现场采集 SOP 、时间线分析模型 、对象来源追踪方法 、容量评估与治理闭环。让每一次 OOM 都成为团队成熟度提高的机会。