等待与唤醒机制——wait/notify、Condition 与 LockSupport 对照

并发里所有“等待/唤醒”问题，最终都绕不开三套机制：

Object.wait/notify/notifyAll（监视器机制，配合 synchronized）
Condition.await/signal/signalAll（显式锁配套）
LockSupport.park/unpark（更底层，AQS/FutureTask/线程池广泛使用）

写清楚它们的差异，很多“信号丢失/虚假唤醒/死等”的问题会一下子明朗。

1. 对比速查表

机制	等待条件	唤醒方式	是否必须持有锁	是否可能虚假唤醒	典型使用处
`wait/notify`	对象 monitor 的 wait-set	`notify/notifyAll`	是（必须在 synchronized 内）	是	传统生产者-消费者、synchronized 协作
`Condition`	条件队列（每个 Condition 一个队列）	`signal/signalAll`	是（必须持有关联 Lock）	是	ReentrantLock 协作、多条件队列
`LockSupport`	线程的“permit”	`unpark(thread)`	否	会（park 可能无理由返回）	AQS、FutureTask、线程池阻塞

2. wait/notify：监视器上的等待集合

2.1 关键规则

必须在 synchronized(obj) 内调用 obj.wait() / obj.notify()
wait() 会：
- 释放 monitor
- 把线程加入 obj 的等待集合
- 被唤醒后重新竞争 monitor

2.2 正确姿势：永远用 while

synchronized (lock) {
    while (!conditionOk()) {
        lock.wait();
    }
    // condition ok
}

原因：

虚假唤醒：线程可能在没有收到通知时返回
竞争唤醒：notifyAll 后只有一个线程能拿到资源，其余线程需要继续等

2.3 notify vs notifyAll

notify()：只随机唤醒一个等待线程，容易造成“唤醒了不该唤醒的人”（条件不满足又继续睡）
notifyAll()：唤醒全部，依靠 while 自旋检查条件；更安全但唤醒风暴更大

3. Condition：更可控的等待/唤醒

Condition 的最大价值是：

一个 Lock 可以派生多个 Condition
每个 Condition 有自己的等待队列

这让“多条件协作”更清晰：

notEmpty
notFull
hasResource

3.1 模板

ReentrantLock lock = new ReentrantLock();
Condition notEmpty = lock.newCondition();

lock.lock();
try {
    while (queue.isEmpty()) {
        notEmpty.await();
    }
    // consume
} finally {
    lock.unlock();
}