线程被notify()唤醒后为何进入BLOCKED？

你是否以为被 notify() 唤醒的线程会立刻“满血复活”开始执行？真相是：它醒来后第一件事不是奔跑，而是排队——必须先陷入 BLOCKED 状态，与其他线程激烈争夺对象锁，只有抢到锁才能真正进入 RUNNABLE；这不是 JVM 的临时限制，而是 Java 监视器模型和 synchronized 语义的刚性要求——唤醒不等于可执行，没有锁，连 synchronized 块的门都进不去。

因为被 notify() 唤醒的线程必须重新竞争对象锁，而锁此时大概率仍被持有——它不是“醒来就能跑”，而是“醒来就得排队抢锁”。这个关键设计源于 Java 监视器（monitor）模型的语义约束，不是 JVM 实现的随意选择，而是 JMM 和 synchronized 语义的刚性要求。

唤醒不等于可执行：notify() 只是发个“起床通知”

调用 notify() 的线程本身仍在 synchronized 块中执行，尚未退出临界区，因此锁并未释放。被唤醒的线程虽然脱离 WAITING 状态，但立刻面临一个现实问题：目标对象的 monitor 锁还被占着。它无法直接进入 RUNNABLE，只能进入 BLOCKED 状态，加入该锁的竞争队列等待重试。

• notify() 不释放锁，只把线程从等待队列（wait set）移到同步队列（entry set）
• 只有当 notify() 所在线程退出 synchronized 块（或抛异常），锁才真正释放
• JVM 从 entry set 中挑选一个线程尝试获取锁；失败即继续 BLOCKED，成功才转为 RUNNABLE

BLOCKED 是 WAITING 被唤醒后的必经中转站

WAITING → BLOCKED → RUNNABLE 是标准、合法且被 Java 官方文档明确定义的状态路径。很多资料画成 WAITING → RUNNABLE，属于简化示意，容易误导。真实流程中：

• WAITING 线程已放弃锁和 CPU，处于“静默等待通知”状态
• 被 notify 后，它要“复活”并回到临界区继续执行，就必须重新持锁——这一步就是 BLOCKED 的全部含义
• 若此时锁空闲，它可能极快地完成 BLOCKED → RUNNABLE 转换（肉眼难察），但状态机上依然存在该环节

为什么不能跳过 BLOCKED 直接 RUNNABLE？

跳过 BLOCKED 意味着允许线程在未持有锁的情况下执行 synchronized 块内的后续代码——这会彻底破坏 synchronized 的原子性和内存可见性保证。Java 要求：

• 所有进入 synchronized 块的线程，必须先获得 monitor 锁
• 所有从 wait() 返回的线程，也必须满足同一前提
• BLOCKED 状态正是这个强制准入检查的体现：它是“有资格争锁但尚未得手”的明确标识

如何验证这一点？

用 jstack 抓取线程快照，你会看到清晰线索：

• java.lang.Thread.State: BLOCKED (on object monitor) —— 后面通常跟 waiting to lock ...
• java.lang.Thread.State: WAITING (on object monitor) —— 后面通常跟 waiting on ...
• 如果某线程刚被 notify，堆栈显示它卡在 synchronized 入口处，且状态为 BLOCKED，就证实了该路径

好了，本文到此结束，带大家了解了《线程被notify()唤醒后为何进入BLOCKED？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！