条件队列大法好：使用wait、notify和notifyAll的正确姿式

前面介绍wait和notify的基本语义，参考条件队列大法好：wait和notify的基本语义。这篇讲讲使用wait、notify、notifyAll的正确姿式。

必定要先看语义，保证本身掌握了基本语义，再来学习如何使用。

基本原理

状态依赖的类

状态依赖的类：在状态依赖的类中，存在着某些操做，它们拥有基于状态的前提条件。也就是说，只有该状态知足某种前提条件时，操做才会继续执行。

例如，要想从空队列中取得元素，必须等待队列的状态变为“非空”；在这个前提条件获得知足以前，获取元素的操做将保持阻塞。

若是是头一次了解状态依赖类的概念，很容易将状态依赖类与并发容器混淆。实际上，两者是不对等的概念：

• 并发容器的关键词是“容器”，其_提供了不一样的并发特征（包括性能、安全、活跃性等方面），用户大多数时候能够直接使用这些容器_。
• 状态依赖的类的关键词是“依赖”，其_提供的是状态同步的基本逻辑，每每用于维护并发程序的状态，例如构建并发容器等_，也能够直接由用户使用。

可阻塞的状态依赖操做

状态依赖类的核心是状态依赖操做，最经常使用的是可阻塞的状态依赖操做。

其本质以下：

acquire lock(on object state) // 测试前须要获取锁，以保证测试时条件不变 while (precondition does not hold) { // pre-check防止信号丢失；re-check防止过早唤醒
  release lock // 若是条件还没有知足，就释放锁，容许其余线程修改条件
  wait until precondition might hold, interrupted or timeout expires
  acquire lock // 再次测试前须要获取锁，以保证测试时条件不变
}
do sth // 若是条件已知足，就执行动做
release lock // 最后再释放锁
复制代码

注释内容可暂时不关注，后面逐项解释。

对应修改状态的操做：

acquire lock(on object state) do sth, to make precondition might be hold release lock 复制代码

条件队列的核心行为就是一个可阻塞的状态依赖操做。

在条件队列中，precondition（前置条件）是一个单元的条件谓词，也即条件队列等待的条件（signal/notify）。大部分使用条件队列的场景，本质上是在基于单元条件谓词构造多元条件谓词的状态依赖类。

正确姿式

version1：baseline

若是将具体场景中的多元条件谓词称为“条件谓词”，那么，构造出来的仍然是一个可阻塞的状态依赖操做。

能够认为，条件谓词和条件队列针对的都是同一个“条件”，只不过条件谓词刻画该“条件”的内容，条件队列用于维护状态依赖，即4行的“wait until”。

理解了这一点后，基于条件队列的同步将变的很是简单。大致上是使用Java提供的API实现可阻塞的状态依赖操做。

key point

基本点：

• 在等待线程中获取条件谓词的状态，若是不知足就等待，知足就继续操做
• 在通知线程中修改条件谓词的状态，以后发出通知

加锁：

• 获取、修改条件谓词的状态是互斥的，须要加锁保护
• 知足条件谓词的值后，须要保证操做期间，条件谓词的状态不变，所以，等待线程的加锁范围应扩展为从检查条件以前开始，而后进入等待，最后到操做以后结束
• 同一时间，只能执行一种操做，对应条件谓词的一次状态转换，所以，通知线程的加锁范围应扩展为从操做以前开始，到发出通知以后结束

API相关：

• 在通知线程等待时，通知线程须要释放本身持有的锁，待条件谓词知足时从新竞争锁。所以，咱们在“通知-等待”模型中使用的锁必须与条件队列关联——在Java中，这一语义都由wait()方法完成，所以，不须要用户显示的释放锁和获取锁。

伪码

使用共享对象shared中的内置锁与内置条件队列。

// 等待线程
synchronized (shared) {
  if (precondition does not hold) {
    shared.wait();
  }
  do sth;
}
复制代码

// 通知线程
synchronized (shared) {
  do sth, to make precondition might be hold;
  shared.notify();
}
复制代码

version2：过早唤醒

Java提供的条件队列（不管是内置条件队列仍是显示条件队列）自己不支持多元条件谓词，所以尽管咱们试图基于条件队列内置的单元条件谓词构造多元条件谓词的状态依赖类，但实际上两者在语义上没法绑定在一块儿——这致使了不少问题。

仍旧之内置条件队列为例。它提供了内置单元条件谓词上的“等待”和“通知”的语义，当内置单元条件谓词知足时，等待线程被唤醒，但该线程没法得知是不是多元条件谓词是否也已经知足。不考虑恶意代码，被唤醒一般有如下缘由：

• 本身的多元条件谓词获得知足（这是咱们最指望的状况）
• 超时（若是你不但愿一直等下去的话）
• 被中断
• 与你共用一个条件队列的多元条件谓词获得知足（咱们不建议这样作，但内置条件队列常常会遇到这样的状况）
• 若是你刚好使用了一个线程对象s做为条件队列，那么线程死亡的时候，会自动唤醒等待s的线程

因此，当线程从wait()方法返回时，必须再次检查多元条件谓词是否知足。改起来很简单：

// 等待线程
synchronized (shared) {
  while (precondition does not hold) {
    shared.wait();
  }
  do sth;
}
复制代码

另外一方面，就算此次被唤醒是由于多元条件谓词获得知足，仍然须要再次检查。别忘了，wait()方法完成了“释放锁->等待通知->收到通知->竞争锁->从新获取锁”一系列事件，虽然“收到通知”时多元条件谓词已经获得知足，但从“收到通知”到“从新获取锁”之间，可能有其余线程已经获取了这个锁，并修改了多元条件谓词的状态，使得多元条件谓词再次变得不知足。

以上几种状况即为“过早唤醒”。

version3：信号丢失

还有一个很难注意到的问题：re-check时，使用while-do仍是do-while？

本质上是一个”先检查仍是先wait“的问题，发生在等待线程和通知线程启动的过程当中。假设使用do-while：若是通知线程先发出通知，等待线程再进入等待，那么等待线程将永远不会醒来，也就是“信号丢失”。这是由于，条件队列的通知没有“粘附性”：若是条件队列收到通知时，没有线程等待，通知就被丢弃了。

要解决信号丢失问题，必须“先检查再wait”，使用while-do便可。

version4：信号劫持

明确了过早唤醒和信号丢失的问题，再来说信号劫持就容易多了。

信号劫持发生在使用notify()时，notifyAll()不会出现该问题。

假设等待线程T一、T2的条件谓词不一样，但共用一个条件队列s。此时，T2的条件谓词获得知足，s收到通知，随机从等待在s上的T一、T2中选择了T1。T1的条件谓词还未知足，通过re-check后再次进入了阻塞状态；而条件谓词已经知足的T2却没有被唤醒。因为T1的过早唤醒，使得T2的信号丢失了，咱们就说在T2上发生了信号劫持。

将通知线程代码中的notify()替换为notifyAll()能够解决信号劫持的问题：

// 通知线程
synchronized (shared) {
  do sth, to make precondition might be hold;
  shared.notifyAll();
}
复制代码

不过，notifyAll()的反作用很是大：一次性唤醒等待在条件队列上的全部线程，除了最终竞争到锁的线程，其余线程都至关于无效竞争。事实上，使用notify()也能够，只须要保证每次都能叫醒正确的等待线程。方法很简单：

• 一个条件队列只与一个多元条件谓词绑定，即“单进单出”。

若是使用内置条件队列，因为一个内置锁只关联了一个内置条件队列，单进单出的条件将很难知足（如队列非空与队列非满）。显式锁（如ReentrantLock）提供了Lock#newCondition()方法，能在一个显式锁上建立多个显示条件队列，能保证知足该条件。

总之，信号劫持问题须要在设计状态依赖类的时候解决。若是能够避免信号劫持，仍是要使用notify()：

// 通知线程
synchronized (shared) {
  do sth, to make precondition might be hold;
  shared.notify();
}
复制代码

final version

大致框架记住后，使用条件队列的正确姿式能够精简为如下几个要点：

• 全程加锁
• while-do 等待
• 要想使用notify，必须保证单进单出

最后给一个以前手撸的生产者消费者模型，明确使用wait、notify、notifyAll的正确姿式，详细参考Java实现生产者-消费者模型。

该例中，生产者与消费者互为等待线程与通知线程；两个条件谓词非空buffer.size() > 0与非满buffer.size() < cap共用同一个条件队列BUFFER_LOCK，须要使用notifyAll避免信号劫持。简化以下：

public class WaitNotifyModel implements Model {
  private final Object BUFFER_LOCK = new Object();
  private final Queue<Task> buffer = new LinkedList<>();
...
  private class ConsumerImpl extends AbstractConsumer implements Consumer, Runnable {
    @Override
    public void consume() throws InterruptedException {
      synchronized (BUFFER_LOCK) {
        while (buffer.size() == 0) {
          BUFFER_LOCK.wait();
        }
        Task task = buffer.poll();
        assert task != null;
        // 固定时间范围的消费，模拟相对稳定的服务器处理过程
        Thread.sleep(500 + (long) (Math.random() * 500));
        System.out.println("consume: " + task.no);
        BUFFER_LOCK.notifyAll();
      }
    }
  }

  private class ProducerImpl extends AbstractProducer implements Producer, Runnable {
    @Override
    public void produce() throws InterruptedException {
      // 不按期生产，模拟随机的用户请求
      Thread.sleep((long) (Math.random() * 1000));
      synchronized (BUFFER_LOCK) {
        while (buffer.size() == cap) {
          BUFFER_LOCK.wait();
        }
        Task task = new Task(increTaskNo.getAndIncrement());
        buffer.offer(task);
        System.out.println("produce: " + task.no);
        BUFFER_LOCK.notifyAll();
      }
    }
  }
...
}
复制代码

建议感兴趣的读者继续阅读源码|并发一枝花之BlockingQueue，从LinkedBlockingQueue的实现中，学习如何保证“一个条件队列只与一个多元条件谓词绑定”以免信号劫持，还能了解到"单次通知"、"条件通知" 等常见优化手段。

总结

条件队列的使用是并发面试中的一个好考点。猴子第一次遇到时一脸懵逼，叽里咕噜也没有答上来，如今写文章时才发现本身根本没有理解。若是本文有哪里说错了，但愿您能经过简书或邮箱联系我，提早致谢。

挖坑系列——之后讲一下wait、notify、notifyAll的实现机制。

---

本文连接：条件队列大法好：使用wait、notify和notifyAll的正确姿式
做者：猴子007
出处：monkeysayhi.github.io
本文基于 知识共享署名-相同方式共享 4.0 国际许可协议发布，欢迎转载，演绎或用于商业目的，可是必须保留本文的署名及连接。