Java 线程状态深度解析从 jstack 输出看懂 BLOCKED、WAITING 与死锁当 Java 应用出现性能瓶颈或卡顿时开发者往往需要深入线程内部一探究竟。jstack 作为 JDK 自带的线程诊断利器能为我们打开这扇观察窗口。但面对密密麻麻的线程堆栈如何快速识别关键状态本文将带您穿透表象掌握线程状态的核心判读技巧。1. Java 线程状态机从理论到 jstack 映射Java 线程的生命周期由六种状态构成但在 jstack 输出中我们主要关注以下核心状态线程状态jstack 标识触发条件RUNNABLErunnable线程正在执行或等待 CPU 资源BLOCKEDblocked等待进入 synchronized 代码块WAITINGwaiting on condition调用了 Object.wait()、Thread.join() 或 LockSupport.park()TIMED_WAITINGwaiting on condition带有超时的等待状态如 sleep、wait 带时间参数NEW/TERMINATED不显示初始化和终止状态不会出现在 dump 中关键区别点BLOCKED是等待监视器锁synchronizedWAITING是主动放弃CPU等待唤醒wait/join/park注意jstack 中的waiting to lock 0x0000000718a7d4a8表示线程正在等待特定锁资源通常伴随 BLOCKED 状态出现。2. jstack 实战分析解码线程堆栈获取线程 dump 的基础命令jstack -l pid thread_dump.log2.1 典型线程堆栈模式解析BLOCKED 状态示例Thread-1 #12 prio5 tid0x00007fb58b0e7000 nid0x5903 waiting for monitor entry [0x0000700001f89000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.DeadLock$2.run(DeadLock.java:42) - waiting to lock 0x000000076bf62200 (a java.lang.Object) - locked 0x000000076bf62210 (a java.lang.Object)WAITING 状态示例Thread-2 #13 prio5 tid0x00007fb58b0e8800 nid0x5a03 in Object.wait() [0x000070000208c000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x000000076bf62200 (a java.lang.Object) at java.lang.Object.wait(Object.java:502) at com.example.WaitDemo.run(WaitDemo.java:25) - locked 0x000000076bf62200 (a java.lang.Object)2.2 锁信息深度解读使用-l参数时jstack 会显示额外的锁信息locked 0x12345678当前线程持有的锁waiting to lock 0x12345678等待获取的锁waiting on 0x12345678等待通知的锁对象锁竞争分析表现象可能原因解决方案大量线程 BLOCKED 同一锁地址热点锁竞争减小锁粒度/改用并发容器线程 WAITING 且持有多个锁可能引发死锁检查锁获取顺序parking 状态持续线程池闲置或任务不足调整线程池大小3. 死锁诊断从线索到定位3.1 死锁特征识别jstack 会自动检测死锁输出如下标志性信息Found one Java-level deadlock: Thread-1: waiting to lock monitor 0x00007fb58b0e7000 (object 0x000000076bf62200, a java.lang.Object), which is held by Thread-2 Thread-2: waiting to lock monitor 0x00007fb58b0e8800 (object 0x000000076bf62210, a java.lang.Object), which is held by Thread-13.2 手动分析死锁链路即使没有自动检测到死锁也可以通过以下步骤分析查找所有BLOCKED状态的线程记录每个线程的waiting to lock和locked信息绘制锁依赖图ThreadA - 等待锁L1 (持有锁L2) ThreadB - 等待锁L2 (持有锁L1)使用工具可视化分析推荐 jstack.review 死锁预防检查清单[ ] 避免嵌套锁[ ] 统一锁获取顺序[ ] 使用 tryLock 设置超时[ ] 对共享资源进行分层加锁4. 高级场景WAITING 状态细分4.1 不同类型的 WAITING等待类型典型堆栈特征常见场景Object.wait()显示in Object.wait()条件等待/生产者消费者Thread.join()显示java.lang.Thread.join()线程串行化LockSupport.park()显示sun.misc.Unsafe.park()并发工具类内部实现4.2 虚假唤醒与检查即使线程显示为 WAITING也需要验证等待条件// 错误示例可能错过信号 synchronized(lock) { if(!condition) lock.wait(); } // 正确做法循环检查 synchronized(lock) { while(!condition) { lock.wait(); } }5. 性能优化从线程状态到系统调优5.1 状态统计脚本使用 awk 快速分析线程状态分布jstack -l pid | awk BEGIN { print Thread State Summary } /java.lang.Thread.State:/ { state$0; sub(/^[ \t]java.lang.Thread.State: /, , state); stats[state] } END { for (s in stats) print s :, stats[s] }5.2 优化决策矩阵状态模式优化方向具体措施大量 RUNNABLECPU 瓶颈性能剖析/算法优化高频 BLOCKED锁竞争减小锁范围/读写分离长期 WAITING资源等待连接池扩容/超时设置TIMED_WAITING 堆积任务调度调整线程池参数在实际项目中我曾遇到一个典型案例某订单系统高峰期出现响应延迟。通过 jstack 分析发现80% 的线程处于WAITING on 0x000000076bf621f8状态进一步排查发现是数据库连接池耗尽导致的连锁反应。扩容连接池后系统吞吐量提升了3倍。