这里有一个简单的解释:

您是正确的，无论使用notify()还是notifyAll()，直接结果都是恰好有另一个线程获得监视器并开始执行。(假设一些线程实际上在wait()上阻塞了这个对象，其他不相关的线程并没有占用所有可用的内核，等等。)

假设线程A、B和C正在等待这个对象，线程A得到监视器。区别在于当A释放监视器时发生了什么。如果你使用notify()，那么B和C仍然被阻塞在wait()中:它们不是在监视器上等待，而是在等待通知。当A释放监视器时，B和C仍然在那里等待notify()。

如果使用notifyAll()，则B和C都已进入“等待通知”状态，都在等待获取监视器。当A释放监视器时，B或C将获得它(假设没有其他线程竞争该监视器)并开始执行。

notify()将唤醒一个线程，而notifyAll()将唤醒所有线程。据我所知，没有中间立场。但是如果你不确定notify()会对你的线程做什么，使用notifyAll()。每次都很灵验。

notify()让您编写比notifyAll()更有效的代码。

考虑下面这段从多个并行线程执行的代码:

synchronized(this) {
    while(busy) // a loop is necessary here
        wait();
    busy = true;
}
...
synchronized(this) {
    busy = false;
    notifyAll();
}

可以通过使用notify()来提高效率:

synchronized(this) {
    if(busy)   // replaced the loop with a condition which is evaluated only once
        wait();
    busy = true;
}
...
synchronized(this) {
    busy = false;
    notify();
}

在有大量线程的情况下，或者如果等待循环条件的计算成本很高，notify()将比notifyAll()快得多。例如，如果你有1000个线程，那么999个线程将在第一个notifyAll()之后被唤醒和评估，然后是998，然后是997，依此类推。相反，使用notify()解决方案，只会唤醒一个线程。

使用notifyAll()当你需要选择哪个线程将做下一步工作:

synchronized(this) {
    while(idx != last+1)  // wait until it's my turn
        wait();
}
...
synchronized(this) {
    last = idx;
    notifyAll();
}

Finally, it's important to understand that in case of notifyAll(), the code inside synchronized blocks that have been awakened will be executed sequentially, not all at once. Let's say there are three threads waiting in the above example, and the fourth thread calls notifyAll(). All three threads will be awakened but only one will start execution and check the condition of the while loop. If the condition is true, it will call wait() again, and only then the second thread will start executing and will check its while loop condition, and so on.

总结一下上面的详细解释，用我能想到的最简单的方式，这是由于JVM内置监控器的限制，1)在整个同步单元(块或对象)上获得，2)不区分正在等待/通知/关于的特定条件。

这意味着如果多个线程正在等待不同的条件，并且使用了notify()，所选择的线程可能不是在新满足的条件上取得进展的线程——导致该线程(以及其他当前仍在等待的能够满足条件的线程等)不能取得进展，最终饥饿或程序挂起。

相反，notifyAll()允许所有等待的线程最终重新获得锁并检查各自的条件，从而最终允许执行进程。

因此，notify()只有在任何等待线程被选中时保证允许进程，才可以安全地使用，当同一监视器中的所有线程只检查一个相同的条件时，通常可以满足这一点——在实际应用程序中相当罕见的情况。

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

基本上:

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

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

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

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

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

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

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

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