1. OOM现象识别：应用挂起、日志报错、监控告警、用户反馈
OOM（Out of Memory）是 Java 后端服务中最致命的运行时故障之一。它不会突然“崩溃”，而是通过四种典型表象逐步暴露：应用挂起、日志报错、监控告警和用户反馈。本章从这四条线索出发，按问题排查六步法——现象识别 → 数据采集 → 原因定位 → 修复动作 → 复测 → 预防——建立完整的 OOM 识别与处置闭环。
1.1 现象识别
OOM 不会只以一种面貌出现。同一个 OOM 事件往往同时触发多条表象。下表列出四种表象的典型特征、发现渠道及紧急程度，帮助团队在第一时间做出准确判断。
| 表象 | 典型特征 | 发现渠道 | 紧急级别 |
|---|---|---|---|
| 应用挂起 | 请求无响应、线程 stuck、健康检查失败 | 负载均衡摘除、自愈脚本触发 | ★★★★★ |
| 日志报错 | java.lang.OutOfMemoryError、Java heap space、GC overhead limit exceeded | ELK/日志平台告警 | ★★★★☆ |
| 监控告警 | 堆内存使用率持续 >95%、GC 频率骤升、Full GC 时间 >10s | Prometheus + Grafana / APM | ★★★★☆ |
| 用户反馈 | 页面加载超时、操作无反馈、服务不可用 | 客服工单、舆情、SLA 报表 | ★★★★★ |
🔍 判断规则：当上述 4 种表象中同时出现 ≥2 种时，OOM 概率超过 85%；若同时出现“应用挂起”+“日志报错”，可直接进入 OOM 应急流程。
故障树：OOM 现象识别总图
下图以故障树形式展示从顶层“应用 OOM”到四种表象及具体表现的完整映射。每个叶子节点对应一条可观测的现场特征，排查时可根据叶子节点快速反推根因。
💡 现场保留铁律：一旦判定为 OOM，不要立即重启进程。先执行 jmap -dump:live,format=b,file=/tmp/heap.hprof <pid> 和 jstat -gcutil <pid> 2000 10 采集现场数据，再考虑恢复操作。
1.2 数据采集
锁定 OOM 嫌疑后，必须在分钟级时间内完成以下三项数据采集，否则一旦进程重启，现场证据将永久丢失。
| 采集项 | 命令/工具 | 关键信息 | 采集时机 |
|---|---|---|---|
| Heap Dump | jmap / jcmd / -XX:+HeapDumpOnOutOfMemoryError | 对象分布、大对象、泄漏嫌疑点 | OOM 发生后立即执行 |
| GC 日志 | -Xloggc:gc.log / jstat -gcutil | GC 频率、回收效率、晋升行为 | 持续采集（启动参数开启） |
| 线程 Dump | jstack / jcmd Thread.print | 线程状态、锁竞争、死锁 | OOM 发生时同步采集 |
⚠️ 常见陷阱：Heap Dump 文件大小通常等于堆大小，生产环境堆 8G 时 Dump 文件可能达 8G+。确保磁盘空间充足，建议挂载独立 dump 目录并监控使用率。
典型 OOM 日志示例（java.lang.OutOfMemoryError: Java heap space）：
2025-03-21T10:23:47.123+0800 [GC (Allocation Failure) -- 8192.0M->8192.0M(8192.0M), 0.523s]
2025-03-21T10:23:47.647+0800 [Full GC (Ergonomics) 8192.0M->6214.3M(8192.0M), 12.345s]
2025-03-21T10:23:47.648+0800 [GC (Allocation Failure) -- 8192.0M->8192.0M(8192.0M), 0.001s]
2025-03-21T10:23:47.649+0800 java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:133)
at com.example.service.ReportService.generateReport(ReportService.java:87)🔍 日志判断规则：如果日志中出现 OutOfMemoryError: Java heap space + 堆内存已满且 Full GC 无法回收（回收量 <5%），可 100% 确认是堆内存泄漏或堆配置不足。
1.3 原因定位
基于采集到的三份现场数据，使用故障树分析法（FTA）逐层排除，定位根因。下表列出最常见的 4 类 OOM 根因及对应判断特征。
| 根因类型 | 故障树路径 | Heap Dump 特征 | GC 日志特征 |
|---|---|---|---|
| 内存泄漏 | 日志报错 → 堆内存持续增长 → Full GC 无法回收 | 某类对象（如 HashMap、ThreadLocal）占 >60% 堆 | Full GC 后占用无明显下降 |
| 大对象分配 | 监控告警 → GC 频率突升 → 分配失败 | 单个数组/对象超过堆的 10% | 频繁 Allocation Failure，GC 时间短但频次高 |
| 线程泄漏 | 应用挂起 → 无法创建新线程 → 进程假死 | 线程对象数量异常多（数千个） | 无特殊 GC 异常，但线程栈溢出 |
| 类加载泄漏 | 用户反馈 → 热部署/动态加载后 OOM | ClassLoader 对象及关联类大量滞留 | Metaspace 持续增长，Full GC 无法回收 |
💡 快速定位技巧：使用 jhat 或 Eclipse MAT 打开 Heap Dump 后，直接查看 Biggest Objects 和 Leak Suspects 报告，MAT 会自动计算 GC Root 引用链，定位泄漏点精确到代码行。
1.4 修复动作
根据根因类型采取针对性修复。以下为四类标准修复动作及其操作示例。
| 根因 | 修复动作 | 命令/配置示例 | 预期效果 |
|---|---|---|---|
| 内存泄漏 | 修复代码中未释放的引用（如未关闭的 InputStream、ThreadLocal 未 remove） | try (InputStream in = new FileInputStream(path)) { ... } | Full GC 后堆占用降回基线 |
| 大对象分配 | 分页查询替代全量加载；超大报文拆包处理 | SELECT * FROM table LIMIT 1000 OFFSET :page | GC 频率降低 80% 以上 |
| 线程泄漏 | 使用线程池替代手动创建线程；限制最大线程数 | new ThreadPoolExecutor(10, 50, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100)) | 线程数稳定在池大小范围内 |
| 类加载泄漏 | 停止热部署时清除 ClassLoader；使用 -XX:+CMSClassUnloadingEnabled | -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled | Metaspace 不再持续增长 |
⚠️ 紧急止血：在代码修复完成前，可临时通过 增大堆内存 或 降低并发数 延缓 OOM 发生，但绝不能作为长期方案。临时调整参数：-Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200。
1.5 复测
修复完成后，必须通过以下三轮验证确认问题已闭环。
- 单元/集成测试：针对修复点编写用例，模拟 OOM 场景，确认不再触发 OOM。
- 压力测试：使用 JMeter 或 wrk 施压至原触发负载的 1.5 倍，持续运行 30 分钟，监控堆内存曲线是否平稳。
- 长时间运行验证：在预发环境部署修复版本，连续运行 48 小时，每 2 小时采集一次 GC 日志与堆使用率，绘制趋势图。
🔍 复测通过标准：
• 堆内存使用率波动范围 <20%，无持续上升趋势
• Full GC 频率 <1 次/小时，每次耗时 <2s
• 线程数稳定在正常值（如 Tomcat 线程池大小）
• 0 次 OutOfMemoryError 出现
1.6 预防
将单次 OOM 的排查经验转化为可复用的防御体系，避免同类问题再次发生。
| 预防措施 | 实施要点 | 工具/配置举例 |
|---|---|---|
| 启动参数固化 | 强制开启 Heap Dump 自动生成、GC 日志、OOM 后保留现场 | -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dump |
| 监控告警覆盖 | 堆内存使用率 >80% 警告，>90% 紧急；GC 暂停时间 >5s 告警 | Prometheus Rule：jvm_memory_used_bytes / jvm_memory_max_bytes > 0.9 |
| 代码审查清单 | 每次提交检查：流是否关闭、ThreadLocal 是否清理、大对象是否分页 | 结合 SonarQube 规则：java:S2095（流未关闭） |
| 容量规划 | 每季度根据业务增长评估堆大小，预留 30% 余量 | 基于峰值 QPS 的堆模型：堆 = 对象大小 * 并发数 * 1.3 |
| 定期演练 | 每半年执行一次 OOM 故障演练，检验应急响应速度 | Chaos Monkey 注入 OOM，验证自愈链路 |
💡 最佳实践：在 CI/CD 流水线中集成 Heap Dump 分析门禁——每次构建后自动分析 Dump 文件，若发现疑似泄漏模式（如单类占用超 50% 堆），直接阻断发布。