jmap三步锁定java内存泄漏源头：先用jmap -histo:live 识别异常存活对象，再用jmap -dump:live,format=b,file=heap.hprof 生成精准堆转储，最后通过mat分析gc roots强引用链定位泄漏根因。
Java 内存持续增长，不能只看 top 的 RES 值，得确认是不是堆内对象真在累积。jmap 是 JDK 自带的轻量级工具，不用装额外组件，三步就能快速聚焦问题源头：先查对象分布、再抓堆快照、最后定位强引用链。
第一步：用 jmap -histo 快速识别异常对象
执行 jmap -histo:live
- 重点关注前三类：byte[]、String、HashMap$Node 或 ArrayList —— 它们数量或总大小明显高于历史基线，就可能是泄漏起点；
- 对比正常时段输出：比如某次发现 byte[] 实例数达 200 万，而平时只有 5 万，说明有大量未释放的字节数组；
- 配合 jstat -gc
1000 看老年代（OU/OCC）比值是否持续 >90% 且 Full GC 后不回落，若吻合，基本可断定是老年代对象堆积。
第二步：用 jmap -dump 抓取有效堆转储
确认异常后，立即导出堆镜像：jmap -dump:live,format=b,file=heap.hprof
- 务必加 live 参数——避免把即将被回收的临时对象也 dump 进来，干扰分析；
- 确保目标路径磁盘空间充足（通常为堆内存的 1.2–1.5 倍），否则 dump 失败或文件损坏；
- 如果进程无响应，可用 -F 强制执行：
jmap -F -dump:live,format=b,file=heap.hprof <pid></pid>，但需注意这会触发 STW，建议选低峰期。
第三步：用 MAT 分析 GC Roots 引用链
把 hprof 文件拖进 Eclipse MAT，按以下顺序操作：
- 打开 Leak Suspects Report，它会自动标出最可疑的几个对象及其 retained heap 占比；
- 点开高占比项，进入 Dominator Tree，按 “Retained Heap” 降序排列，找顶部几个大对象；
- 对可疑对象右键 → Path to GC Roots → with all references，重点看 “Exclude weak/soft references” 之外的强引用路径；
- 常见根因路径示例：
MyService.cache (static)→ArrayList→byte[]，或ThreadLocalMap→ThreadLocal→Connection。
补充验证：结合 jmap -heap 看堆结构是否失衡
执行 jmap -heap
- 确认 GC 算法是否匹配业务特征（如 G1 适合大堆，Parallel 适合吞吐优先）；
- 观察新生代与老年代比例：若 Eden 区极小、老年代过大，可能导致短生命周期对象过早晋升；
- 留意 Metaspace 使用量是否同步上涨——如果是，问题可能不在堆内，而是动态类加载（如 Spring AOP 代理类未卸载）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
