Java中管程模型：Hoare与MESA的锁获取规则解析

Java的管程模型严格遵循MESA语义，这意味着wait()或Condition.await()唤醒后线程必须重新竞争并获取锁才能继续执行，而非直接恢复运行；这种设计虽带来灵活性和实现简易性，却也要求开发者始终用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 协同、以及避免唤醒者卡死的风险。

• 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 温床——所有条件检查必须是循环的，所有共享状态访问必须包裹在锁内，连日志打印都最好放在临界区里，否则你看到的“快照”可能已经失效。

今天关于《Java中管程模型：Hoare与MESA的锁获取规则解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！