Condition接口提供比wait/notify更灵活的线程通信机制，支持多等待队列和精确唤醒。它需与Lock配合使用，通过await()、signal()、signalAll()实现线程等待与通知，适用于生产者-消费者、读写锁等复杂并发场景，避免虚假唤醒应使用while条件判断，且必须在锁内操作，推荐优先使用signalAll()确保唤醒可靠性。
在Java并发编程中，当我们需要协调多个线程的执行顺序，让它们在特定条件下等待或被唤醒时，
Condition接口提供了一种比
Object类的
wait()和
notify()/
notifyAll()机制更为灵活和强大的解决方案。它本质上是
Lock接口的一个扩展，允许我们为同一个锁创建多个等待队列，从而实现更精细化的线程通信控制。
解决方案
Condition接口通常与
ReentrantLock这样的显式锁配合使用。它允许一个线程在某个条件不满足时释放锁并进入等待状态，直到另一个线程满足该条件并发出信号将其唤醒。这极大地提升了并发控制的粒度。
要使用
Condition，你首先需要一个
Lock实例，然后通过
Lock实例的
newCondition()方法来创建
Condition对象。一个
Lock可以有多个
Condition对象，每个
Condition都可以管理一个独立的等待队列。
核心方法包括：
await()
：当前线程进入等待状态，释放锁，并被放入Condition
的等待队列。当线程被唤醒时，它会尝试重新获取锁。signal()
：唤醒Condition
等待队列中的一个线程。具体唤醒哪一个，JVM 不保证。signalAll()
：唤醒Condition
等待队列中的所有线程。
让我们通过一个经典的生产者-消费者模型来理解它：
import java.util.LinkedList;
import java.util.Queue;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class ConditionProducerConsumer {
private final Lock lock = new ReentrantLock();
private final Condition notFull = lock.newCondition(); // 队列不满条件
private final Condition notEmpty = lock.newCondition(); // 队列不空条件
private final Queue queue = new LinkedList<>();
private final int CAPACITY = 5;
public void produce(int value) throws InterruptedException {
lock.lock(); // 获取锁
try {
while (queue.size() == CAPACITY) { // 队列满，生产者等待
System.out.println(Thread.currentThread().getName() + "：队列已满，等待消费...");
notFull.await(); // 释放锁并等待
}
queue.offer(value);
System.out.println(Thread.currentThread().getName() + "：生产了 " + value + "，当前队列大小：" + queue.size());
notEmpty.signal(); // 队列不空，通知消费者可以消费了
} finally {
lock.unlock(); // 释放锁
}
}
public int consume() throws InterruptedException {
lock.lock(); // 获取锁
try {
while (queue.isEmpty()) { // 队列空，消费者等待
System.out.println(Thread.currentThread().getName() + "：队列为空，等待生产...");
notEmpty.await(); // 释放锁并等待
}
Integer value = queue.poll();
System.out.println(Thread.currentThread().getName() + "：消费了 " + value + "，当前队列大小：" + queue.size());
notFull.signal(); // 队列不满，通知生产者可以生产了
return value;
} finally {
lock.unlock(); // 释放锁
}
}
public static void main(String[] args) {
ConditionProducerConsumer pc = new ConditionProducerConsumer();
Runnable producerTask = () -> {
try {
for (int i = 0; i < 10; i++) {
Thread.sleep((long) (Math.random() * 100));
pc.produce(i);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
};
Runnable consumerTask = () -> {
try {
for (int i = 0; i < 10; i++) {
Thread.sleep((long) (Math.random() * 150));
pc.consume();
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
};
new Thread(producerTask, "生产者A").start();
new Thread(producerTask, "生产者B").start();
new Thread(consumerTask, "消费者X").start();
new Thread(consumerTask, "消费者Y").start();
}
} 这段代码清晰地展示了如何使用两个
Condition对象 (
notFull和
notEmpty) 来分别管理生产者和消费者的等待/唤醒逻辑。生产者只关心队列是否满，消费者只关心队列是否空，它们互不干扰，但又通过同一个
Lock实例保证了对共享队列的同步访问。
Condition与传统的wait/notify有什么本质区别？
从我的经验来看，
Condition和
wait/notify最大的不同，也是最吸引人的地方，在于它提供了多路复用的能力。想象一下，你有一个复杂的系统，里面有多种不同的“等待条件”。使用
Object.wait()和
notifyAll()，所有等待在该对象上的线程都会被唤醒，即使它们等待的条件根本没发生变化。这就像你喊一声“吃饭了”，结果把所有正在睡觉、正在看电视的人都叫起来，但其实只有一个人饿了。这种“广播式”的唤醒，效率低，而且可能导致不必要的上下文切换。
Condition则允许你为不同的等待条件创建独立的
Condition实例。比如，在上面的生产者-消费者例子中，
notFull和
notEmpty就是两个独立的条件。生产者只会在
notFull上等待，消费者只会在
notEmpty上等待。当生产者生产了一个物品后，它只需要
signal()
notEmpty，唤醒等待消费的线程；而不会去打扰那些等待生产的线程。这种精确唤醒的能力，是
wait/notify无法直接提供的，它能显著提高并发程序的效率和可读性。
另一个关键区别是，
Condition必须与
Lock接口（如
ReentrantLock）配合使用，而
wait/notify是
Object类的方法，因此它依赖于
synchronized关键字。
Lock提供了更强大的功能，比如尝试获取锁、可中断的锁获取、公平锁等，这些都是
synchronized不具备的。
Condition继承了
Lock的这些优势，使得并发控制更加灵活和强大。
在哪些场景下，Condition比wait/notify更具优势？
我个人觉得，
Condition的优势主要体现在那些需要精细化控制线程等待和唤醒的复杂并发场景中。
多条件等待的生产者-消费者模型： 这就是我们上面代码展示的经典场景。当队列有容量限制时，生产者等待“队列不满”的条件，消费者等待“队列不空”的条件。如果使用
wait/notify
，你可能需要一个复杂的逻辑来判断唤醒的是生产者还是消费者，或者干脆用notifyAll()
暴力唤醒，这显然不如Condition
的notFull.signal()
和notEmpty.signal()
来得优雅和高效。读写锁的内部实现： 虽然
ReentrantReadWriteLock
已经为我们实现了读写锁的功能，但如果你要自己设计一个类似的锁，Condition
几乎是不可或缺的。例如，写线程在写操作进行时需要等待读线程释放锁，读线程在有写线程等待时也可能需要等待。这些不同的等待条件，通过Condition
可以清晰地分离和管理。线程池的等待队列： 许多高级并发工具的内部实现，例如
ThreadPoolExecutor
的BlockingQueue
，在需要等待任务到来或等待队列有空间时，都会用到Condition
来实现更高效的线程协作。任何需要多路复用等待队列的场景： 只要你的并发逻辑中存在多个独立的等待条件，并且你希望只唤醒那些真正满足条件的线程，那么
Condition
都是一个比wait/notify
更好的选择。它能让你的代码逻辑更清晰，性能更高，也更易于维护。
使用Condition时，有哪些常见的陷阱或最佳实践？
在使用
Condition的过程中，我遇到过一些坑，也总结了一些经验，分享给大家：
-
务必在
while
循环中检查条件： 这是一个非常关键的实践。当你调用await()
时，线程可能会因为虚假唤醒（spurious wakeup）或者被signalAll()
唤醒，即使它等待的条件并未真正满足。所以，永远不要使用if
来检查条件，而应该使用while
循环。这样，即使被唤醒了，线程也会再次检查条件，如果条件不满足，会再次进入等待。例如：while (conditionIsNotMet) { myCondition.await(); } await()
和signal()
/signalAll()
必须在持有锁的情况下调用： 这一点和wait/notify
类似，如果你在没有持有锁的情况下调用这些方法，会抛出IllegalMonitorStateException
。这是因为Condition
的工作机制是基于锁的，它需要锁来保护共享状态和管理等待队列。考虑使用
signalAll()
而不是signal()
： 虽然signal()
看起来更精确，只唤醒一个线程，但它有一个潜在的风险：如果被唤醒的那个线程发现条件依然不满足（比如它不是真正等待的那个），或者它需要重新获取锁但暂时获取不到，那么其他等待的线程可能永远不会被唤醒，从而导致死锁或饥饿。除非你非常确定只有一个线程需要被唤醒，并且被唤醒的线程一定能处理情况，否则signalAll()
通常是更安全的选择。虽然signalAll()
会唤醒所有等待的线程，可能带来一些性能开销，但在大多数复杂场景下，其带来的正确性保证远超这点开销。为不同的等待条件创建独立的
Condition
实例：
这是 Condition
的核心优势，也是避免上述signal()
陷阱的关键。不要试图用一个Condition
来管理所有等待状态，那会让你失去Condition
的精细化控制能力，退化到notifyAll()
的低效模式。处理中断：
await()
方法会抛出InterruptedException
。这意味着你的线程在等待时可能会被中断。你需要根据业务需求来决定如何处理这个异常，通常是捕获它，然后根据需要重新抛出或设置中断标志位Thread.currentThread().interrupt()
。锁的释放： 确保在
finally
块中释放锁 (lock.unlock()
)，以防止在代码执行过程中发生异常导致锁无法释放，进而造成死锁。这是使用Lock
接口的基本要求，对Condition
同样适用。
这是 
