Java 条件接口中的signalAll与对象中的notifyAll

1） 昨天我才问了这个问题

2） 我想编辑同样的内容，并在我的问题中添加一些“如果”，但因为它可能会变得很麻烦，并且包含足够的文本，让读者不感兴趣和困惑，所以我想在这里提出一个新问题

< P > 3）在我的文章的上下文中，URL是在第1个点中给出的，考虑一个4个线程的情况，P1，T1和P2，T2作用在一个数据结构的'`./p>上。 4） 我试图再次得出使用条件接口优于等待通知的优点

5）考虑代码

final Lock lock = new ReentrantLock();
Condition c1 = lock.newCondition();
Condition c2 = lock.newCondition();
Condition c3 = lock.newCondition();
Condition c4 = lock.newCondition();

6）考虑P1，T1使用C1，C2（以标准等待）/信号（）方式。考虑P2，T2使用C3，C4（以标准的等待（）/信号（方式））分别在我们所说的PUT，PAT1，PUT1，Tou1方法。 7） 当我执行c1.signalAll（）时，将只有由于条件1等待的线程才会收到信号。我说得通吗

8）考虑一个等待/通知机制来实现同样的说法，

private static final Object lock= new Object();
synchronized(lock)

---

考虑put、take、put1、take1，因此如果任何线程对任何一个条件实现执行lock.notifyAll（），即使是由于其他条件而等待/打开的线程也会收到通知。这是真的吗？。这就是使用等待/通知条件机制的缺点吗？

是的，你是对的。

Condition

类是内部条件队列（通过

Object.wait

、

Object.notify

和

Object.notifyAll控制的队列）的泛化

我将引用Brian Goetz的Java并发实践[p.306-307]

内在条件队列有几个缺点。每个内在锁只能有一个关联的条件队列，这意味着在像BoundedBuffer这样的类中，多个线程可能在同一个条件队列上等待不同的条件谓词，最常见的锁定模式涉及公开条件队列对象。这两个因素都使使用notifyAll的统一服务员要求变得不可能。如果要编写具有多个条件谓词的并发对象，或者要对条件队列的可见性进行更多控制，则显式锁和条件类提供了一种比内在锁和条件队列更灵活的替代方法

条件与单个锁关联，就像条件队列与单个内在锁关联一样；[…]正如锁提供了比内在锁定更丰富的功能集一样，条件提供了比内在条件队列更丰富的功能集：每个锁有多个等待集，可中断和不可中断的条件等待，基于截止日期的等待，以及公平或非公平排队的选择

在阅读博文之前，我想说你基本上是对的为什么这么多人同时发布同一个问题？