wait和notify机制

Wait-Notify机制可以说是实现阻塞操作较为高效的一种方式。

典型的Wait-Notify场景一般与以下内容相关

1.状态变量（State Variable）

当线程需要wait的时候，总是因为一些状态不满足导致的。如往BlockQueue里面加入元素已满的时候。

2.条件断言（Condition Predicate）

当线程确定是否进入wait或者从notify中醒来的时候是否往下执行，大都要测试状态是否满足，如往BlockQueue里面加入元素已满，于是阻塞，后续其他线程从队列里取走了元素，于是在等待的线程“队列不是满的了，可以往里面加东西了”，这时候在等待的线程会醒来，然后看看是不是队列不为满的状态，如果是则将元素家进入，如果不是，就继续等待。

3.条件队列（Condition Queue）

每个对象都有一个内置的条件队列，当一个线程调用该对象的wait方法的时候，就将该线程加入到了该对象的条件队列了。

 

 

基于以上来谈wait和notify操作。在调用wait、notify的时候，必须先持有锁，且状态变量必须由该锁保护，而内置锁对象和内置条件队列对象又是同一个对象。也就是说，要在某个对象上执行wait、notify先必须锁定该对象，而对应的状态变量也是由该对象锁保护的，如果在调用wait、notify的时候没有持有锁，将会抛出一下错误：

Exception....java.lang.IllegalMonitorStateException

 

 

线程的wait操作的典型代码结构如下：

void op() throws InterruptedException {

    synchronized(obj) {

        while(条件不满足) {

            obj.wait();

        }

    }

}

为什么要在循环中wait？有以下几个原因。
1、一个对象锁可能用于保护多个状态变量，当它们都需要wait-notify操作时，如果不将wait放到while中就有问题。例如，某对象锁obj保护两种状态变量a和b，当a的条件断言不成立时发生了wait操作，当b的条件断言不成立时也发生了wait操作，两个线程被加入到obj对应的条件队列中，现在若改变状态变量a的某操作发生，在obj上调用了notifyAll操作，obj对应的条件队列里的所有线程均被唤醒，之前等待a的某个或几个线程去判断a的条件断言可能成立了，但b对应的条件断言肯定仍不成立，而此时等待b的线程也被唤醒了，所以需要循环判断b的条件断言是否满足，如果不满足，继续wait。
2、多个线程wait的同一个状态的条件断言。如BlockingQueue场景下，当前队列是空的，多个线程要从里面取元素，于是都wait了。此时另一个线程往里面添加了一个元素，调用了notifyAll操作，唤醒了所有线程，但只有一个线程能拿到那个新加进来的元素，继续走下去，其它的仍需等待。
3、虚假唤醒。在没有被通知、中断或超时的情况下，线程自动苏醒了。虽然这种情况在实践中很少发生，但是必须通过循环检测条件是否满足的方式来防止其发生，如果不满足该条件，则继续等待。

notify操作有两个方法可用，nofity和notifyAll，顾名思义，前者每次唤醒一个线程，后者唤醒所有线程。当唤醒所有线程的时候，会增加上下文切换、锁竞争。但很多时候，使用notify是有风险的，多个线程在同一个条件队列里等待不同的条件断言成立，极可能本该唤醒的线程没唤醒。那么什么时候才能用notify呢？牛人们已经总结好了，需要满足以下两个条件：
1、该对象的条件队列只关联了一个条件断言，且线程被唤醒后执行的代码逻辑是相同的；
2、单进单出。一次notify（这里不是指notify方法）能唤醒的线程至多一个。

对于第一点，在为什么要循环中wait以及为什么notify方法有风险时已经说过了。对于第二点，比如要实现一个类似开/关锁存器（在构造CountDownLatch的时候传入1）的功能，所有线程调用await()操作，最终某一线程调用countDown()操作，该countDown()操作就需要唤醒所有wait的线程。在这种场景下，第二条是不满足的——使用notify方法，其它线程将无法唤醒。

上面说到的都是内置锁，内置条件队列，与之对应的，有显式锁（Lock），显式条件队列（Lock#newCondition()）
Lock#newCondition()返回一个Condition对象，该对象上对应于操作条件队列的wait和notify方法为：await、signal。与内置锁一样，要调用Condition的await、signal，需要锁定创建该Condition的Lock。如下代码形式：

package com.ticmy.concurrency;

import java.util.concurrent.locks.Condition;

import java.util.concurrent.locks.Lock;

import java.util.concurrent.locks.ReentrantLock;

public class TestWatiNotifyMechanism {

    private static Lock lock = new ReentrantLock();

    private static Condition condition = lock.newCondition();

    public static void main(String[] args) throws Exception {

        //无意义，仅测试用，勿模仿

        lock.lock();

        try {

            condition.await();

        } finally {

            lock.unlock();

        }

    }

}

除了这个对应关系不一样，其他诸如需要在循环中await，以及使用signal()还是signalAll()等原理与前面一致，不再赘述。需要说到的是，它与内置锁、内置条件队列的区别。
1、内置锁对象只有一个条件队列，而显式锁可以通过newCondition方法创建多个条件队列，这样就可以避免不同的条件断言关联同一个条件队列造成的问题。
2、如同Lock比内置锁更灵活一样，显式的条件队列也提供了更多的方法供调用（如等待的时候不可被中断的awaitUninterruptibly方法），更多方法参见java.util.concurrent.locks.Condition的JAVA API。
3、Condition也有wait、notify方法，它们从Object类继承而来，一般实际中不会调用这些方法（要调用这些方法必须持有Condition对象的锁，而不是Lock的锁定）以避免混淆。
4、Condition可以继承Lock的公平策略。如new ReentrantLock的时候传入的公平策略参数。当公平策略为true的时候，signal的时候，Condition中的线程唤醒顺序是FIFO的。