JUC虚假唤醒（六）

为什么条件锁会产生虚假唤醒现象（spurious wakeup）？

在不同的语言，甚至不同的操作系统上，条件锁都会产生虚假唤醒现象。所有语言的条件锁库都推荐用户把wait()放进循环里：

while (!cond) {

    lock.wait();

}

这个一般出现在多线程竞争的时候，when no thread specifically broadcast or signaled that condition variable，也就是没有线程这时候释放锁信号，但是wait也会又返回。（看起来这个属于线程的系统问题,属于几率问题）

如果你采用if的形式的话，就直接往下跑了。

if (!cond) {

    lock.wait();

}

产生了虚假唤醒图示说明：

程序说明：

（1）product <= 0时，两个消费者先后根据if条件判断为“缺货”，都进入wait状态；

（2）另外一个生产者生产了产品之后，通过this.notifyAll();的调用，唤醒了所有的消费线程。使得他们共同执行--produce的操作；也就是说，

--product; // 被执行了两次

但是如果你采用while，他会判别你的锁条件标志还没有被修改，那么会再一次的进入到await的状态中。

这个问题其实很好理解

从wait函数中返回的条件有二，根据顺序为

A，从挂起状态中被唤醒

B，获得cond的锁

如果条件变量被notify,有多个线程同时同时从挂起状态中被唤醒，此时他们会争夺cond的锁。

第一个成功获得锁的线程在临界区中读取cond，并决定是继续wait，还是执行他的工作，选择后者可能会修改cond的状态。

因此，后续获得锁的线程必须确认前面的线程是否修改了cond。notify_one和notify_all，分别对应所有的线程都在等同一个cond或存在多个cond关联到同一个条件变量上。与try_lock不同，条件变量很好地解决了线程的等待问题，不用频繁地争夺锁。

wait, notify, notifyAll 方法说明：

wait：在其他线程调用此对象的 notify()方法或notifyAll()方法前，导致当前线程等待。当前线程必须拥有此对象监视器。该线程发布对此监视器的所有权并等待，直到其他线程通过调用notify方法，或 notifyAll方法通知在此对象的监视器上等待的线程醒来。然后该线程将等到重新获得对监视器的所有权后才能继续执行。
notify：唤醒在此对象监视器上等待的单个线程，直到当前线程放弃此对象上的锁定，才能继续执行被唤醒的线程。如果所有线程都在此对象上等待，则会选择唤醒其中一个线程，选择是任意性的，被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争。
notifyAll：唤醒在此对象监视器上等待的所有线程，直到当前线程放弃此对象上的锁定，才能继续执行被唤醒的线程。被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争。

参考链接

本文主要整理自互联网，主要是便于自己复习知识所用，侵权联系删除，以下为原文参考链接！

【1】为什么条件锁会产生虚假唤醒现象（spurious wakeup）？

【2】JUC 源码分析四 wait notify notifyAll 与条件对象

【3】生产者消费者案例-虚假唤醒