我认为这取决于资源是如何生产和消费的。如果同时有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.

Notify将只通知处于等待状态的一个线程，而Notify all将通知处于等待状态的所有线程，现在所有被通知的线程和所有被阻塞的线程都有资格获得锁，其中只有一个线程将获得锁，所有其他线程(包括之前处于等待状态的线程)将处于阻塞状态。

显然，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。

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

基本上:

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

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

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

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

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

看看@xagyg发布的代码。

假设两个不同的线程正在等待两个不同的条件: 第一个线程等待buf.size() != MAX_SIZE，第二个线程等待buf.size() != 0。

假设在某一点buf.size()不等于0。JVM调用notify()而不是notifyAll()，并且通知第一个线程(而不是第二个线程)。

第一个线程被唤醒，检查buf.size()，它可能返回MAX_SIZE，然后返回等待。第二个线程没有被唤醒，继续等待，不调用get()。

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

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