用jdk命令可快速定位生产环境内存泄漏：先用jstat -gcutil观察o、fgc、fgct三列异常；再用jmap -histo:live找膨胀类；最后jmap -dump:live导出快照，结合mat分析gc roots路径。
直接用 JDK 自带命令就能在生产环境快速定位内存泄漏，关键不是堆 dump，而是先看 GC 行为是否异常。jstat 是第一响应工具，它不暂停应用、开销极低，能立刻告诉你泄漏是否正在发生、发生在哪个区域。
第一步：用 jstat -gcutil 快速确认泄漏迹象
执行 jstat -gcutil
- O 列（Old Gen 使用率）：持续上升且不回落，比如从 40% 涨到 95% 并卡住，说明老年代对象无法回收
- FGC 列（Full GC 次数）：短时间内猛增（如 2 分钟内从 0 到 15），但每次回收后 O 值几乎不变
- FGCT 列（Full GC 总耗时）：不断变长，同时 YGC 频次可能也升高，说明新生代对象过早晋升
只要 O 持续涨 + FGC 频繁 + FGCT 变长，基本可判定存在内存泄漏，此时再深入。
第二步：用 jmap -histo:live 定位膨胀类
确认泄漏后，立即执行 jmap -histo:live
- 关注 #instances 和 #bytes 都排前几的类，尤其是自定义业务类（如
com.xxx.OrderCache、org.apache.http.impl.client.CloseableHttpClient） - 注意数组类型：[C 是 char[]（常为字符串）、[[I 是 int[][]（可能是缓存结构）、[Ljava.lang.Object; 是 Object 数组（常见于集合扩容）
- 如果某类实例数每分钟增长数千，而业务量并无对应变化，大概率就是泄漏源头
第三步：导出存活堆快照供离线分析
定位到可疑类后，导出轻量级堆转储：jmap -dump:live,format=b,file=leak-$(date +%s).hprof
- 加 live 参数确保只导出可达对象，文件更小、分析更快
- 命名带时间戳，方便后续比对多个快照的变化趋势
- 文件导出后，用 MAT 打开 → 执行 “Leak Suspects Report” → 查看 Dominator Tree 中占比最高的对象链
- 重点关注 “Path to GC Roots” 中的强引用路径，比如 static 字段、ThreadLocal、未注销监听器等
补充验证：结合 jinfo 和启动参数交叉检查
运行 jinfo -flags
- 是否有
-XX:+HeapDumpOnOutOfMemoryError？没开就补上，下次 OOM 自动留证据 - 堆大小是否合理？比如 -Xms 和 -Xmx 差距过大，或老年代初始比例过小（-XX:NewRatio=2），可能掩盖泄漏表象
- 元空间是否异常？jstat -gcmetacapacity
查看 M 区使用率，长期 >90% 可能是类加载泄漏
整个过程无需重启、不改代码、不装插件，5 分钟内完成从现象判断到线索锁定。
