定位java内存泄漏需用.hprof快照+mat工具分析引用链，重点找“本该回收却存活”的对象；生产环境应配置-xx:+heapdumponoutofmemoryerror自动dump，并调大mat内存后优先使用leak suspects report、dominator tree和histogram视图，再通过引用链、多dump对比及代码审查三步验证。
定位 Java 内存泄漏，核心是用好堆内存快照（.hprof 文件）+ MAT 工具 + 引用链分析逻辑。不是看谁占内存多，而是找“本该被回收却一直活下来”的对象。
先确保拿到有效的 dump 文件
没快照，一切分析都是空谈。生产环境必须提前配置自动 dump：
- -XX:+HeapDumpOnOutOfMemoryError：OOM 触发时自动生成，最可靠
- -XX:HeapDumpPath=/path/to/dumps/：指定路径，注意磁盘空间（dump 大小通常是堆的 30%–50%）
- 临时排查可用 jcmd
GC.heap_dump heap.hprof ，比 jmap 对 JVM 影响更小 - 避免用 jmap -dump:live 在 OOM 后执行——此时进程可能已终止或状态失真
用 MAT 打开前调大自身内存
MAT 加载大 dump 很吃内存。打开 MemoryAnalyzer.ini，修改 -Xmx 值：
- dump 约 1GB → 设为 -Xmx2048m；约 2GB → 设为 -Xmx4096m
- 设太小会报错 “Parsing heap dump” 失败；设太大可能启动不了，需匹配本机物理内存
直奔三个关键视图快速聚焦
别从头翻对象列表，优先看这三个功能：
- Leak Suspects Report：点开即扫描，高亮前几组“最可疑泄漏”，附带引用路径和保留内存大小，适合静态 Map、缓存未清理等典型场景
- Dominator Tree：按 Retained Heap 降序排列，顶部几行就是“拖着最多内存不放”的对象。右键 → Path to GC Roots → 勾选 exclude weak/soft references，只看强引用链
- Histogram：按类统计实例数。比如 OrderService 实例达 50 万，而正常应为几百，说明创建失控或未释放
确认是否真泄漏：看引用链 + 对比 + 查代码
找到嫌疑对象后，做三步验证：
- 检查 Path to GC Roots 中的引用链：是否经过 static 字段、未清空的 ConcurrentHashMap、ThreadLocal、监听器注册后未注销、数据库连接里的 Statement 等长生命周期持有者？
- 如果有多个 dump（如相隔 10 分钟），对比同一类的实例数和 Retained Heap 是否持续增长？
- 定位到具体类后，查代码：是不是用了 static Map 缓存但没加 size 限制或 LRU 淘汰？是不是流/连接/监听器注册后忘了 close/remove？
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
