Condition 接口中的 signalAll 与对象中的 notificationAll

1）昨天我才问过这个问题条件与等待通知机制 https://stackoverflow.com/questions/10395571/condition-vs-wait-notify-mechanism

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

3) 根据我的帖子的上下文，其 url 在第 1) 点中给出，考虑 4 个线程 P1,T1 和 P2,T2 作用于单个数据结构“S”的情况。

4）我试图再次展示使用Condition接口相对于等待通知的优势。

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（以标准await()/signalAll() 方式）。考虑 P2、T2 分别在 put、take、put1、take1 方法中使用 c3、c4（以标准的 wait()/signalAll() 方式）。

7）当我执行 c1.signalAll() 时，将仅等待/由于条件 1 的线程将收到信号。我说得有道理吗？

8）考虑使用等待/通知机制来实现相同的说法，

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

考虑 put,take,put1,take1，因此如果任何线程在满足任何一个条件时执行 lock.notifyAll()，即使由于其他条件而等待/开启的线程也会收到通知。真的吗 ？。这是我们可以将其视为使用 wait/notify over Condition 机制的缺点吗？

是的你是对的。这Condition类是内在条件队列的概括（通过控制的队列）Object.wait, Object.notify and Object.notifyAll).

我将引用 Brian Goetz 的 Java Concurrency in Practice [p.306-307]

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

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