被 notify() 唤醒的线程必须先转入 blocked 状态争抢锁，而非直接 runnable；因 notify() 不释放锁，仅将线程从 wait set 移至 entry set，只有原线程退出 synchronized 块后锁才释放，jvm 从 entry set 中选线程竞争锁成功才转为 runnable。
因为被 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，就证实了该路径
