如果一个人在谷歌上搜索“notify()和notifyAll()之间的区别”，那么会跳出很多解释(撇开javadoc段落)。这都归结于被唤醒的等待线程的数量:notify()中有一个，notifyAll()中有所有线程。
然而(如果我确实理解了这些方法之间的区别)，只有一个线程总是被选择用于进一步的监视采集;第一种情况是VM选择的线程，第二种情况是系统线程调度程序选择的线程。程序员不知道它们的确切选择过程(在一般情况下)。
那么notify()和notifyAll()之间有什么有用的区别呢?我遗漏了什么吗?
当前回答
notify()将唤醒一个线程，而notifyAll()将唤醒所有线程。据我所知，没有中间立场。但是如果你不确定notify()会对你的线程做什么，使用notifyAll()。每次都很灵验。
其他回答
等待队列和阻塞队列
您可以假设与每个锁对象关联的队列有两种类型。一个是阻塞队列，包含等待监控器锁的线程，另一个是等待队列，包含等待通知的线程。(线程调用Object.wait时将被放入等待队列)。
每次锁可用时，调度器从阻塞队列中选择一个线程执行。
当调用notify时，等待队列中只有一个线程被放入阻塞队列中争夺锁，而notifyAll将等待队列中的所有线程放入阻塞队列中。
现在你能看出区别了吗? 尽管在这两种情况下，只有一个线程被执行，但使用notifyAll，其他线程仍然得到一个要执行的更改(因为它们在阻塞队列中)，即使它们未能争用锁。
一些指导原则
我基本上建议一直使用notifyAll，尽管可能会有一点性能损失。 仅在以下情况下使用notify:
任何被唤醒的线程都可以使程序继续运行。 性能很重要。
例如: @xagyg的回答给出了一个通知会导致死锁的例子。在他的例子中，生产者和消费者都与同一个锁对象相关。因此，当生产者调用notify时，可以通知生产者或消费者。但是，如果一个生产者被唤醒，它就不能使程序继续进行，因为缓冲区已经满了。因此发生了死锁。 有两种解决方法:
使用@xagyg建议的notifyALl。 使生产者和消费者关联不同的锁对象，并且生产者只能唤醒消费者，消费者只能唤醒生产者。在这种情况下，无论唤醒哪个消费者，它都可以消费缓冲区并使程序继续进行。
线程有三种状态。
WAIT -线程没有使用任何CPU周期 BLOCKED -线程在试图获取监视器时被阻塞。它可能仍在使用CPU周期 RUNNING -线程正在运行。
现在，当调用notify()时，JVM选择一个线程并将其移动到BLOCKED状态，从而将其移动到RUNNING状态，因为没有竞争监视器对象。
当调用notifyAll()时，JVM选取所有线程并将它们移到BLOCKED状态。所有这些线程都将优先获得对象的锁。能够首先获取监视器的线程将能够首先进入RUNNING状态，依此类推。
摘自Java大师Joshua Bloch在Effective Java第二版中的文章:
“第69项:选择并发实用程序而不是等待和通知”。
据我所知，以上所有答案都是正确的，所以我要告诉你一些其他的事情。对于生产代码，您确实应该使用java.util.concurrent中的类。在java的并发性方面，它们几乎没有不能为你做的事情。
总结一下上面的详细解释，用我能想到的最简单的方式，这是由于JVM内置监控器的限制，1)在整个同步单元(块或对象)上获得，2)不区分正在等待/通知/关于的特定条件。
这意味着如果多个线程正在等待不同的条件，并且使用了notify()，所选择的线程可能不是在新满足的条件上取得进展的线程——导致该线程(以及其他当前仍在等待的能够满足条件的线程等)不能取得进展，最终饥饿或程序挂起。
相反，notifyAll()允许所有等待的线程最终重新获得锁并检查各自的条件，从而最终允许执行进程。
因此，notify()只有在任何等待线程被选中时保证允许进程，才可以安全地使用，当同一监视器中的所有线程只检查一个相同的条件时，通常可以满足这一点——在实际应用程序中相当罕见的情况。
