3

1）昨天只有我问了这个问题条件与等待通知机制

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

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

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

7) 当我执行 c1.signalAll() 时，只有等待/因为 condition1 的线程才会收到信号。我说得通吗？

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

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

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

4

1 回答 1

6

是的你是对的。该类Condition是内在条件队列（通过 和 控制的队列）Object.wait的Object.notify泛化Object.notifyAll。

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

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

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

于 2012-06-30T07:04:47.490 回答