Java并发编程学习——Java线程的生命周期

通用线程模型

在操作系统中线程有五种状态，这也是通用的线程模型。这五种状态分别是初始状态(创建),可运行状态(就绪),运行状态,休眠状态(阻塞),终止状态(消亡)。

通用线程模型

对于这五种状态，不同的编程语言会对他们进行简化合并或者细化，就比如Java把这五种状态进行了相应的更改。

Java线程模型

Java线程一共有六种状态，分别是：NEW（初始化状态），RUNNABLE（可运行 / 运行状态），BLOCKED（阻塞状态），WAITING（无时限等待），TIMED_WAITING（有时限等待），TERMINATED（终止状态）。

Java线程模型

而对于BLOCKED，WAITTING，TIMED_WATTING这三种状态可以归于通用线程模型中的休眠状态(阻塞)，而对于通用线程中的运行状态和就绪(可运行状态)，在Java中则对他们进行了合并，合并成了Runnable状态。

Runnable与Blocked状态之间的转换

对于Runnable转换成Blocked状态只有一种情况，那就是在获取synchronized隐式锁失败的时候，线程会从可运行(Runnable)状态转换为Blocked阻塞状态。而当线程获取到了synchronized隐式锁的时候又会从Blocked状态转换到Runnable状态。

但是线程调用阻塞式API的时候不会从Runnable状态转换到Blocked状态，在操作系统层面，线程会进入休眠(阻塞状态)，但是在JVM层面，线程的状态是不会发生变化的，也就是说线程状态还是Runnable。JVM 层面并不关心操作系统调度相关的状态，因为在 JVM 看来，等待 CPU 使用权（操作系统层面此时处于可执行状态）与等待 I/O（操作系统层面此时处于休眠状态）没有区别，都是在等待某个资源，所以都归入了 RUNNABLE 状态。

Runnable和Waitting状态之间的转换

获得synchronized隐式锁的线程调用Object的wait方法
调用无参数的Thread.join(),其中的 join() 是一种线程同步方法，例如有一个线程对象 thread A，当调用 A.join() 的时候，执行这条语句的线程会等待 thread A 执行完，而等待中的这个线程，其状态会从 RUNNABLE 转换到 WAITING。当线程 thread A 执行完，原来等待它的线程又会从 WAITING 状态转换到 RUNNABLE。
调用 LockSupport.park() 方法。其中的 LockSupport 对象，也许你有点陌生，其实 Java 并发包中的锁，都是基于它实现的。调用 LockSupport.park() 方法，当前线程会阻塞，线程的状态会从 RUNNABLE 转换到 WAITING。调用 LockSupport.unpark(Thread thread) 可唤醒目标线程，目标线程的状态又会从 WAITING 状态转换到 RUNNABLE。

Runnable与Timed_Waitting状态之间的转换

调用带超时参数的 Thread.sleep(long millis) 方法
获得 synchronized 隐式锁的线程，调用带超时参数的 Object.wait(long timeout) 方法
调用带超时参数的 Thread.join(long millis) 方法
调用带超时参数的 LockSupport.parkNanos(Object blocker, long deadline) 方法；
调用带超时参数的 LockSupport.parkUntil(long deadline) 方法。

从New到Runnable状态

首先当线程创建的时候就是New状态，而创建线程有两种方式。

一是继承Thread类并重写run方法。

二是实现Runnable接口重写run方法并将该类作为创建Thread的参数。

// 自定义线程对象
class MyThread extends Thread {
  public void run() {
    // 线程需要执行的代码
    ......
  }
}
// 创建线程对象
MyThread myThread = new MyThread();

// 实现 Runnable 接口
class Runner implements Runnable {
  @Override
  public void run() {
    // 线程需要执行的代码
    ......
  }
}
// 创建线程对象
Thread thread = new Thread(new Runner());

而对于从New状态到Runnable状态只需要调用线程的start()方法。

从Runnable状态到Terminated状态

调用stop()或者interrupt()方法，但是对于stop方法官方已经废弃，因为stop方法会直接杀死线程，如果线程已经获得隐式锁，那么这锁也会消失，也就意味着，其他线程再也获取不到这个锁了。类似的方法还有 suspend() 和 resume() 方法，这两个方法同样也都不建议使用了。

而 interrupt() 方法就温柔多了，interrupt() 方法仅仅是通知线程，线程有机会执行一些后续操作，同时也可以无视这个通知。被 interrupt 的线程，是怎么收到通知的呢？一种是异常，另一种是主动检测。

比如有线程A和线程B，线程A调用了线程B的interrupt()方法，这个意思是指线程A告诉线程B——你现在被设置成了中断状态。但是线程B还可以进行操作(因为它有个isInterrupted来决定被中断之后执行的操作)

当线程 A 处于 WAITING、TIMED_WAITING 状态时，如果其他线程调用线程 A 的 interrupt() 方法，会使线程 A 返回到 RUNNABLE 状态，同时线程 A 的代码会触发 InterruptedException 异常。

上面我们提到转换到 WAITING、TIMED_WAITING 状态的触发条件，都是调用了类似 wait()、join()、sleep() 这样的方法，我们看这些方法的签名，发现都会 throws InterruptedException 这个异常。这个异常的触发条件就是：其他线程调用了该线程的 interrupt() 方法。

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

上面这两种情况属于被中断的线程通过异常的方式获得了通知。还有一种是主动检测，如果线程处于 RUNNABLE 状态，并且没有阻塞在某个 I/O 操作上，例如中断计算圆周率的线程 A，这时就得依赖线程 A 主动检测中断状态了。如果其他线程调用线程 A 的 interrupt() 方法，那么线程 A 可以通过 isInterrupted() 方法，检测是不是自己被中断了。