Java jcmd 怎样查看运行中进程的线程信息

排查 Java 服务卡顿时，先用 jcmd -l 找到目标 JVM 的 PID，再执行 jcmd Thread.print -l。前者确认进程，后者打印所有线程的栈，并补充 java.util.concurrent 锁信息。若要留档或交给脚本处理，则改用 Thread.dump_to_file -format=json。

官方地址：https://docs.oracle.com/en/java/javase/24/docs/specs/man/jcmd.html

先用 jcmd -l 锁定运行中的 Java 进程

不要凭服务名猜 PID。先在目标主机执行下面的命令，结果通常包含进程标识、主类和启动参数；如果同一主类启动了多个实例，再结合启动参数或系统进程信息缩小范围。

# 先列出当前主机上 jcmd 可见的 Java 进程
jcmd -l

# 让目标 JVM 自己说明有哪些诊断命令
jcmd 12345 help

12345 只是示例 PID。Oracle 文档说明，jcmd 要求在 JVM 所在的同一台机器执行，并使用与目标进程相同的有效用户和组标识；权限不匹配时，命令失败不等于线程不存在。JVM 位于独立 Docker 进程时，jcmd -l 可能列不出来，此时先用 ps 找到容器内或宿主机映射的 PID，再回到同一权限上下文执行。

用 Thread.print -l 查看线程栈和锁

确认 PID 后，最小可用命令是：

# 打印所有线程的栈，并显示 java.util.concurrent 锁信息
jcmd 12345 Thread.print -l

# 需要更完整的线程字段时，额外打开扩展信息
jcmd 12345 Thread.print -e -l

阅读输出时先看线程名和状态，再看栈顶附近的共同调用点。大量 BLOCKED 线程指向监视器竞争；WAITING 或 TIMED_WAITING 更像是在等待条件、队列或定时唤醒；RUNNABLE 只表示线程仍可运行，不能直接等同于“正在消耗 CPU”。把重复的栈帧、锁拥有者和业务请求日志放在一起，才足以形成排障假设。

用 Thread.dump_to_file 导出可检索的线程转储

人工查看适合一次性现场判断，持续排障或工单协作更适合保存结构化文件。Oracle 的命令支持 plain 和 json 两种格式，并允许用 -overwrite 覆盖已有文件。

# 导出 JSON 线程转储，文件名中保留 PID 便于归档
jcmd 12345 Thread.dump_to_file -format=json /tmp/java-threads-12345.json

# 文件已存在且确认可以覆盖时再显式开启覆盖
jcmd 12345 Thread.dump_to_file -format=json -overwrite /tmp/java-threads-12345.json

这里的路径只是示例，生产环境应替换为有权限、容量足够且不会暴露敏感信息的诊断目录。先保留原始转储，再做字段提取；不要只把“线程很多”当作结论。可以按线程状态、锁地址、线程名和重复栈帧建立对照，随后与请求超时、连接池耗尽或 CPU 指标交叉验证。

常见问题

jcmd -l 没有列出 Java 进程怎么办？

先确认命令运行在 JVM 所在机器，并检查有效用户和组是否匹配；容器场景再用 ps 找 PID。不要先修改 JVM 参数。

Thread.print -l 能直接证明死锁吗？

它能提供线程栈和并发锁线索，但是否构成死锁还要核对锁拥有者、等待环和业务时序，不能只凭一个线程状态下结论。

什么时候选 JSON 而不是 plain？

需要脚本筛选、工单留档或多次采样对比时选 JSON；现场快速阅读和人工粘贴讨论时，plain 往往更直接。