企业级java内存故障排查需建立“现象→证据→定位→验证”闭环工作流：一查gc日志确认老年代持续上涨及full gc异常；二在老年代85%+时抓多时间点堆转储；三用mat聚焦静态集合、threadlocal等四类强引用泄漏；四代码验证修复并补监控。
企业级 Java 应用内存故障排查不能靠零散命令堆砌，而要建立可复现、可回溯、可传承的闭环工作流。核心是把“现象→证据→定位→验证”四步拧成一条逻辑链，避免跳过确认环节直接 dump、或只看 MAT 报告不验证引用链真实性。
第一阶段：用 GC 日志锚定泄漏真实性
不看日志就动手 dump，等于没确诊就开刀。必须确认三点：
- 老年代（Old Gen）使用率是否持续缓慢上升，且每次 Full GC 后回收量＜20%，回收后水位不回落
- Full GC 频次是否从小时级加速到分钟级，单次耗时是否稳定＞1s
- 排除干扰项：元空间（Metaspace）或直接内存（DirectByteBuffer）同步增长，说明可能不是纯堆泄漏，需切换排查方向
第二阶段：在关键时间点抓有效堆转储
dump 不是越早越好，也不是等 OOM 才做：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 推荐在连续两次 Full GC 之间、老年代占用率达 85% 以上时执行：jmap -dump:live,format=b,file=heap_85p.hprof
（加 live 参数避免导出已标记但未回收对象） - 禁止在 GC 高峰期或系统卡顿瞬间 dump，易导致进程假死；生产环境优先用 -XX:+HeapDumpBeforeFullGC JVM 参数自动捕获前哨快照
- 一次排查至少保留 3 个时间点的 dump（如泄漏初期、中期、临近 OOM 前），用于比对对象增长趋势
第三阶段：MAT 分析聚焦四类高危引用模式
MAT 不是用来找“最大的对象”，而是找“不该活这么久却一直被强持”的对象：
- 先看 Leak Suspects Report —— 它常能直指静态 Map、ThreadLocalMap 或未注销监听器
- 再查 Dominator Tree，按 Retained Heap 排序，对 top 5 对象右键 → Path to GC Roots → 勾选 exclude weak/soft references，只看强引用链
- 重点盯四类结构：静态集合（尤其是 static Map/List）、ThreadLocal 持有业务对象未 remove()、单例中缓存无淘汰策略、注册监听器后未 unregister()
第四阶段：代码层验证与修复闭环
分析结论必须落到可执行、可验证的代码动作上：
- 找到嫌疑对象后，反查其创建和持有位置：是否在 Filter/Interceptor 中塞入 ThreadLocal？是否在 @PostConstruct 初始化了静态缓存但没配定时清理？
- 修复后必须验证：上线新版本，用 jstat 观察老年代水位是否回归周期性波动（而非单边上涨），Full GC 频次回到基线
- 补监控卡点：在关键静态容器上埋点（如 size() 计数 + lastModified 时间戳），接入 Prometheus 告警，避免同类问题重复发生
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
