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

这是不对的。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的并发性方面，它们几乎没有不能为你做的事情。

我认为这取决于资源是如何生产和消费的。如果同时有5个工作对象，并且您有5个消费者对象，那么使用notifyAll()唤醒所有线程是有意义的，这样每个线程都可以处理1个工作对象。

如果您只有一个可用的工作对象，那么唤醒所有使用者对象来争夺这个对象有什么意义呢?第一个检查可用工作的线程将得到它，所有其他线程将检查并发现它们无事可做。

我在这里找到了一个很好的解释。简而言之:

The notify() method is generally used for resource pools, where there are an arbitrary number of "consumers" or "workers" that take resources, but when a resource is added to the pool, only one of the waiting consumers or workers can deal with it. The notifyAll() method is actually used in most other cases. Strictly, it is required to notify waiters of a condition that could allow multiple waiters to proceed. But this is often difficult to know. So as a general rule, if you have no particular logic for using notify(), then you should probably use notifyAll(), because it is often difficult to know exactly what threads will be waiting on a particular object and why.

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

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

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

制作人:

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

消费者:

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

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

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

显然，notify唤醒等待集中的一个线程(any)， notifyAll唤醒等待集中的所有线程。下面的讨论应能消除任何疑问。大多数时候应该使用notifyAll。如果您不确定使用哪个，那么使用notifyAll。请看下面的解释。

仔细阅读并理解。如果您有任何问题，请发邮件给我。

查看生产者/消费者(假设是一个具有两个方法的ProducerConsumer类)。IT IS BROKEN(因为它使用notify) -是的，它可能工作-甚至大多数时候，但它也可能导致死锁-我们将看到为什么:

public synchronized void put(Object o) {
    while (buf.size()==MAX_SIZE) {
        wait(); // called if the buffer is full (try/catch removed for brevity)
    }
    buf.add(o);
    notify(); // called in case there are any getters or putters waiting
}

public synchronized Object get() {
    // Y: this is where C2 tries to acquire the lock (i.e. at the beginning of the method)
    while (buf.size()==0) {
        wait(); // called if the buffer is empty (try/catch removed for brevity)
        // X: this is where C1 tries to re-acquire the lock (see below)
    }
    Object o = buf.remove(0);
    notify(); // called if there are any getters or putters waiting
    return o;
}

首先,

为什么我们需要一个while循环围绕等待?

我们需要一个while循环，以防出现这种情况:

消费者1 (C1)进入同步块，缓冲区是空的，因此C1被放入等待集(通过等待调用)。消费者2 (C2)即将进入同步方法(在上面的Y点)，但生产者P1在缓冲区中放入一个对象，然后调用notify。唯一等待的线程是C1，因此它被唤醒，现在试图重新获得点X(上面)的对象锁。

Now C1 and C2 are attempting to acquire the synchronization lock. One of them (nondeterministically) is chosen and enters the method, the other is blocked (not waiting - but blocked, trying to acquire the lock on the method). Let's say C2 gets the lock first. C1 is still blocking (trying to acquire the lock at X). C2 completes the method and releases the lock. Now, C1 acquires the lock. Guess what, lucky we have a while loop, because, C1 performs the loop check (guard) and is prevented from removing a non-existent element from the buffer (C2 already got it!). If we didn't have a while, we would get an IndexArrayOutOfBoundsException as C1 tries to remove the first element from the buffer!

NOW,

为什么我们需要notifyAll?

在上面的生产者/消费者示例中，我们似乎可以使用notify。看起来是这样的，因为我们可以证明生产者和消费者的等待循环上的守卫是互斥的。也就是说，看起来我们不能让一个线程同时在put方法和get方法中等待，因为，为了使它为真，那么下面的条件必须为真:

buf.size() == 0 AND buf.size() == MAX_SIZE(假设MAX_SIZE不为0)

然而，这还不够好，我们需要使用notifyAll。让我们看看为什么……

Assume we have a buffer of size 1 (to make the example easy to follow). The following steps lead us to deadlock. Note that ANYTIME a thread is woken with notify, it can be non-deterministically selected by the JVM - that is any waiting thread can be woken. Also note that when multiple threads are blocking on entry to a method (i.e. trying to acquire a lock), the order of acquisition can be non-deterministic. Remember also that a thread can only be in one of the methods at any one time - the synchronized methods allow only one thread to be executing (i.e. holding the lock of) any (synchronized) methods in the class. If the following sequence of events occurs - deadlock results:

步骤1: - P1将1个字符放入缓冲区

步骤2: P2尝试put -检查等待循环-已经是一个字符-等待

步骤3: P3尝试put -检查等待循环-已经是一个字符-等待

步骤4: - C1尝试获取1个char C2尝试在进入get方法时获取1个字符块 C3尝试在进入get方法时获取1个字符块

步骤5: C1正在执行get方法——获取char，调用notify，退出方法 —notify唤醒P2 但是，C2在P2之前进入方法(P2必须重新获得锁)，所以P2在进入put方法时阻塞 C2检查等待循环，缓冲区中没有更多字符，所以等待 C3在C2之后进入方法，但在P2之前，检查等待循环，缓冲区中没有更多字符，所以等待

步骤6: -现在:有P3, C2，和C3等待! -最后P2获取锁，在缓冲区中放入一个字符，调用notify，退出方法

第七步: P2的通知会唤醒P3(记住任何线程都可以被唤醒) P3检查等待循环条件，缓冲区中已经有一个字符，所以等待。 没有更多线程调用通知和三个线程永久挂起!

解决方案:在生产者/消费者代码(上面)中用notifyAll替换notify。

摘自Java大师Joshua Bloch在Effective Java第二版中的文章:

“第69项:选择并发实用程序而不是等待和通知”。