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

Question

1）昨天才问这个问题条件与等待通知机制

2）我想对其进行编辑，并在问题中添加一些“如果”，但是由于它可能变得很麻烦并且包含足够的文字以引起读者的兴趣和困惑，所以我想在这里提出一个新问题。

3）在我的文章上下文中，其URL在点1）中给出，请考虑作用于单个数据结构'S'的4个线程P1，T1和P2，T2的情况。

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）考虑使用c1，c2的P1，T1（以标准await（）/ signalAll（）方式）。考虑分别使用put，take，put1，take1方法使用c3，c4（以标准await（）/ signalAll（）方式）的P2，T2。

7）当我做c1.signalAll（）时，将仅等待/由于condition1的线程将接收到信号。我有道理吗？

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

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

考虑put，take，put1，take1，因此，如果任何线程对任何一个条件实现执行lock.notifyAll（），即使由于其他条件而正在等待/启动的线程也将收到通知。真的吗 ？。那可以算作使用条件机制中的等待/通知的缺点吗？

Answer 1

是的，你是对的。的Condition类是固有条件队列（其通过控制的那些的一般化Object.wait，Object.notify和Object.notifyAll）。

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

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

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