Java 线程状态与状态间的切换

1. 在 Java 5 以后，线程状态被明确定义在其公共内部枚举类型 java.lang.Thread.State 中，分别是：

1.        NEW（初始化状态）

2.        RUNNABLE（可运行 / 运行状态）

3.        BLOCKED（阻塞状态）

4.        WAITING（无时限等待）

5.        TIMED_WAITING（有时限等待）

6.        TERMINATED（终止状态）

其中，Java 层面中的 BLOCKED、WAITING、TIMED_WAITING 对应到操作系统层面，都是休眠状态。也就是说，线程处于这三种状态之一，那么该线程就不会拥有 CPU 的使用权。

2. NEW 到 RUNNABLE

刚 new 出来的 Thread 对象、且未调用 start()，就处于 NEW 状态。此时还不会执行。当调用了 start()后，线程就从 NEW 状态转换到 RUNNABLE 状态

3. RUNNABLE 到 BLOCKED

只有一种场景会触发 RUNNABLE 到 BLOCKED 状态的转变，那就是线程等待 synchronized 隐式锁。

当线程获取 synchronized 隐式锁、并获取失败时，该线程状态就会从 RUNNABLE 转换成 BLOCKED，当持有锁的线程释放锁，且被阻塞线程获取锁后，该线程状态又从 BLOCKED 转换到 RUNNABLE。

那线程调用阻塞式 API 时，线程是否会进入到 BLOCKED 状态呢？

答案是，在操作系统层面，线程会进入到休眠状态；但在 JVM 层面，Java 线程的状态不会发生变化，仍然是 RUNNABLE。

事实上，JVM 并不关心操作系统调度相关的状态（JVM 把线程调度交给操作系统处理了）。因为在 JVM 看来，等待 CPU 使用权（操作系统层面处于可执行状态）与等待 I/O（操作系统层面处于休眠状态）没有区别，都是在等待某个资源（等待被调度与等待 IO 的反馈，都不会执行），所以都归入了 RUNNABLE 状态。

因此，我们平时所谓的 Java 在调用阻塞式 API 时，线程会阻塞，指的是操作系统线程的状态，并不是 Java 线程的状态。

4. RUNNABLE 到 WAITING

有三种场景会触发这样的转换：

1.        获得 synchronized 的线程，调用 Object 无参的 wait() 方法。

2.        调用无参的 join()。目标线程执行完，该线程又会回到 RUNNABLE 状态

3.        调用 LockSupport.park()。而调用 LockSupport.unpark(Thread thread) 可唤醒目标线程，目标线程的状态又会从 WAITING 状态转换到 RUNNABLE。

5. RUNNABLE 到 TIMED_WAITING

有五种场景会触发这种转换：TIMED_WAITING 和 WAITING 状态的区别，仅仅是触发条件多了超时参数。

1.        调用带超时参数的 Thread.sleep(long millis) 方法；

2.        获得 synchronized 隐式锁的线程，调用带超时参数的 Object.wait(long timeout) 方法；

3.        调用带超时参数的 Thread.join(long millis) 方法；

4.        调用带超时参数的 LockSupport.parkNanos(Object blocker, long deadline) 方法；

5.        调用带超时参数的 LockSupport.parkUntil(long deadline) 方法。

6. RUNNABLE 到 TERMINATED

1.        当线程执行完 run() 方法或执行 run()过程中抛出异常，线程都会进入到 TERMINATED 状态

不过有时候，我们想要主动强制终止 run() 方法的执行，比如 run()方法访问一个很慢的网络，我们不想等了，想终止它。怎么做呢？方法是，调用 interrupt()。

interrupt()和 stop()的区别是，stop() 会真的杀死线程，不给线程喘息的机会，如果线程持有 ReentrantLock 锁，被 stop() 的线程并不会自动调用 ReentrantLock 的 unlock() 去释放锁，这就太危险了。

而 interrupt() 仅仅是通知线程，线程有机会执行一些后续操作，同时也可以无视这个通知。InterruptedException 退出同步代码块会释放当前线程持有的锁，所以相比外部强制 stop 是安全的。

7. 那被 interrupt 的线程，是怎么收到通知的呢？

答：一种是异常，另一种是主动检测。

当线程处在 WAITING、TIMED_WAITING 状态时，如果有其它线程调用该线程的 interrupt()方法，那么会使该线程返回到 RUNNABLE 状态，同时触发 InterruptedException 异常。

这一点也可以从方法签名上看出。对于 WAITING、TIMED_WAITING 状态的触发条件，都是调用了诸如 wait()、join()、sleep() 这样的方法，从这些方法的方法签名上可以看到，当有其它线程调用其 interrupt()方法是，会抛出 InterruptedException 异常。

1.        当线程 A 处于 RUNNABLE 状态时，并且阻塞在 java.nio.channels.InterruptibleChannel 上时，如果其他线程调用线程 A 的 interrupt() 方法，线程 A 会触发 java.nio.channels.ClosedByInterruptException 这个异常；

2.        而阻塞在 java.nio.channels.Selector 上时，如果其他线程调用线程 A 的 interrupt() 方法，线程 A 的 java.nio.channels.Selector 会立即返回。

上述情况都属于被中断的线程通过异常的方式获得了通知。

另一种是主动检测，如果线程处于 RUNNABLE 状态，并且没有阻塞在某个 I/O 操作上，例如中断计算圆周率的线程 A，这时就得依赖线程 A 主动检测中断状态了。

如果其他线程调用线程 A 的 interrupt() 方法，那么线程 A 可以通过 isInterrupted() 方法，检测是不是自己被中断了。