摘自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.

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

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

看看@xagyg发布的代码。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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