这个答案是xagyg的优秀答案的图形重写和简化，包括eran的评论。

为什么要使用notifyAll，即使每个产品都是针对单个消费者的?

考虑生产者和消费者，简化如下。

制作人:

while (!empty) {
   wait() // on full
}
put()
notify()

消费者:

while (empty) {
   wait() // on empty
}
take()
notify()

假设2个生产者和2个消费者共享一个大小为1的缓冲区。下图描述了一个导致死锁的场景，如果所有线程都使用notifyAll，就可以避免死锁。

每个通知都被标记为被唤醒的线程。

线程有三种状态。

WAIT -线程没有使用任何CPU周期 BLOCKED -线程在试图获取监视器时被阻塞。它可能仍在使用CPU周期 RUNNING -线程正在运行。

现在，当调用notify()时，JVM选择一个线程并将其移动到BLOCKED状态，从而将其移动到RUNNING状态，因为没有竞争监视器对象。

当调用notifyAll()时，JVM选取所有线程并将它们移到BLOCKED状态。所有这些线程都将优先获得对象的锁。能够首先获取监视器的线程将能够首先进入RUNNING状态，依此类推。

摘自Effective Java博客:

The notifyAll method should generally be used in preference to notify. 

If notify is used, great care must be taken to ensure liveness.

所以，我的理解是(从前面提到的博客，“Yann TM”对公认答案和Java文档的评论):

notify() : JVM awakens one of the waiting threads on this object. Thread selection is made arbitrarily without fairness. So same thread can be awakened again and again. So system's state changes but no real progress is made. Thus creating a livelock. notifyAll() : JVM awakens all threads and then all threads race for the lock on this object. Now, CPU scheduler selects a thread which acquires lock on this object. This selection process would be much better than selection by JVM. Thus, ensuring liveness.

虽然上面有一些可靠的答案，但我对我读到的困惑和误解的数量感到惊讶。这可能证明了应该尽可能多地使用java.util.concurrent，而不是尝试编写自己的坏并发代码。

回到问题:总结一下，目前的最佳实践是在所有情况下避免notify()，因为会出现丢失唤醒的问题。任何不理解这一点的人都不应该被允许编写关键任务并发代码。如果你担心羊群问题，实现一次唤醒一个线程的安全方法是:

为等待线程构建一个显式的等待队列; 让队列中的每个线程等待它的前一个线程; 完成后让每个线程调用notifyAll()。

或者你可以使用Java.util.concurrent。*，它们已经实现了这一点。

看看@xagyg发布的代码。

假设两个不同的线程正在等待两个不同的条件: 第一个线程等待buf.size() != MAX_SIZE，第二个线程等待buf.size() != 0。

假设在某一点buf.size()不等于0。JVM调用notify()而不是notifyAll()，并且通知第一个线程(而不是第二个线程)。

第一个线程被唤醒，检查buf.size()，它可能返回MAX_SIZE，然后返回等待。第二个线程没有被唤醒，继续等待，不调用get()。

简短的总结:

总是更喜欢使用notifyAll()而不是notify()，除非你有一个大型并行应用程序，其中大量线程都在做同样的事情。

解释:

notify()[…醒来时还是单身 线程。因为notify()不允许指定线程 唤醒后，它只在大规模并行应用程序中有用 是指具有大量线程的程序，它们都执行类似的任务。 在这样的应用程序中，您不关心哪个线程被唤醒。

来源:https://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html

比较上述情况下的notify()和notifyAll():一个大型并行应用程序，其中线程在做相同的事情。如果在这种情况下调用notifyAll()， notifyAll()将导致大量线程的唤醒(即调度)，其中许多线程是不必要的(因为实际上只有一个线程可以继续，即被授予wait()、notify()或notifyAll()对象监视的线程被调用)，因此浪费计算资源。

因此，如果您的应用程序中没有大量线程并发地做同样的事情，请使用notifyAll()而不是notify()。为什么?因为，正如其他用户已经在这个论坛上回答的那样，notify()

唤醒正在此对象的监视器上等待的单个线程。[…] 选择是任意的，发生在自由裁量权 实现。

来源:Java SE8 API (https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#notify--)

Imagine you have a producer consumer application where consumers are ready (i.e. wait() ing) to consume, producers are ready (i.e. wait() ing) to produce and the queue of items (to be produced / consumed) is empty. In that case, notify() might wake up only consumers and never producers because the choice who is waken up is arbitrary. The producer consumer cycle wouldn't make any progress although producers and consumers are ready to produce and consume, respectively. Instead, a consumer is woken up (i.e. leaving the wait() status), doesn't take an item out of the queue because it's empty, and notify() s another consumer to proceed.

In contrast, notifyAll() awakens both producers and consumers. The choice who is scheduled depends on the scheduler. Of course, depending on the scheduler's implementation, the scheduler might also only schedule consumers (e.g. if you assign consumer threads a very high priority). However, the assumption here is that the danger of the scheduler scheduling only consumers is lower than the danger of the JVM only waking up consumers because any reasonably implemented scheduler doesn't make just arbitrary decisions. Rather, most scheduler implementations make at least some effort to prevent starvation.