线程Blocked与Waiting状态区别解析

本文深入剖析了Java线程中BLOCKED与WAITING状态的本质区别：前者是从未获取锁、被动等待锁释放后自动参与竞争，后者则是已成功持有锁后主动让出并进入休眠，必须依赖notify、interrupt或unpark等显式唤醒机制才能恢复；通过jstack日志中的“waiting to lock”与“waiting on”关键词、sleep与wait对锁的不同处理、以及唤醒行为的差异，清晰划清了二者在生命周期、触发条件和调试识别上的关键边界，帮助开发者精准定位并发问题根源。

看线程是否已成功获取 synchronized 锁

这是最直接的判断依据：BLOCKED 状态的线程 从未拿到锁，WAITING 状态的线程 一定已经持有锁（至少在调用 wait() 前持有）。
如果你在线程堆栈里看到 synchronized(lock) { lock.wait(); }，那它先进入 RUNNABLE → 拿到锁 → 执行 wait() → 进入 WAITING；而如果只看到 synchronized(lock) { 就卡住、没进大括号内部，大概率是 BLOCKED。

查 jstack 输出中的关键字线索

jstack 日志里藏着明确的状态提示：

• 出现 java.lang.Thread.State: BLOCKED (on object monitor) + waiting to lock <0x...> → 典型 BLOCKED
• 出现 java.lang.Thread.State: WAITING (on object monitor) + waiting on <0x...> 或 parking to wait for <0x...> → 典型 WAITING
• waiting to lock 表示“想抢但没抢到”，waiting on 表示“已拿到，主动让出并等通知”

注意 sleep() 和 wait() 的根本差异

Thread.sleep() 不会释放锁，也不会导致 WAITING 状态（它进入的是 TIMED_WAITING）；只有 Object.wait()、Thread.join()、LockSupport.park() 这三类方法才会把线程推入 WAITING 状态。

• wait() 必须在 synchronized 块内调用，否则抛 IllegalMonitorStateException
• sleep() 可以在任意位置调用，且与锁无关
• 误把 sleep() 当成 wait() 会导致状态误判 —— 它既不是 BLOCKED 也不是 WAITING

Blocked 线程无需唤醒，Waiting 线程必须被显式唤醒

这是行为层面最硬的区分点：

• 当持有锁的线程退出 synchronized 块，所有 BLOCKED 线程会自动参与新一轮锁竞争，无需任何 notify/park 操作
• WAITING 线程不会因锁释放而醒来：比如 t1 在 lock.wait() 后进入 WAITING，即使 t2 拿到锁又释放了，t1 仍沉睡，除非 t2 调用 lock.notify()
• 更隐蔽的坑：notify() 后，t1 从 WAITING → RUNNABLE → 但要重新争锁 → 可能立刻再次变成 BLOCKED（如果锁被别人抢走）

真正容易被忽略的是：WAITING 状态的线程，其“等待对象”和“唤醒机制”完全独立于锁本身。它可能在等另一个线程结束（join()），可能在等 unpark（park()），也可能在等 notify（wait()）——但 BLOCKED 只有一件事可等：某个具体对象的 monitor 锁空出来。

到这里，我们也就讲完了《线程Blocked与Waiting状态区别解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！