线程有三种状态。

WAIT -线程没有使用任何CPU周期 BLOCKED -线程在试图获取监视器时被阻塞。它可能仍在使用CPU周期 RUNNING -线程正在运行。

现在，当调用notify()时，JVM选择一个线程并将其移动到BLOCKED状态，从而将其移动到RUNNING状态，因为没有竞争监视器对象。

当调用notifyAll()时，JVM选取所有线程并将它们移到BLOCKED状态。所有这些线程都将优先获得对象的锁。能够首先获取监视器的线程将能够首先进入RUNNING状态，依此类推。

这里有一个简单的解释:

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

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

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

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

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

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

制作人:

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

消费者:

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

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

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

但是(如果我正确理解了这些方法之间的区别)，总是只选择一个线程进行进一步的监视采集。

这是不对的。o.notifyAll()唤醒在o.wait()调用中阻塞的所有线程。线程只允许一个接一个地从o.wait()返回，但它们将轮流返回。

简单地说，这取决于线程等待通知的原因。您是想告诉其中一个等待线程发生了什么，还是想同时告诉所有等待线程?

在某些情况下，所有等待线程在等待结束后都可以采取有用的操作。一个例子是一组等待某个任务完成的线程;一旦任务完成，所有等待的线程都可以继续它们的业务。在这种情况下，您可以使用notifyAll()同时唤醒所有等待的线程。

另一种情况，例如互斥锁，只有一个等待线程在被通知后可以做一些有用的事情(在这种情况下获得锁)。在这种情况下，您更愿意使用notify()。如果实现得当，您也可以在这种情况下使用notifyAll()，但是您将不必要地唤醒无法做任何事情的线程。

在很多情况下，等待条件的代码会被写成循环:

synchronized(o) {
    while (! IsConditionTrue()) {
        o.wait();
    }
    DoSomethingThatOnlyMakesSenseWhenConditionIsTrue_and_MaybeMakeConditionFalseAgain();
}

这样，如果一个o.notifyAll()调用唤醒了多个等待线程，并且第一个从o.wait() make返回的线程将条件保持在false状态，那么其他被唤醒的线程将返回等待状态。

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

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

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