JVM问题排查实战教程详解

本文深入讲解了jcmd在JVM生产环境问题排查中的实战应用，涵盖如何可靠列出Java进程、轻量级原生内存分析、无干扰线程快照、运行时启停JFR等关键场景，强调其“不重启、不断业务、快速定位”的独特价值——它虽不能替代jmap或jstat，却是在高可用要求下精准缩小问题范围、避开Full GC风险、绕过权限与容器限制的首选诊断利器。

查 JVM 进程 ID 和基础信息用 jcmd -l

很多人一上来就输 jcmd，结果报错“no pid given”——因为没指定目标进程。jcmd -l 是唯一可靠的方式列出当前用户下所有 Java 进程，它比 ps aux | grep java 更准，能过滤掉 shell wrapper 或非 JVM 进程。

注意：jcmd -l 不显示 PID 为 0 的进程（比如刚 fork 出还没 exec 的子进程），也不显示其他用户启动的 Java 进程（除非你有 root 权限）。如果你在容器里跑，得确认是否挂载了 /proc，否则可能看不到任何输出。

• 输出中第二列是 PID，第三列是主类或 jar 路径，例如 12345 /opt/app.jar
• 如果只看到数字 PID 没有类名，说明应用用了自定义 Launcher 或混淆了主类，这时得结合 cat /proc/12345/cmdline 看真实启动参数
• 某些 JDK 8u212+ 在容器中会默认禁用 jcmd 的部分功能，需加 JVM 参数 -XX:+UseContainerSupport 并确保 cgroup v1/v2 配置正确

导出堆快照不卡死用 jcmd VM.native_memory summary 和 jcmd VM.native_memory detail

线上服务不敢随便 jmap -dump？因为容易触发 Full GC 或长时间 STW。jcmd 提供轻量级内存视图，尤其适合快速判断是不是 native 内存泄漏（比如 DirectByteBuffer、JNI 库、JIT 编译缓存）。

VM.native_memory summary 一秒内返回总用量和各模块占比；VM.native_memory detail 则带调用栈（但开销略大，慎在高负载时用）。两者都依赖 JVM 启动时加了 -XX:NativeMemoryTracking=summary（JDK 8u60+ 默认关闭）。

• 没加 NMT 参数时执行会提示 Native memory tracking is not enabled，此时只能退回去改启动参数重启
• summary 输出里的 [thread] 模块持续增长，大概率是线程数失控；[class] 异常高，可能是动态生成类（Groovy、CGLIB、反射代理）没释放
• detail 输出中若看到大量 malloc + Unsafe_AllocateMemory，要重点查 ByteBuffer.allocateDirect() 是否漏调 cleaner 或未 close

触发线程 dump 但不中断业务用 jcmd Thread.print

和 jstack 功能一样，但 jcmd 更稳：它走的是 JVM 内部诊断通道，不会因线程状态异常（如 IN_NATIVE 卡在系统调用）而挂住整个命令，也不会被 SIGQUIT 信号干扰。

输出格式和 jstack 完全一致，可直接用现有分析工具（比如 fastthread.io）解析。但要注意：它不会自动附加时间戳，如果需要对比多次 dump，得自己重命名文件。

• 输出里出现大量 java.lang.Thread.State: BLOCKED (on object monitor)，优先看锁对象的 locked ownable synchronizers 区域
• 若某线程状态是 RUNNABLE 但 CPU 占用极高，配合 top -H -p 找出对应 LWP，再用 jstack 查其 native stack（jcmd 不提供 native 栈）
• 容器环境下，如果 jcmd Thread.print 报 Unable to open socket file，通常是 /tmp 权限或路径被 mount --tmpfs 覆盖导致，需检查 java.io.tmpdir 设置

清理 JFR 录制但不重启 JVM 用 jcmd JFR.stop 和 jcmd JFR.start

JFR（Java Flight Recorder）录久了会吃内存、磁盘 IO，但很多人以为必须停 JVM 才能关。其实 jcmd 支持运行时启停，且支持指定录制名、时长、事件设置，比写 JMX 脚本简单得多。

关键点在于：JFR 默认不开启，得先用 jcmd VM.native_memory summary 确认 JVM 是 JDK 8u262+ 或 JDK 11+，且启动时没加 -XX:+FlightRecorder（旧版需显式启用）。

• 启动录制：jcmd JFR.start name=debug duration=60s settings=profile，其中 profile 是内置模板，比 default 更细粒度
• 停止并保存：jcmd JFR.stop name=debug filename=/tmp/recording.jfr，注意 filename 必须是绝对路径，且 JVM 进程有写权限
• 如果执行 JFR.start 报 Not supported，不是 JDK 版本问题，而是启动时没加 -XX:+UnlockCommercialFeatures -XX:+FlightRecorder（JDK 8u）或 --enable-preview（JDK 14 前）

真正难的从来不是命令怎么敲，而是搞清 jcmd 能做什么、不能做什么——它不替代 jmap 的堆分析能力，也不提供 jstat 那种高频采样，但它在“不想重启、不能停服、又得快速定位”的场景里，是唯一不用额外装工具链的选择。别指望它解决所有问题，但至少能帮你把问题范围从“整个 JVM”缩小到“某个内存区”或“某类线程”。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。