等待队列和阻塞队列

您可以假设与每个锁对象关联的队列有两种类型。一个是阻塞队列，包含等待监控器锁的线程，另一个是等待队列，包含等待通知的线程。(线程调用Object.wait时将被放入等待队列)。

每次锁可用时，调度器从阻塞队列中选择一个线程执行。

当调用notify时，等待队列中只有一个线程被放入阻塞队列中争夺锁，而notifyAll将等待队列中的所有线程放入阻塞队列中。

现在你能看出区别了吗? 尽管在这两种情况下，只有一个线程被执行，但使用notifyAll，其他线程仍然得到一个要执行的更改(因为它们在阻塞队列中)，即使它们未能争用锁。

一些指导原则

我基本上建议一直使用notifyAll，尽管可能会有一点性能损失。 仅在以下情况下使用notify:

任何被唤醒的线程都可以使程序继续运行。 性能很重要。

例如: @xagyg的回答给出了一个通知会导致死锁的例子。在他的例子中，生产者和消费者都与同一个锁对象相关。因此，当生产者调用notify时，可以通知生产者或消费者。但是，如果一个生产者被唤醒，它就不能使程序继续进行，因为缓冲区已经满了。因此发生了死锁。 有两种解决方法:

使用@xagyg建议的notifyALl。 使生产者和消费者关联不同的锁对象，并且生产者只能唤醒消费者，消费者只能唤醒生产者。在这种情况下，无论唤醒哪个消费者，它都可以消费缓冲区并使程序继续进行。

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

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

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

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

在这里，所有的醒来都没有多大意义。 Wait notify和notifyall，所有这些都放在拥有对象的监视器之后。如果一个线程处于等待阶段，并且调用了notify，那么这个线程将占用该锁，此时没有其他线程可以占用该锁。所以并发访问根本不能发生。据我所知，只有在锁定对象后才能调用wait notify和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。

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

基本上:

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

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

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

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

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

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

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

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

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

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

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

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

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