怎样使用JVM标准命令行工具实时排查生产环境内存泄漏

用JDK命令可快速定位生产环境内存泄漏：先用jstat -gcutil观察O、FGC、FGCT三列异常；再用jmap -histo:live找膨胀类；最后jmap -dump:live导出快照，结合MAT分析GC Roots路径。

直接用 JDK 自带命令就能在生产环境快速定位内存泄漏，关键不是堆 dump，而是先看 GC 行为是否异常。jstat 是第一响应工具，它不暂停应用、开销极低，能立刻告诉你泄漏是否正在发生、发生在哪个区域。

第一步：用 jstat -gcutil 快速确认泄漏迹象

执行 jstat -gcutil <pid> 1000（每秒刷新一次），重点盯住三列：

• 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 <pid> | head -n 20。它只统计存活对象，避免死亡对象干扰：

• 关注 #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 <pid>

• 加 live 参数确保只导出可达对象，文件更小、分析更快
• 命名带时间戳，方便后续比对多个快照的变化趋势
• 文件导出后，用 MAT 打开 → 执行 “Leak Suspects Report” → 查看 Dominator Tree 中占比最高的对象链
• 重点关注 “Path to GC Roots” 中的强引用路径，比如 static 字段、ThreadLocal、未注销监听器等

补充验证：结合 jinfo 和启动参数交叉检查

运行 jinfo -flags <pid> 确认关键配置：

• 是否有 -XX:+HeapDumpOnOutOfMemoryError？没开就补上，下次 OOM 自动留证据
• 堆大小是否合理？比如 -Xms 和 -Xmx 差距过大，或老年代初始比例过小（-XX:NewRatio=2），可能掩盖泄漏表象
• 元空间是否异常？jstat -gcmetacapacity <pid> 查看 M 区使用率，长期 >90% 可能是类加载泄漏

整个过程无需重启、不改代码、不装插件，5 分钟内完成从现象判断到线索锁定。