如果一个人在谷歌上搜索“notify()和notifyAll()之间的区别”，那么会跳出很多解释(撇开javadoc段落)。这都归结于被唤醒的等待线程的数量:notify()中有一个，notifyAll()中有所有线程。
然而(如果我确实理解了这些方法之间的区别)，只有一个线程总是被选择用于进一步的监视采集;第一种情况是VM选择的线程，第二种情况是系统线程调度程序选择的线程。程序员不知道它们的确切选择过程(在一般情况下)。
那么notify()和notifyAll()之间有什么有用的区别呢?我遗漏了什么吗?
当前回答
notify() -从对象的等待集中随机选择一个线程，并将其置于BLOCKED状态。对象的等待集中的其余线程仍然处于WAITING状态。
notifyAll() -将所有线程从对象的等待集移动到BLOCKED状态。使用notifyAll()后，共享对象的等待集中没有剩余线程，因为所有线程现在都处于BLOCKED状态，而不是WAITING状态。
BLOCKED—锁定获取阻塞。 WAITING -等待通知(或阻塞连接完成)。
其他回答
摘自Java大师Joshua Bloch在Effective Java第二版中的文章:
“第69项:选择并发实用程序而不是等待和通知”。
我想提一下《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对象来解决，因为它为每个条件谓词提供了不同的等待。在这里，它将表现正确，不会有性能问题，因为它将调用信号，并确保只有一个线程正在等待该条件
摘自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.
notify()将唤醒一个线程，而notifyAll()将唤醒所有线程。据我所知，没有中间立场。但是如果你不确定notify()会对你的线程做什么，使用notifyAll()。每次都很灵验。
当你调用wait()的“对象”(期望对象锁)、实习生这将释放锁,物体和帮助的其他线程锁在这个“对象”,在这种情况下,将会有超过1线程等待“资源/对象”(考虑到其他线程也发布了等待上面相同的对象,将会有一个线程的方式填补资源/对象并调用通知/ notifyAll)。
在这里，当您(从进程/代码的同一/另一端)发出同一对象的通知时，这将释放一个阻塞和等待的单个线程(不是所有等待的线程——这个释放的线程将由JVM thread Scheduler挑选，对象上的所有锁获取进程与常规进程相同)。
如果只有一个线程共享/处理这个对象，那么可以在wait-notify实现中单独使用notify()方法。
如果您处于基于业务逻辑的多个线程对资源/对象进行读写的情况，那么您应该使用notifyAll()
现在我正在寻找JVM是如何识别和打破等待线程时，我们发出通知()在一个对象…
