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
都可以管理一个独立的等待队列。
核心方法包括：
立即学习“Java免费学习笔记（深入）”；
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 { 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()
来得优雅和高效。
ERMEB云盘发卡小程序源码
ERMEB云盘发卡系统官方正版系统发卡系统操作简单、方便、易懂，系统微信小程序前端采用nuiapp、后端采用think PHP6，PC前端采用vue开发，使用场景：文件上传储存。适合个人/个体/中小企业使用，本系统配合微信小程序端进行使用，文件下载以及发卡商品卡密领取都需要进入小程序内获取下载码以及卡密领取，小程序内可设置积分充值以及任务获取积分，支持微信激励广告领取文件下载码以及卡密商品，可实现
0 查看详情 
读写锁的内部实现： 虽然
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
同样适用。
以上就是Java中使用Condition实现线程通信的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/771850.html
微信扫一扫 
支付宝扫一扫 
