Wait-Notify机制

Wait-Notify机制可以说是实现阻塞操作较为高效的一种方式。虽然在实际中鼓励使用类库中已有的满足条件的类，或基于类库中的类来做满足自己特殊需求的开发，并不建议直接使用如此底层的机制，但了解其原理还是很有必要的。

典型的Wait-Notify场景一般与以下内容相关：
1、状态变量（State Variable）
当线程需要wait的时候，总是因为一些状态不满足导致的。如往BlockingQueue里加元素队列已满的时候。当状态满足的时候，程序就可以执行下去。

2、条件断言（Condition Predicate）
当线程确定是否进入wait或者从notify中醒来的时候是否继续往下执行，大都要测试状态条件是否满足，如往BlockingQueue里加元素队列已满，于是阻塞，后续其它线程从队列里取走了元素，就通知在等待的线程“队列不是满的了，可以往里加东西了”，这时候在等待的线程就会醒来，然后看看是不是真的队列不为满的状态，如果是，就将元素添加进去，如果不是，就继续等待。

3、条件队列（Condition Queue）
每个对象都有一个内置的条件队列，当一个线程在该对象是调用wait的时候，就会将该线程加入该对象的条件队列。

基于以上，接下来说说wait（以及其它两个带超时时间的wait重载版本，后文如无特别说明，wait就表示这三种操作）、notify（以及notifyAll，后文若无特别说明，notify表示这两种操作）操作。

在调用wait、notify的时候，必须先持有锁，且状态变量须由该锁保护，而内置锁对象与内置条件队列对象又是同一个对象。也就是说，要在某个对象上执行wait，notify，先必须锁定该对象，而对应的状态变量也是由该对象锁保护的。如果在调用wait、notify的时候没有持有锁，将会抛出以下错误：
Exception in thread “main” java.lang.IllegalMonitorStateException
这很容易通过下面的代码重现：

package com.ticmy.concurrency;

public class TestWatiNotifyMechanism {

    private static Object obj = new Object();

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

        //错误代码，无意义，仅测试用

        obj.wait();

        //obj.notify();

    }

}

如果上述代码在obj上调用wait，而持有其他对象的锁呢？

package com.ticmy.concurrency;

public class TestWatiNotifyMechanism {

    private static Object obj = new Object();

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

        //错误代码，无意义，仅测试用

        synchronized(TestWatiNotifyMechanism.class) {

            obj.wait();

            //obj.notify();

        }

    }

}

情况和没有锁一样。只有在哪个对象上调用wait、notify，就锁定哪个对象才可以。上面的代码，只要锁定obj对象就可以了：

package com.ticmy.concurrency;

public class TestWatiNotifyMechanism {

    private static Object obj = new Object();

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

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

        synchronized(obj) {

            obj.wait();

//          obj.notify();

        }

    }

}

当在obj对象上调用wait操作的时候，就会释放当前持有的锁，并将线程加入到obj所属的条件队列，而后阻塞，直到有其它线程在该obj上调用了notify操作或阻塞线程被中断或wait超时。
当调用Object#notify()方法时，会去唤醒对应对象条件队列中的某个线程，至于唤醒的是哪个线程，这是不确定的，选择是任意性的。当调用Object#notifyAll()方法时，会唤醒条件队列中的所有线程。当唤醒一个线程或所有线程时，这个或这些线程需要自动重新获得原先wait时释放的锁，它（们）并不一定立马就能执行，像其它线程一样，需要等待CPU来调度，需要与其它线程竞争执行前需要获得的锁。

线程的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的。

至于是选择显式的条件队列还是内置的，如同内置锁和Lock一样，取决于应用是否需要使用内置条件队列无法提供而显式条件队列提供了的特性。如果已使用了Lock，那么使用Condition是自然而然的事情。