jcmd -l 是列出当前用户所有 Java 进程的唯一可靠方式，输出第二列为 PID、第三列为主类或 jar 路径；需注意权限、容器环境及 NMT/JFR 等功能依赖启动参数。
查 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 <pid> VM.native_memory summary</pid> 和 jcmd <pid> VM.native_memory detail</pid>
线上服务不敢随便 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 <pid> Thread.print</pid>
和 jstack <pid></pid> 功能一样，但 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 <pid></pid>找出对应 LWP，再用jstack查其 native stack（jcmd不提供 native 栈） - 容器环境下，如果
jcmd <pid> Thread.print</pid>报Unable to open socket file，通常是/tmp权限或路径被 mount --tmpfs 覆盖导致，需检查java.io.tmpdir设置
清理 JFR 录制但不重启 JVM 用 jcmd <pid> JFR.stop</pid> 和 jcmd <pid> JFR.start</pid>
JFR（Java Flight Recorder）录久了会吃内存、磁盘 IO，但很多人以为必须停 JVM 才能关。其实 jcmd 支持运行时启停，且支持指定录制名、时长、事件设置，比写 JMX 脚本简单得多。
关键点在于：JFR 默认不开启，得先用 jcmd <pid> VM.native_memory summary</pid> 确认 JVM 是 JDK 8u262+ 或 JDK 11+，且启动时没加 -XX:+FlightRecorder（旧版需显式启用）。
- 启动录制：
jcmd <pid> JFR.start name=debug duration=60s settings=profile</pid>，其中profile是内置模板，比default更细粒度 - 停止并保存：
jcmd <pid> JFR.stop name=debug filename=/tmp/recording.jfr</pid>，注意filename必须是绝对路径，且 JVM 进程有写权限 - 如果执行
JFR.start报Not supported，不是 JDK 版本问题，而是启动时没加-XX:+UnlockCommercialFeatures -XX:+FlightRecorder（JDK 8u）或--enable-preview（JDK 14 前）
真正难的从来不是命令怎么敲，而是搞清 jcmd 能做什么、不能做什么——它不替代 jmap 的堆分析能力，也不提供 jstat 那种高频采样，但它在“不想重启、不能停服、又得快速定位”的场景里，是唯一不用额外装工具链的选择。别指望它解决所有问题，但至少能帮你把问题范围从“整个 JVM”缩小到“某个内存区”或“某类线程”。
