Java内存泄漏排查需遵循“现象→证据→定位→验证”闭环：先用jstat -gcutil实时观察O、FGC、FGCT确认泄漏；再用jmap -histo:live锁定膨胀类；接着jmap -dump:live导出快照，MAT分析Leak Suspects与GC Roots；最后用jinfo、jstat -gcmetacapacity排除元空间等干扰。
熟练使用 Java 内存泄漏排查命令，关键不是死记参数，而是建立“现象→证据→定位→验证”的闭环思维。每个命令都有明确的职责边界，用错顺序或跳过环节，容易把问题拖进迷雾。
先用 jstat 看清 GC 是否已失控
这是唯一能实时、低开销确认泄漏是否正在发生的工具。别一上来就 dump 堆——那会暂停应用，还可能掩盖真实节奏。
- 执行 jstat -gcutil
1000 ，每秒刷新一次，盯住三列：O（老年代使用率）、FGC（Full GC 次数）、FGCT（Full GC 总耗时） - O 持续上涨不回落（比如从 40% 涨到 95% 卡住），同时 FGC 在 2 分钟内猛增、FGCT 逐次变长 → 基本坐实活跃泄漏
- 如果 O 稳定在 60%、FGC 隔几小时才一次，那大概率不是泄漏，可能是堆配小了或流量突增
再用 jmap -histo:live 锁定膨胀类
确认泄漏后立刻执行，只统计存活对象，避免死亡对象干扰判断。
- 运行 jmap -histo:live
| head -n 20 - 重点看 #instances 和 #bytes 都排前几的类，尤其是你自己的包路径（如 com.yourcompany.cache.UserCache）
- 留意数组类型：[C（字符串）、[[I（二维 int 数组）、[Ljava.lang.Object;（集合扩容常见）——这些突然暴增，往往就是缓存或队列没清理
- 对比两次输出：间隔 1 分钟各跑一次，用 diff 看哪些类实例数增长最快
最后用 jmap -dump:live 导出快照给 MAT 分析
只在锁定可疑类之后才导出，否则快照太大、分析太慢，还可能错过关键时间点。
立即学习“Java免费学习笔记（深入）”；
- 命令必须带 live 参数：jmap -dump:live,format=b,file=leak-$(date +%s).hprof
- 文件名加时间戳，方便后续比对多个快照中同一类的增长趋势
- 用 MAT 打开后，先跑 “Leak Suspects Report”，再看 Dominator Tree 找内存占比最高的对象链
- 右键可疑对象 → “Path to GC Roots” → 重点检查 static 字段、ThreadLocal、未注销监听器、内部类隐式引用
顺手用 jinfo 和 jstat -gcmetacapacity 排除干扰项
有些“泄漏假象”其实是配置或元空间问题，查之前先扫一眼，省得白忙活。
-
jinfo -flags
：确认是否开了 -XX:+HeapDumpOnOutOfMemoryError，没开就补上，下次 OOM 自动留证据 -
jstat -gcmetacapacity
：看 M 区（元空间）使用率，长期 >90% 可能是类加载泄漏（比如热部署没清理旧类） - 检查 -Xms 和 -Xmx 是否差距过大，或 -XX:NewRatio 是否设得太小（如 =1），这些都可能让老年代初始空间过小，掩盖真实泄漏节奏
