简短的总结:

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

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

在这里，所有的醒来都没有多大意义。 Wait notify和notifyall，所有这些都放在拥有对象的监视器之后。如果一个线程处于等待阶段，并且调用了notify，那么这个线程将占用该锁，此时没有其他线程可以占用该锁。所以并发访问根本不能发生。据我所知，只有在锁定对象后才能调用wait notify和notifyall。如果我错了，请指正。

据我所知，以上所有答案都是正确的，所以我要告诉你一些其他的事情。对于生产代码，您确实应该使用java.util.concurrent中的类。在java的并发性方面，它们几乎没有不能为你做的事情。

notify() -从对象的等待集中随机选择一个线程，并将其置于BLOCKED状态。对象的等待集中的其余线程仍然处于WAITING状态。

notifyAll() -将所有线程从对象的等待集移动到BLOCKED状态。使用notifyAll()后，共享对象的等待集中没有剩余线程，因为所有线程现在都处于BLOCKED状态，而不是WAITING状态。

BLOCKED—锁定获取阻塞。 WAITING -等待通知(或阻塞连接完成)。

注意，对于并发实用程序，您还可以在signal()和signalAll()之间进行选择，因为在那里调用了这些方法。因此，即使使用java.util.concurrent，这个问题仍然有效。

Doug Lea在他著名的书中提出了一个有趣的观点:如果notify()和Thread.interrupt()同时发生，通知实际上可能会丢失。如果可能发生这种情况，并且有显著的影响，notifyAll()是一个更安全的选择，即使您付出了开销的代价(大多数时间唤醒太多线程)。