是的，wait() 唤醒后必须重新获取对象锁才能返回，这是 JVM 规范强制要求的 MESA 管程语义；唤醒不保证条件仍成立，须用 while 循环检查而非 if。
Java 的 wait() 唤醒后一定重新抢锁吗？
是的，wait() 返回前，线程必须重新获取所属对象的监视器锁（即 synchronized 锁），否则不会从 wait() 返回。这不是“可选行为”，而是 JVM 规范强制要求——哪怕唤醒它的 notify() 是在另一个线程释放锁的瞬间发生的，当前线程也得排队等锁，不是直接接着跑。
常见错误现象：wait() 后立刻读共享变量，结果看到过期值，以为“唤醒即执行”，其实中间可能被其他线程插队修改过。根本原因就是没意识到：唤醒 ≠ 恢复执行，中间隔着一次锁竞争。
-
wait()会原子性地释放锁 + 进入等待队列；唤醒信号到达后，线程进入“就绪但无锁”状态 - 只有当它在同步块/方法入口处成功获得锁，才能真正继续执行
- 这意味着：即使只有一个线程在等，它也可能在唤醒后，被新进来的
synchronized线程抢先拿到锁
为什么 Java 只实现 MESA 风格，不支持 Hoare 语义？
因为 Java 的管程模型严格对应 MESA：唤醒操作（notify()）不移交执行权，被唤醒线程必须自己争锁；而 Hoare 要求唤醒者立即将 CPU 和锁让给被唤醒者（类似“接力”），这在 JVM 的线程调度和锁实现上难以安全、高效支撑。
使用场景差异很实际：MESA 更宽松、更易实现，适合通用语言；Hoare 更强语义，适合实时或形式化验证场景（如早期 Concurrent Pascal）。Java 选择 MESA，是权衡了可移植性、GC 协同、以及避免唤醒者卡死的风险。
立即学习“Java免费学习笔记（深入）”；
- Hoare 下，
notify()调用者必须阻塞直到被唤醒者完成一轮执行——这会破坏调用上下文，JVM 栈帧无法安全移交 - MESA 允许唤醒者继续执行，甚至可能在被唤醒者抢到锁前再次修改条件，所以你必须用
while而非if检查条件 - 所有标准 JDK 类（
ArrayBlockingQueue、LinkedBlockingQueue）都遵循 MESA，靠循环检查 +wait()组合来规避虚假唤醒
wait() 被唤醒后，条件还成立吗？
不一定。MESA 模型下，唤醒不保证条件仍为真——可能被其他线程抢占锁后改掉，也可能发生虚假唤醒（spurious wakeup）。所以永远不要用 if (condition) wait();，必须写成 while (!condition) wait();。
性能影响很小，但逻辑正确性全系于此。有人试过加日志发现：明明刚 notify() 完，wait() 返回后 condition 就是 false，就是因为中间有第三个线程进来 set + notify 了一次，把状态又翻回去了。
- 虚假唤醒虽罕见，但 POSIX 和 JVM 规范都明确允许，不能假设它不会发生
-
notifyAll()更容易暴露这个问题——多个线程被唤醒，但往往只有一个能真正干活，其余必须重新判断并可能再次等待 - 别依赖唤醒顺序：JVM 不保证
notify()唤醒的是等待最久的，也不保证 FIFO
用 Lock + Condition 时规则还一样吗？
核心规则没变：condition.await() 同样会释放关联的 Lock，唤醒后也必须重新获取该锁，才能从 await() 返回。但它比 synchronized + wait() 多一层可控性：比如可中断、可超时、可绑定多个 Condition 实例。
容易踩的坑是误以为 await() 和 wait() 行为不同——其实它们在“唤醒后是否自动持锁”这点上完全一致，都是 MESA 风格。区别只在 API 设计和扩展能力。
-
await()抛出InterruptedException，而wait()也会，但前者更容易集成进响应式流程 - 用
ReentrantLock时，记得lock()/unlock()必须配对，且await()只能在持有锁时调用，否则抛IllegalMonitorStateException - 不要混用：
synchronized块里不能调用Condition.await()，反过来也不行；锁对象和条件变量必须严格归属同一同步机制
真正复杂的地方在于：你永远没法靠“谁 notify 谁就一定 next run”来建模线程协作。MESA 的松耦合既是灵活性来源，也是 bug 温床——所有条件检查必须是循环的，所有共享状态访问必须包裹在锁内，连日志打印都最好放在临界区里，否则你看到的“快照”可能已经失效。
