等待队列和阻塞队列

您可以假设与每个锁对象关联的队列有两种类型。一个是阻塞队列，包含等待监控器锁的线程，另一个是等待队列，包含等待通知的线程。(线程调用Object.wait时将被放入等待队列)。

每次锁可用时，调度器从阻塞队列中选择一个线程执行。

当调用notify时，等待队列中只有一个线程被放入阻塞队列中争夺锁，而notifyAll将等待队列中的所有线程放入阻塞队列中。

现在你能看出区别了吗? 尽管在这两种情况下，只有一个线程被执行，但使用notifyAll，其他线程仍然得到一个要执行的更改(因为它们在阻塞队列中)，即使它们未能争用锁。

一些指导原则

我基本上建议一直使用notifyAll，尽管可能会有一点性能损失。 仅在以下情况下使用notify:

任何被唤醒的线程都可以使程序继续运行。 性能很重要。

例如: @xagyg的回答给出了一个通知会导致死锁的例子。在他的例子中，生产者和消费者都与同一个锁对象相关。因此，当生产者调用notify时，可以通知生产者或消费者。但是，如果一个生产者被唤醒，它就不能使程序继续进行，因为缓冲区已经满了。因此发生了死锁。 有两种解决方法:

使用@xagyg建议的notifyALl。 使生产者和消费者关联不同的锁对象，并且生产者只能唤醒消费者，消费者只能唤醒生产者。在这种情况下，无论唤醒哪个消费者，它都可以消费缓冲区并使程序继续进行。

但是(如果我正确理解了这些方法之间的区别)，总是只选择一个线程进行进一步的监视采集。

这是不对的。o.notifyAll()唤醒在o.wait()调用中阻塞的所有线程。线程只允许一个接一个地从o.wait()返回，但它们将轮流返回。

简单地说，这取决于线程等待通知的原因。您是想告诉其中一个等待线程发生了什么，还是想同时告诉所有等待线程?

在某些情况下，所有等待线程在等待结束后都可以采取有用的操作。一个例子是一组等待某个任务完成的线程;一旦任务完成，所有等待的线程都可以继续它们的业务。在这种情况下，您可以使用notifyAll()同时唤醒所有等待的线程。

另一种情况，例如互斥锁，只有一个等待线程在被通知后可以做一些有用的事情(在这种情况下获得锁)。在这种情况下，您更愿意使用notify()。如果实现得当，您也可以在这种情况下使用notifyAll()，但是您将不必要地唤醒无法做任何事情的线程。

在很多情况下，等待条件的代码会被写成循环:

synchronized(o) {
    while (! IsConditionTrue()) {
        o.wait();
    }
    DoSomethingThatOnlyMakesSenseWhenConditionIsTrue_and_MaybeMakeConditionFalseAgain();
}

这样，如果一个o.notifyAll()调用唤醒了多个等待线程，并且第一个从o.wait() make返回的线程将条件保持在false状态，那么其他被唤醒的线程将返回等待状态。

简短的总结:

总是更喜欢使用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.

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

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

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

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

我认为这取决于资源是如何生产和消费的。如果同时有5个工作对象，并且您有5个消费者对象，那么使用notifyAll()唤醒所有线程是有意义的，这样每个线程都可以处理1个工作对象。

如果您只有一个可用的工作对象，那么唤醒所有使用者对象来争夺这个对象有什么意义呢?第一个检查可用工作的线程将得到它，所有其他线程将检查并发现它们无事可做。

我在这里找到了一个很好的解释。简而言之:

The notify() method is generally used for resource pools, where there are an arbitrary number of "consumers" or "workers" that take resources, but when a resource is added to the pool, only one of the waiting consumers or workers can deal with it. The notifyAll() method is actually used in most other cases. Strictly, it is required to notify waiters of a condition that could allow multiple waiters to proceed. But this is often difficult to know. So as a general rule, if you have no particular logic for using notify(), then you should probably use notifyAll(), because it is often difficult to know exactly what threads will be waiting on a particular object and why.

我很惊讶居然没有人提到臭名昭著的“失醒”问题(谷歌it)。

基本上:

如果有多个线程在等待同一个条件， 可以让你从状态A转换到状态B的多个线程， 可以让你从状态B转换到状态A的多个线程(通常是与状态1相同的线程)， 从状态A转换到状态B应该通知1中的线程。

然后，您应该使用notifyAll，除非您有可证明的保证，丢失的唤醒是不可能的。

一个常见的例子是并发FIFO队列，其中: 多个排队者(1。和3。)可以将队列从空转换为非空 多个退出队列器(2。上面)可以等待条件“队列不是空的” Empty ->非空应该通知脱队列者

您可以很容易地编写一个交叉操作，其中从一个空队列开始，2个入队者和2个出队者交互，1个入队者保持休眠状态。

这是一个可以与死锁问题相比较的问题。