Java中使用Condition实现线程通信-java教程-PHP中文网

Condition接口提供比wait/notify更灵活的线程通信机制，支持多等待队列和精确唤醒。它需与Lock配合使用，通过await()、signal()、signalAll()实现线程等待与通知，适用于生产者-消费者、读写锁等复杂并发场景，避免虚假唤醒应使用while条件判断，且必须在锁内操作，推荐优先使用signalAll()确保唤醒可靠性。

java中使用condition实现线程通信

在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<Integer> 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()
```
登录后复制
来得优雅和高效。

微信 WeLM
WeLM不是一个直接的对话机器人，而是一个补全用户输入信息的生成模型。

33

查看详情
读写锁的内部实现： 虽然
```
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实现线程通信的详细内容，更多请关注php中文网其它相关文章！