前言

今天我们来分析一下Object的wait/notify方法。虽然明面上是两个方法，但是通过查看Object源码，我们发现wait/notify相关的方法其实一共有5个。而Object总共才12个方法，由此可以看出其重要性。先来看看jdk中的源码。

public final native void notify();
public final native void notifyAll();
public final native void wait(long timeout) throws InterruptedException;
public final void wait(long timeout, int nanos) throws InterruptedException {
    if (timeout < 0) { throw new IllegalArgumentException("timeout value is negative"); }
    if (nanos < 0 || nanos > 999999) { throw new IllegalArgumentException("nanosecond timeout value out of range");}
    if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {
        timeout++;
    }
    wait(timeout);
}
public final void wait() throws InterruptedException {
    wait(0);
}

其中有3个native方法（用c语言实现），另外两个wait方法也是间接调用了wait(long timeout)方法。

1. wait(long timeout, int nanos)，该方法其实并非真正能精确到纳秒，而是通过纳秒四舍五入成微秒的方式来代替
2. wait(0)，方法参数0，是无限等待的意思，如果没有notify，那么就会一直等待下去

既然wait/notify这么重要，它又是拿来做什么呢？其实我们可以使用它们来实现线程间通信。那么什么又是线程通信呢？线程通信的英文名为Thread Signaling，即：线程间互相发送信号的意思，通俗地将就是一个线程等待其他线程发送信号。

假如没有wait/notify，我们怎么实现类似发布订阅功能呢？自然而然地我们想到使用状态标记的方式。伪代码如下：

// 生产者
void produce() {
    修改条件使其满足
    doSomething()
}

// 消费者
void consume() {
    while (条件不满足) {
        Thread.sleep(1000L)
    }
    doSomeThing();
}

这种方式存在一些问题

1. 因为使用了sleep()让线程休眠，所以处理可能存在不及时的情况
2. 如果sleep()休眠时间过短，cpu的消耗就会过多

这两种情况是相互矛盾的，一个问题缓解了，另外一个必然就会加重。所以java自带的wait/notify真是非常的及时和实用。

如何使用

我们写一段demo来看看。

public class WaitNotify {

    private final static Object lock = new Object();

    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override public void run() {
                System.out.println("线程 A 等待拿锁");
                synchronized (lock) {
                    try {
                        System.out.println("线程 A 拿到锁了");
                        TimeUnit.SECONDS.sleep(1L);
                        System.out.println("线程 A 开始等待并放弃锁");
                        lock.wait();
                        System.out.println("被通知可以继续执行 则 继续运行至结束");
                    } catch (InterruptedException e) {
                    }
                }
            }
        }, "线程 A").start();

        try {
            TimeUnit.SECONDS.sleep(1L);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        new Thread(new Runnable() {
            @Override public void run() {
                System.out.println("线程 B 等待锁");
                synchronized (lock) {
                    System.out.println("线程 B 拿到锁了");
                    try {
                        TimeUnit.SECONDS.sleep(3L);
                    } catch (InterruptedException e) {
                    }
                    lock.notify();
                    System.out.println("线程 B 随机通知 Lock 对象的某个线程");
                }
            }
        }, "线程 B").start();
    }
}

执行结果如下

线程 A 等待拿锁
线程 A 拿到锁了
线程 A 开始等待并放弃锁
线程 B 等待锁
线程 B 拿到锁了
线程 B 随机通知 Lock 对象的某个线程
被通知可以继续执行 则 继续运行至结束

我们分析一下代码

1. 线程A和B会抢占lock对象的锁
2. 因为main主线程有sleep()休眠1秒的操作，所以线程A会先拿到锁。
3. 线程A执行到lock.wait()时，会释放锁，并将当前线程状态设置为WAITING状态
4. 线程B获得锁，当执行到lock.notify()时，会通知所有等待队列中的线程，然后继续执行lock.notify()之后的代码，执行完成之后释放锁
5. 锁被释放后，等待队列中的线程会抢占锁，抢到锁的线程A会把线程状态变更为RUNNABLE，然后继续执行wait()之后的代码

这儿需要特别注意，B线程的notify()执行之后，会唤醒A线程，但是A线程并不会马上执行（因为锁还未释放），A线程wait()方法后面的逻辑仍然需要先拿到锁才会执行！

wait()/notify()为什么必须在synchroized中

表面上，如果wait()和notify()不放在synchroized中，执行时会抛出异常IllegalMonitorStateException，即：非法的监视器状态异常。

那么为什么会是这样的呢？主要原因还是因为存在竟态条件！这儿先科普一下，什么是竟态条件？

当两个线程竞争同一资源时，如果对资源的访问顺序敏感，就称存在竞态条件。

wait()的调用必然是在等待某种条件的满足，而条件的满足又是另外一个线程在更改条件之后进行了notify()通知，所以我们期望达到如下的效果：

// 生产者B
void produce() {
    修改条件使其满足
    notify();
    // do something
}

// 消费者A
void consume() {
    while (条件不满足) {
        wait();
    }
    // do something
}

如果不加synchronized，可能出现下面的情况

1. A进入while循环后，但还没有执行wait()方法
2. B更新了条件，通过notify()唤醒等待队列中的线程。这时因为A还没有执行到wait()方法，所以A不会被唤醒。
3. A执行到wait()了，如果除了A之后没有其他线程的notify()通知到A，那么A会一直保持在WAITING状态而得不到后续的执行

那么如果我们加上synchronized后，变成下面这种情况，又可不可以呢？

// 生产者B
void produce() {
    synchronized(obj_a) {
        修改条件使其满足
        obj_b.notify();
        // do something
    }
}

// 消费者A
void consume() {
    synchronized(obj_a) {
        while (条件不满足) {
            obj_b.wait();
        }
        // do something
    }
}

表面上看貌似可以，实际上却是行不通的。因为wait()在线程状态变更之前必然会释放锁，而sychronized可以嵌套包含，这时wait()就不知道应该释放哪个锁了。所以最理所当然地就是把wait()所属对象当做释放的锁，所以JUC的作者就使用了这样一种很直观，又很合理的方式。

最终的呈现如下：

// 生产者B
void produce() {
    synchronized(obj_a) {
        修改条件使其满足
        obj_a.notify();
        // do something
    }
}

// 消费者A
void consume() {
    synchronized(obj_a) {
        while (条件不满足) {
            obj_a.wait();
        }
        // do something
    }
}

实现原理

我们来看看，使用这两个方法的顺序一般是什么样的？

1. 使用wait()、notify()、notifyAll()时，必须先对调用对象加锁
2. 调用wait()方法后，线程状态由RUNNABLE变更为WAITING，并将当前线程放置到对象的等待队列
3. notify()或notifyAll()调用后，等待线程依然不会从wait()返回，需要调用notify()或notifyAll()的线程释放锁之后，等待线程才有机会从wait()返回
4. notify()方法将等待队列中的一个等待线程从等待队列中移到同步队列中，而notifyAll()则是将等待队列中所有的线程全部移到同步队列，被移动的线程状态由WAITING变为BLOCKED
5. 从wait()方法返回的前提是获得了被调用对象的锁

从上述细节可以看到，等待/通知机制依托于同步机制，其目的就是确保等待线程从wait()方法返回后能够感知到通知线程对变量做出的修改。

该图描述了上面的步骤：

image.png

总结

至此，wait()和notify()的讲解就告一段落了，如果还需要了解更底层的原理，必须去看jdk的源码。jdk的源码是非常复杂的，不要轻易去看。里面非常多的细节和扩展，往往会掩盖抽象和原理。不过为了兴趣，也为了自己在java领域更加的深入，不管jdk源码多么多么得复杂，我迟早要介入了解的。

参考链接

1. http://thinkinjava.cn/2018/01/并发编程之-wait-notify-方法剖析
2. https://blog.csdn.net/lengxiao1993/article/details/52296220
3. https://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html
4. http://www.xyzws.com/javafaq/why-wait-notify-notifyall-must-be-called-inside-a-synchronized-method-block/127
5. https://stackoverflow.com/questions/2779484/why-must-wait-always-be-in-synchronized-block
6. http://ifeve.com/thread-signaling/