前言
=====
上一节讲了Synchronized关键词的原理与优化剖析，而配合Synchronized应用的另外两个关键词wait¬ify是本章解说的重点。最简略的货色，往往蕴含了最简单的实现，因为须要为下层的存在提供一个稳固的根底，Object作为Java中所有对象的基类，其存在的价值显而易见，其中wait¬ify办法的实现多线程合作提供了保障。
1 源码
明天咱们要学习或者说剖析的是 Object 类中的 wait¬ify 这两个办法，其实说是两个办法，这两个办法包含他们的重载办法一共有 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资源