管程是synchronized背后的运行时结构，每个对象有独立管程，负责互斥、等待与唤醒；Java采用MESA模型，要求wait()必须置于while循环中以防虚假唤醒；ReentrantLock比synchronized更灵活，支持多条件、可中断和超时。
管程不是Java关键字，而是synchronized背后的运行时结构
Java里没有monitor这个语法，但它真实存在——当你用synchronized修饰方法或代码块时，JVM会在对象头里关联一个管程实例。这个管程由JVM在运行时创建和管理，负责互斥进入、条件等待与唤醒。它不是你new出来的对象，也不是接口或类，而是一套隐式行为契约。
容易踩的坑：
- 误以为
synchronized(this)和synchronized(obj)共享同一个管程——其实每个对象有独立管程，锁的是对象监视器（Monitor），不是“同步逻辑”本身 - 在
wait()/notify()前没用synchronized包裹，直接抛IllegalMonitorStateException - 用
notify()代替notifyAll()导致部分线程永远等不到唤醒（MESA模型特性：被唤醒线程需重新检查条件）
为什么Java选MESA模型而不是Hoare或Hasen
MESA模型规定：线程调用wait()后释放锁并进入等待队列；被notify()唤醒后，必须重新竞争锁，拿到锁后才从wait()返回，且**不保证唤醒时条件仍成立**。这是Java设计的取舍，也是最贴近实际工程需求的模型。
这意味着你必须把wait()写在while循环里，而不是if：
立即学习“Java免费学习笔记（深入）”；
while (!conditionMet()) {
obj.wait();
}
否则可能遭遇虚假唤醒（spurious wakeup）或条件已过期。Hoare模型会立即将CPU交给被唤醒线程，但实现开销大、调度复杂；MESA更轻量，也更可控。
synchronized和ReentrantLock都实现管程，但行为细节不同
两者都提供互斥+条件等待能力，但ReentrantLock是显式、可中断、可超时、可绑定多个Condition；而synchronized只绑定一个隐式条件队列，且不可中断、无超时。
使用场景差异：
- 需要公平锁策略？
new ReentrantLock(true)，synchronized永远非公平 - 要避免死等？用
lock.tryLock(1, TimeUnit.SECONDS)，synchronized只能硬等 - 多个等待条件？比如“缓冲区满”和“缓冲区空”，
ReentrantLock可配两个Condition，synchronized只能靠notifyAll()广播，再靠while各自判断
别在管程里做耗时操作，尤其是I/O或远程调用
管程的核心价值是快速进出、保护临界区。一旦你在synchronized块里调用Thread.sleep()、socket.read()或httpClient.execute()，等于把锁占着不动，其他线程全卡住。
典型错误模式：
synchronized (lock) {
// ❌ 千万别在这里发HTTP请求
response = httpClient.post("/api/data");
data = parse(response);
sharedList.add(data);
}
正确做法是：只在管程内做状态变更和通知，把耗时逻辑移出去。必要时用生产者-消费者解耦，比如用BlockingQueue——它的put()/take()内部用AQS+管程协作，但对外屏蔽了锁细节。
真正难的不是理解“管程是什么”，而是时刻意识到：它不是功能容器，而是资源闸门。开得久，后面就堵成一片。
