Java线程状态切换与Java中断

1. 前言

最近看到synchronized和ReentrantLock两者的不同点时有这么一句：Lock可以让等待锁的线程响应中断，而synchronized 却不能。对此进行了实验，发现是正确的。接着又看了Java中断的概念和讲解，发现没整明白，反而给我整懵了。于是从下面的角度开始出发重新理解Java中断。

ReentrantLock底层挂起线程是通过java.util.concurrent.locks.LockSupport.park()方法来实现的，注意我这里为什么用‘挂起’一词而不是阻塞，因为从线程状态的层面来说synchronized才是阻塞。
从上面这个细微的差别，想着从Java线程状态出发，分析线程在不同状态下对中断做出如何的响应。

2. Java的6种线程状态

首先弄明白Java线程中各个状态的含义和切换的时机。

Java中对线程状态的定义有6种，定义在java.lang.Thread类的内部枚举类State中，如下：

public enum State {
	//新建状态
    NEW,
	//运行状态
    RUNNABLE,
    //阻塞状态
    BLOCKED,
    //无限期等待状态
    WAITING,
    //限期等待状态
	TIMED_WAITING,
	//结束状态
	TERMINATED;
}

• 新建 NEW：创建后尚未启动的线程处于这种状态，即new了一个线程但还没有调用其start()方法。

• 运行 RUNNABLE：调用了Thread的start()方法后进入该状态，该状态包括了操作系统线程状态中的 Running(正在运行) 和 Ready(准备就绪)，即在Java中处于RUNNABLE的线程有可能正在运行，也有可能正在等待CPU为其分配执行时间。

• 无限期等待 WAITING：处于这种状态的线程不会被分配CPU执行时间，它们要等待被其他线程显式地唤醒。以下方法会让线程进入无限期等待状态：
  1、java.lang.Object.wait()方法；
  2、java.lang.Thread.join()方法，其本质也是调用了wait()；
  3、java.util.concurrent.locks.LockSupport.park()方法，这就解释了上面为什么说挂起而不是阻塞，更加确切地可以说成使线程等待。

• 限期等待 TIMED_WAITING：处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显式地唤醒，在一定时间后他们会由系统自动唤醒。以下方法会让线程进入限期等待状态：
  1、java.lang.Thread.sleep(long)方法；
  2、java.lang.Object.wait(long)方法，参数不能是0；
  3、java.lang.Thread.join(long)方法，参数不能是0；
  4、java.util.concurrent.locks.LockSupport.parkNanos(long)方法；
  5、java.util.concurrent.locks.LockSupport.parkUntil(long)方法。

• 阻塞 BLOCKED：线程被阻塞了，正在等待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生。在程序等待进入同步区域（synchronized）的时候，线程将进入这种状态。

• 结束 TERMINATED：已终止线程的线程状态，线程已经结束执行。

3. Java线程状态切换图

4. Java中断

中断一个线程通过方法Thread.interrupt()，实际上就是会给线程打上一个中断标记，开始标记位为false，调用该方法后就会变为true。
可以通过Thread.interrupted()和Thread.isInterrupted()方法来获取线程的中断标记，这两个方法的区别是interrupted()在调用之后会重置标记位为false，isInterrupted()则不会。

下面是通过实验来得出每种线程状态下触发中断，线程状态会有什么样的改变。
新建(NEW)：该状态下触发中断没有意义，就算在触发之后调用start()方法也不会使中断标记位为true，更不会影响线程的状态。

运行(RUNNABLE)：该状态下触发中断会将线程的中断标记位置为true，也不会影响线程的状态，也不会影响代码执行，若要响应中断需要自己在代码中写判断线程是否中断，然后处理中断的逻辑。

无限期等待(WAITING)：按照最开始的说法，Lock可以让等待锁的线程响应中断，而synchronized 却不能。Lock底层用的 LockSupport.park()，即发生锁争抢时，线程状态会进入无限期等待状态。根据这样的推测，我斗胆的给出一个结论是：在无限期等待状态的线程被触发中断时，会从无限期等待状态转为运行状态，并且中断标记位置为true。

下面是我的测试用例：

public static void main(String[] args) throws InterruptedException {
	Thread thread = new Thread(() -> {
		System.out.println("开始运行, 中断标记: " + Thread.interrupted());
		LockSupport.park();	//使线程进入无限期等待状态
		System.out.println("运行结束, 中断标记: " + Thread.interrupted());
		// 无论何时应该为false,因为第一次调用后就会被清除
		System.out.println("运行结束, 中断标记: " + Thread.interrupted());
	});
	
	thread.start();
	// 当前线程睡眠10s， 确保线程已经进入 WAITING 状态
	Thread.sleep(10 * 1000L);
	System.out.println("线程是否为WAITING 状态: " + (thread.getState() == Thread.State.WAITING));
	// 中断线程
	thread.interrupt();
}

运行结果：

开始运行, 中断标记: false
线程是否为WAITING 状态: true
运行结束, 中断标记: true
运行结束, 中断标记: false

限期等待(TIMED_WAITING)：限期等待状态下的线程被触发中断后，效果和无限期等待状态下的一致。

阻塞(BLOCKED)：synchronized使线程进入的阻塞状态，此时线程被触发中断并不会改变当前的阻塞状态，但是其中断标记会被置为true。
下面是我的测试例子:

public static void main(String[] args) throws InterruptedException {
	//锁对象
	Object lock = new Object();
	//创建线程A，使其先获得锁进入同步区
	Thread threadA = new Thread(() -> {
		System.out.println("线程A即将进入同步区");
		synchronized(lock) {
			System.out.println("线程A已经进入同步区");
			try {
				//睡眠20s后再释放锁，sleep方法不会释放锁
				Thread.sleep(20 * 1000L);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			System.out.println("线程A出同步区");
		}
	});
	//创建线程B，使其抢不到锁进入阻塞状态
	Thread threadB = new Thread(() -> {
		System.out.println("线程B即将进入同步区");
		synchronized(lock) {
			System.out.println("线程B已经进入同步区");
			System.out.println("中断标记: " + Thread.interrupted());
		}
		System.out.println("线程B出同步区");
	});
	
	//先启动A线程
	threadA.start();
	//当前线程睡眠5s，确保A线程运行并进入同步区
	Thread.sleep(5 * 1000L);
	//启动B线程
	threadB.start();
	//当前线程睡眠5s，确保B线程运行并在同步区外等待获取锁
	Thread.sleep(5 * 1000L);
	System.out.println("B线程为阻塞状态: " + (threadB.getState() == Thread.State.BLOCKED));
	//中断B线程操作
	threadB.interrupt();
	//睡眠1s，再次查看B线程是否为阻塞状态
	Thread.sleep(1 * 1000L);
	System.out.println("B线程为阻塞状态: " + (threadB.getState() == Thread.State.BLOCKED));
}

输出结果：

线程A即将进入同步区
线程A已经进入同步区
线程B即将进入同步区
B线程为阻塞状态: true
B线程为阻塞状态: true
线程A出同步区
线程B已经进入同步区
中断标记: true
线程B出同步区

从输出结果看，当触发中断B线程操作后，B线程状态仍为BLOCKED，B线程是在A线程出同步区后才进入可运行状态并且获得锁进入同步区，并且B线程的中断标记为true。

Java中断总结：
Java中断只是将处于RUNNABLE、TIMED_WAITING、WAITING、BLOCKED状态下的线程的中断标记位置为true，不过Java中断会额外对处于TIMED_WAITING、WAITING状态的线程会将其切换为RUNNABLE状态继续执行，处于BLOCKED状态的线程仍然处于BLOCKED状态。

5. I/O阻塞

这里为什么要提及I/O阻塞呢？因为这里的阻塞和上面谈的阻塞不是同一个阻塞，特别容易混淆。我的理解是平时说的’阻塞’是粗略、广泛地指程序代码在某处不会继续往下执行的意思，并不是指代具体线程的状态。就好比平时可以说调用Thread.wait()方法阻塞一下线程，其实实际上线程是进入了无限期等待状态，并不是阻塞状态。

可以做个试验，当调用ServerSocket.accept()来监听端口的时候，线程还是处于RUNNABLE状态，那么说的I/O阻塞到底怎么阻塞的，怎么使代码不继续往下运行的？

之前提到的线程状态全是Java层面定义的，其中Java定义的运行状态(RUNNABLE)还包括操作系统层面的线程状态Ready和Running。所以I/O中的阻塞其实就是当前线程处于操作系统层面的Ready状态，正在等待某种资源准备好，等待系统调度分配CPU时间片，所以不会继续往下执行。

以上是我个人的理解，如有误，欢迎讨论并指正!

---

参考资料：
1、面试官:都说阻塞 I/O 模型将会使线程休眠，为什么 Java 线程状态却是 RUNNABLE
2、<<深入理解Java虚拟机：JVM高级特性与最佳实践（最新第二版）>>