直接运行 jcmd 即可列出当前用户可访问的、支持诊断接口的 JVM 进程，比 ps aux | grep java 更精准；但需注意 -XX:+DisableAttachMechanism、权限限制或 /tmp 不可写等情况会导致进程不可见。
怎么用 jcmd 查看当前 JVM 进程列表
不加参数直接运行 jcmd 就能列出所有可被当前用户访问的 Java 进程，比 ps aux | grep java 更准——它只显示真正由 JDK 启动、且支持诊断接口的 JVM 实例。
常见错误是误以为它能扫出所有 Java 进程；实际上，如果 JVM 是用 -XX:+DisableAttachMechanism 启动的，或者以 root 以外用户身份运行但权限受限（比如容器里没挂 /tmp），jcmd 就看不到它。
-
jcmd输出第一列是进程 ID（LVMID），不是 OS PID，但通常一致；遇到混淆时可用jcmd -l强制刷新列表 - 在 Docker 容器中运行时，确保
/tmp可写，否则 attach 会失败，jcmd列表为空或报IOException: No such file or directory - 非本用户启动的 JVM（如 systemd 服务用
java -jar启动），默认不可见；需用sudo jcmd，但前提是目标 JVM 没禁用 attach
jcmd <pid> VM.native_memory</pid> 为什么经常报错或返回空
这个命令依赖 JVM 启动时开启 -XX:NativeMemoryTracking=summary（或 detail），否则直接报 Native memory tracking is not enabled。不是所有 JDK 版本默认开，也不是所有场景都允许重启 JVM 补加参数。
即使开了，VM.native_memory 返回的数据也受采样精度限制：JDK 8u262+ 才支持 summary 级别实时查询；旧版本只能用 detail 并配合 jcmd <pid> VM.native_memory baseline</pid> 手动打点比对。
- 启用 NMT 有约 5%~10% 的性能开销，生产环境慎开
detail，summary相对安全 - 输出中的
[thread]区域可能远大于实际线程数 × 栈大小，因为包含 JVM 内部线程和未释放的 native buffer 引用 - 若看到
Unable to open /proc/<pid>/maps</pid>，说明容器没给cap_sys_ptrace权限，或用了seccomp限制
用 jcmd <pid> VM.flags -all</pid> 查 JVM 参数时，哪些值可信
VM.flags -all 显示的是 JVM 启动后最终生效的全部参数，包括用户显式指定的、JVM 自动推导的（如 -XX:MaxRAMPercentage 算出来的堆大小）、以及某些平台相关默认值。但它不反映运行时通过 HotSpotDiagnosticMXBean 动态修改的参数（比如 ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class).setVMOption(...)）。
容易踩的坑是把 -XX:+UseG1GC 这类布尔型参数的「=true」当成必须写法——其实 +UseG1GC 和 =true 等价，但 jcmd 输出统一显示为 =true，别误以为原始命令也得这么写。
-
manageable标记的参数才能被 JMX 或jcmd <pid> VM.set_flag</pid>动态修改；非manageable的（如-Xms）改了也不生效 - 输出里带
{product}或{diagnostic}的括号，表示该参数属于哪个 JVM 内部模块，影响是否能在容器里被安全暴露 - 注意区分
-XX:InitialHeapSize（对应-Xms）和-XX:MaxHeapSize（对应-Xmx）——它们可能被MaxRAMPercentage覆盖，但jcmd显示的是计算后的结果值
jcmd <pid> Thread.print</pid> 输出太长，怎么快速定位阻塞线程
直接看 Thread.print 原始输出容易漏掉关键信息，尤其当线程数过千时。重点不是“全看”，而是抓三类状态：WAITING（无超时等待）、BLOCKED（锁竞争）、parking to wait for（Unsafe.park，常见于 LockSupport 或 ForkJoinPool）。
别依赖 grep BLOCKED ——很多阻塞实际发生在 native 层（如 Object.wait() 底层调 pthread_cond_wait），Thread.print 只标 WAITING。真要确认锁竞争，得结合 jcmd <pid> VM.native_memory summary</pid> 看 Internal 区内存增长，或用 jstack -l <pid></pid>（它比 jcmd 多打印锁持有者信息）。
- 输出中每个线程块开头的
"main" #1 prio=5 os_prio=0 tid=0x00007f...里，tid是 JVM 内部线程 ID，十六进制；转十进制后可用printf "%d\n" 0x00007f...对应/proc/<pid>/stack</pid>中的线程 - 如果看到大量
java.lang.Thread.State: TIMED_WAITING (parking)，大概率是线程池空闲线程，不用慌；但若伴随 CPU 持续 100%，就得查是不是ForkJoinPool.commonPool()被意外压爆 -
jcmd <pid> Thread.print</pid>不会触发 full GC，但会短暂 stop-the-world（毫秒级），高 QPS 服务慎频发执行
真正麻烦的是那些 attach 失败、NMT 关闭、或容器权限卡死的情况——这时候 jcmd 不是不好用，而是它根本没机会说话。提前在启动脚本里加好 -XX:+UnlockDiagnosticVMOptions -XX:+PrintGCDetails，比事后狂敲 jcmd 有用得多。
