执行IO命令的线程不管是本地IO还是网络IO在JVM中线程其状态都是Runable。相对于操作系统，OS会将当前线程挂起，然后由调度队列另起一个线程来执行。此时硬盘正在与CPU并发工作。当IO完成时，CPU会收到来自硬盘的中断信号。类似于回调的操作，告诉你，已经处理完了，等着收尸吧。
此时之前由操作系统阻塞的线程被唤醒。此时这些状态都是在OS上的，想较于JVM此时的状态仍是Runable。就好比前台或保安坐在他们的位置上，可能没有接待什么人，但你能说他们没在工作吗？
因join()方法而等待的线程是如何唤醒的呢？当一个线程执行完任务时也就是生命周期最后的时光，jvm在关闭线程前会检测阻塞在目标线程对象上的对象。然后执行notifyAll()全部唤醒。
wait() & notifyAll() 方法为什么要放入到同步块儿中呢? 诙谐的说下：首先wait()方法 & notify()方法不放在同步块儿里。编译就会报错，IDE也会提示。
其次重要的是，Lost-wake-up 问题。只要是多线程环境，就会出现
如此，那么线程就无法被唤醒了。需要一种同步的机制，把检查与设置状态变成原子操作。且wait()¬ify()操作不交叉执行。也就是需要共同对同一对象进行加锁与释放锁以保持独立。
- 单核CPU实现所谓的“并发”的基本原理，但其实是快速切换带来的假象。
- 关于线程Runable：通常，Java的线程状态是服务于监控的，如果线程切换得是如此之快，那么区分 ready 与 running 就没什么太大意义了。
- 当你看到监控上显示是 running 时，对应的线程可能早就被切换下去了，甚至又再次地切换了上来，也许你只能看到 ready 与 running 两个状态在快速地闪烁。当然，对于精确的性能评估而言，获得准确的 running 时间是有必要的。
- 现今主流的 JVM 实现都把 Java 线程一一映射到操作系统底层的线程上，把调度委托给了操作系统，我们在虚拟机层面看到的状态实质是对底层状态的映射及包装。JVM 本身没有做什么实质的调度，把底层的 ready 及 running 状态映射上来也没多大意义，因此，统一成为runnable 状态是不错的选择。
- 没有参数的wait()方法等价于wait(0),等价于永远等下去
