Java jcmd 怎样按线程状态筛选定位阻塞

Java 服务变慢时，线程数多并不等于线程真的被锁住。更稳妥的做法是先用 jcmd 取得线程转储，再按 java.lang.Thread.State 筛出 BLOCKED、WAITING、TIMED_WAITING 和 RUNNABLE，最后回到锁拥有者与栈帧确认原因。真正值得优先处理的是持续出现、能连到同一把锁或同一段业务调用的线程组。

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

先确认 jcmd 看到了哪个 JVM

jcmd 必须在目标 JVM 所在机器执行，并使用与 JVM 相同的有效用户和组标识。先列出可发现的 Java 进程，再询问目标 JVM 是否支持线程打印命令：

# 列出当前用户可发现的 JVM，先确认 PID 和主类
jcmd -l

# 查看目标 JVM 的 Thread.print 参数，避免直接猜测版本能力
jcmd 12345 help Thread.print

这里的 12345 只是示例 PID，不代表真实运行结果。如果列表为空，先检查执行用户、容器边界和目标 JVM 是否在另一台机器；不要把“没有 PID”误判成“没有线程”。

用 Thread.print -l 保留锁关系

定位阻塞时，建议使用带锁信息的线程转储。官方命令说明中，Thread.print 会打印所有线程及栈，-l 会额外打印 java.util.concurrent 锁：

# 输出所有线程的状态和栈，并保留并发锁信息
jcmd 12345 Thread.print -l > thread-dump-01.txt

# 只做本地文本筛选，不把状态名当成最终根因
grep -n -E 'java.lang.Thread.State: (BLOCKED|WAITING|TIMED_WAITING|RUNNABLE)' thread-dump-01.txt

转储会带来中等影响，影响程度取决于线程数量；在生产环境应记录采样时间、命令和目标 PID。它是诊断输入，不是业务请求的实时监控指标。

按状态筛选时，先看 BLOCKED 再看等待类状态

Java 的线程状态是 JVM 层面的状态，不等同于操作系统线程状态。BLOCKED 表示线程等待监视器锁；WAITING 表示无限期等待另一个线程动作；TIMED_WAITING 表示带超时等待；RUNNABLE 表示线程处于 JVM 可运行状态，也可能正在等待操作系统资源。

因此，筛选的顺序不是“看到 WAITING 就报警”，而是先判断状态语义，再看栈帧是否落在业务锁、队列、连接池或正常调度代码上。

沿着锁拥有者和栈帧确认阻塞根因

看到 BLOCKED 后，先记录线程名、线程 ID、等待的锁对象和栈顶方法；再在同一份转储里找到持有该锁的线程。若多个业务线程都等待同一对象，而持有者长期停留在同一段业务代码，才有较强的锁竞争证据。

# 下面是阅读转储时关注的结构，不是一次真实命令输出
"worker-17" #93
   java.lang.Thread.State: BLOCKED (on object monitor)
        waiting to lock 
        at demo.OrderCache.refresh(OrderCache.java:88)

"worker-03" #41
   java.lang.Thread.State: RUNNABLE
        - locked 
        at demo.OrderCache.rebuild(OrderCache.java:52)

这类片段只能说明“等待者和持有者指向同一锁对象”的诊断关系，不能单凭一份快照证明死锁。若状态在两次采样中都保持不变，再结合业务耗时、锁粒度和持有者栈帧决定是缩短临界区、拆分锁，还是继续观察。

把一次筛选变成可复查的结论

1. 保存 PID、JDK 版本、采样时间和 Thread.print -l 命令。
2. 先统计 BLOCKED，再分别查看等待方法和栈顶业务类。
3. 对疑似锁竞争的线程做第二次采样，比较线程名、锁地址和栈帧是否重复。
4. 把“状态现象”“锁或等待对象”“持有者/唤醒者”“处理动作”写成四列记录。

最终结论应具体到“哪些线程在等什么、谁持有或可能唤醒它、证据是否跨采样重复”。这样才能把 jcmd 输出转成排障动作，而不是只得到一张很长的线程列表。

常见问题

看到 BLOCKED 就说明发生死锁了吗？

不是。BLOCKED 只说明当前线程等待监视器锁；需要继续检查持有者、锁依赖和多次采样，才能判断是否接近死锁或只是短暂竞争。

WAITING 和 TIMED_WAITING 哪个更危险？

没有固定答案。要看等待原因、等待对象和业务预期；例如线程池空闲等待可能正常，而业务线程无限期等待一个永远不会到来的信号就需要继续追查。