前言
=====
上一节讲了 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 资源