啃碎并发（八）：深刻分析wait¬ify原理

前言

上一节讲了Synchronized关键词的原理与优化分析，而配合Synchronized使用的另外两个关键词wait¬ify是本章讲解的重点。最简单的东西，每每包含了最复杂的实现，由于须要为上层的存在提供一个稳定的基础，Object做为Java中全部对象的基类，其存在的价值不言而喻，其中wait&notify方法的实现多线程协做提供了保证。

1 源码

今天咱们要学习或者说分析的是 Object 类中的 wait&notify 这两个方法，其实说是两个方法，这两个方法包括他们的重载方法一共有 5 个，而 Object 类中一共才 12 个方法，可见这 2 个方法的重要性。咱们先看看 JDK 中的代码：

就是这五个方法。其中有 3 个方法是 native 的，也就是由虚拟机本地的 c 代码执行的。有 2 个 wait 重载方法最终仍是调用了 wait（long） 方法。

1.wait方法：wait是要释放对象锁，进入等待池。既然是释放对象锁，那么确定是先要得到锁。因此wait必需要写在synchronized代码块中，不然会报异常。

2.notify方法：也须要写在synchronized代码块中，调用对象的这两个方法也须要先得到该对象的锁。notify，notifyAll，唤醒等待该对象同步锁的线程，并放入该对象的锁池中。对象的锁池中线程能够去竞争获得对象锁，而后开始执行。

另一点比较重要，notify，notifyAll调用时并不会释放对象锁。好比如下代码：

虽然调用了notifyAll，可是紧接着进入了一个死循环。致使一直不能出临界区，一直不能释放对象锁。因此，即便它把全部在等待池中的线程都唤醒放到了对象的锁池中，可是锁池中的全部线程都不会运行，由于他们始终拿不到锁。

2 用法

简单示例：

执行结果：

前提：必须由同一个lock对象调用wait、notify方法

lock对象、线程A和线程B三者是一种什么关系？根据上面的结论，能够想象一个场景：

3 相关疑问

3.1 为什么wait¬ify必需要加synchronized锁

从实现上来讲，这个锁相当重要，正由于这把锁，才能让整个wait/notify玩转起来，固然我以为其实经过其余的方式也能够实现相似的机制，不过hotspot至少是彻底依赖这把锁来实现wait/notify的。

synchronized 代码块经过javap生成的字节码中包含 monitorenter 和 monitorexit 指令。以下图所示：

                                    javap生成的字节码

执行 monitorenter 指令能够获取对象的monitor，而 lock.wait() 方法经过调用native方法wait(0)实现，其中接口注释中有这么一句：

表示线程执行 lock.wait() 方法时，必须持有该lock对象的monitor，若是wait方法在synchronized代码中执行，该线程很显然已经持有了monitor。

3.2 为何wait方法可能抛出InterruptedException异常

这个异常你们应该都知道，当咱们调用了某个线程的interrupt方法时，对应的线程会抛出这个异常，wait方法也不但愿破坏这种规则，所以就算当前线程由于wait一直在阻塞，当某个线程但愿它起来继续执行的时候，它仍是得从阻塞态恢复过来，所以wait方法被唤醒起来的时候会去检测这个状态，当有线程interrupt了它的时候，它就会抛出这个异常从阻塞状态恢复过来。

这里有两点要注意：

3.3 notify执行以后立马唤醒线程吗

其实hotspot里真正的实现是退出同步块的时候才会去真正唤醒对应的线程，不过这个也是个默认策略，也能够改的，在notify以后立马唤醒相关线程。

3.4 notifyAll是怎么实现全唤起全部线程

或许你们立马想到这个简单，一个for循环就搞定了，不过在JVM里没实现这么简单，而是借助了monitorexit，上面提到了当某个线程从wait状态恢复出来的时候，要先获取锁，而后再退出同步块，因此notifyAll的实现是调用notify的线程在退出其同步块的时候唤醒起最后一个进入wait状态的线程，而后这个线程退出同步块的时候继续唤醒其倒数第二个进入wait状态的线程，依次类推，一样这这是一个策略的问题，JVM里提供了挨个直接唤醒线程的参数，不过都很罕见就不提了。

3.5 wait的线程是否会影响load

这个或许是你们比较关心的话题，由于关乎系统性能问题，wait/nofity是经过JVM里的park/unpark机制来实现的，在Linux下这种机制又是经过

pthread_cond_wait/pthread_cond_signal来玩的，所以当线程进入到wait状态的时候实际上是会放弃cpu的，也就是说这类线程是不会占用cpu资源