Notify将只通知处于等待状态的一个线程，而Notify all将通知处于等待状态的所有线程，现在所有被通知的线程和所有被阻塞的线程都有资格获得锁，其中只有一个线程将获得锁，所有其他线程(包括之前处于等待状态的线程)将处于阻塞状态。

我想提一下《Java并发实践》中解释的内容:

第一点，是Notify还是NotifyAll?

It will be NotifyAll, and reason is that it will save from signall hijacking.

If two threads A and B are waiting on different condition predicates of same condition queue and notify is called, then it is upto JVM to which thread JVM will notify. Now if notify was meant for thread A and JVM notified thread B, then thread B will wake up and see that this notification is not useful so it will wait again. And Thread A will never come to know about this missed signal and someone hijacked it's notification. So, calling notifyAll will resolve this issue, but again it will have performance impact as it will notify all threads and all threads will compete for same lock and it will involve context switch and hence load on CPU. But we should care about performance only if it is behaving correctly, if it's behavior itself is not correct then performance is of no use.

这个问题可以通过使用jdk 5中提供的显式锁定Lock的Condition对象来解决，因为它为每个条件谓词提供了不同的等待。在这里，它将表现正确，不会有性能问题，因为它将调用信号，并确保只有一个线程正在等待该条件

等待队列和阻塞队列

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

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

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

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

一些指导原则

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

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

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

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

我认为这取决于资源是如何生产和消费的。如果同时有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.

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

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

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

制作人:

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

消费者:

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

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

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

当你调用wait()的“对象”(期望对象锁)、实习生这将释放锁,物体和帮助的其他线程锁在这个“对象”,在这种情况下,将会有超过1线程等待“资源/对象”(考虑到其他线程也发布了等待上面相同的对象,将会有一个线程的方式填补资源/对象并调用通知/ notifyAll)。

在这里，当您(从进程/代码的同一/另一端)发出同一对象的通知时，这将释放一个阻塞和等待的单个线程(不是所有等待的线程——这个释放的线程将由JVM thread Scheduler挑选，对象上的所有锁获取进程与常规进程相同)。

如果只有一个线程共享/处理这个对象，那么可以在wait-notify实现中单独使用notify()方法。

如果您处于基于业务逻辑的多个线程对资源/对象进行读写的情况，那么您应该使用notifyAll()

现在我正在寻找JVM是如何识别和打破等待线程时，我们发出通知()在一个对象…