Java中断

在Java并发编程中，启动一个线程很容易，但优雅地停止一个线程却往往被忽视。很多开发者习惯使用 volatile boolean 标志位，或者粗暴地吞掉 InterruptedException。

---

1. 引言：为什么需要中断？

在早期的 Java 版本中（JDK 1.0），Thread 类提供了一个 stop() 方法，可以强制终止一个线程。这听起来很美好：你可以像拔掉电源一样立即停止一个正在运行的任务。

然而，stop() 方法很快被标记为 @Deprecated。为什么？

因为强行停止是极其危险的 。当一个线程被 stop() 强行终止时，它会立即释放它持有的所有锁（Monitors）。如果该线程正在修改共享数据（例如从银行账户A转账到B，刚扣了A的钱，还没给B加钱），强制终止会导致数据处于不一致的状态（Corrupted State），并且其他线程会立即看到这部分脏数据。

因此，Java 选择了"中断（Interruption）"。

---

2. 概念辨析：协作式 vs 抢占式

理解中断的核心在于理解它的**协作（Cooperative）**本质。

• 抢占式（Preemptive） ：外部力量强制剥夺你的执行权（如 stop()，或者操作系统的 kill -9）。

• 协作式（Cooperative）：外部并没有真正停止你，只是发出了一个"信号"或"请求"。

Java 的中断本质上是一个标志位。

当你调用 t.interrupt() 时，你并没有真的"杀死"线程 t。你仅仅是将线程 t 内部的一个布尔值（Interrupt Status）置为 true，就像是轻轻拍了一下它的肩膀说："嘿，该停下来了"。

至于线程 t 是立即停止、稍后停止，还是完全无视你的请求，完全取决于线程 t 自己的代码逻辑。

---

3. 核心API：三个容易混淆的方法

这是面试和实战中最大的坑，请务必区分清楚：

方法名	静态/实例	描述	是否清除状态
interrupt()	实例方法	动作 ：中断目标线程。仅仅是将目标线程的中断标志设置为 true。	否
isInterrupted()	实例方法	查询：检查调用该方法的线程对象是否被中断。	否 (只读)
interrupted()	静态方法	查询 ：检查当前执行线程是否被中断。	Yes (副作用)

重点解析 Thread.interrupted()

为什么会有 Thread.interrupted() 这个静态方法，并且它还要清除中断状态？

这是为了复位。在某些循环逻辑中，你可能需要处理完一次中断请求后，擦除这个标记，以便线程可以继续运行并在未来响应下一次中断。这在构建复杂的自定义并发组件时非常有用。

Thread t = new Thread(() -> {
    // ...
});
t.start();

t.interrupt(); // 设置 t 的中断标志为 true

// 检查 t 是否被中断（不会清除标志）
System.out.println(t.isInterrupted()); // true

// 这是一个静态方法！它检查的是"当前线程"（即 main 线程），而不是 t
// main 线程没被中断，所以是 false
System.out.println(Thread.interrupted()); 

---

4. 中断的响应机制：阻塞与非阻塞

线程在不同的状态下，对中断的响应方式截然不同。

4.1 阻塞状态下的中断 (Blocking)

这是最常见的情况。当线程在调用以下方法处于阻塞状态时：

• Thread.sleep()

• Object.wait()

• Thread.join()

• BlockingQueue.take/put

如果此时其他线程调用了该线程的 interrupt()，JVM 的处理流程如下：

1. 唤醒该线程（退出阻塞状态）。

2. 清除 中断标志位（将状态重置为 false）。

3. 抛出 InterruptedException。

为什么必须清除标志位？

因为抛出异常本身就是一种信号。如果抛出异常后标志位依然是 true，后续的逻辑可能会再次误判。JVM 约定：一旦抛出 InterruptedException，说明中断已被"消费"处理，状态归零。

4.2 运行状态下的中断 (Running)

如果线程正在执行 CPU 密集型计算（死循环、复杂运算），调用 interrupt() 没有任何实质性效果 ，除了将标志位置为 true。

线程不会暂停，也不会报错。

这意味着：如果你编写的任务是 CPU 密集型的，你必须手动轮询中断状态。

public void run() {
    while (true) {
        // 这里的代码永远不会停止，即使外部调用了 interrupt()
        calculatePrimeNumbers();
    }
}

public void run() {
    // 每次循环检查中断状态
    while (!Thread.currentThread().isInterrupted()) {
        calculatePrimeNumbers();
    }
    System.out.println("任务被中断，优雅退出");
}

---

5. 深入理解：InterruptedException 的处理哲学

InterruptedException 是 Java 中最被误解的异常之一。它是一个 Checked Exception（受检异常），这意味着编译器强制你必须处理它。

5.1 绝对禁止的操作：生吞异常 (Swallowing)

这是最糟糕的做法：

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    // 啥也不做，或者只打印一个日志
    e.printStackTrace(); 
}

后果：上层调用者（比如线程池、或者你的业务容器）发出了中断请求，结果被你在底层"吞"掉了。调用者以为线程还在运行，或者以为中断未发生，导致程序无法正常停止。

5.2 最佳实践策略

策略一：继续抛出 (Propagate)

如果你的方法不负责处理中断，就应该把它声明在 throws 子句中，让上层去处理。

public void doSomething() throws InterruptedException {
    Thread.sleep(1000); // 不要 try-catch，直接抛出
}

策略二：恢复中断 (Restore)

有些情况下（例如在 Runnable.run() 中），你无法抛出 Checked Exception。此时，你必须捕获异常，并再次调用 interrupt()。

原因 ：正如前面所述，抛出 InterruptedException 会清除 中断标志。为了让后续的代码（或上层容器）知道"刚才发生过中断"，你需要手动把标志位重新置为 true。

public void run() {
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        System.out.println("检测到中断，准备退出...");
        
        // 【关键步骤】恢复中断状态！
        // 这样后续的代码检查 isInterrupted() 时才能感知到
        Thread.currentThread().interrupt(); 
    }
}

---

6. 进阶场景：JUC 与 IO 中的中断

6.1 Lock 框架的响应性

synchronized 关键字获取锁的过程是不可中断 的。如果一个线程在等待 synchronized 锁，你对他调用 interrupt()，它除了记录标记外，依然会死等锁。

Java并发包（JUC）提供了 ReentrantLock，它支持可中断的获取锁方式：

Lock lock = new ReentrantLock();
try {
    // 如果等待过程中被中断，会立即抛出 InterruptedException
    lock.lockInterruptibly(); 
    try {
        // critical section
    } finally {
        lock.unlock();
    }
} catch (InterruptedException e) {
    // 处理中断
}

6.2 Future 与 ExecutorService

在使用线程池时，我们很少直接接触 Thread 对象。我们通过 Future 来管理。

• Future.cancel(true)：这不仅会取消任务，还会向执行该任务的线程发送 interrupt() 信号。

• ExecutorService.shutdownNow()：会尝试中断所有正在执行的任务，并返回等待执行的任务列表。

6.3 传统 BIO vs NIO

• 传统 Socket IO (BIO) ：如果是 InputStream.read() 卡住了，调用 interrupt() 通常无效 （除非底层操作系统支持，但大多数情况无效）。线程会一直卡在 IO 上。解决办法通常是关闭底层的 Socket，这会引发 SocketException。

• NIO (New IO) ：SocketChannel 等实现了 InterruptibleChannel 接口。如果线程阻塞在 channel.read() 上，调用 interrupt() 会导致通道关闭，并抛出 ClosedByInterruptException。这是现代 Java IO 的一大进步。

---

7. 反模式：那些年我们写过的Bug

陷阱一：使用 boolean 标志位代替 interrupt

很多教程教你这样做：

volatile boolean running = true;
public void run() {
    while (running) {
        blockingMethod(); // 如 queue.take()
    }
}

问题：如果 blockingMethod() 一直阻塞（比如队列空了），线程永远卡在那行代码，根本没机会去检查 while(running)。

修正：必须结合 interrupt()，因为 interrupt() 可以打破阻塞。

陷阱二：在循环中错误的 try-catch 位置

// 错误示范
while (!Thread.currentThread().isInterrupted()) {
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        // 仅仅打印日志
        e.printStackTrace();
        // ！！！这里没有 break，也没有 restore interrupt
        // 结果：标志位被清除，循环条件 !isInterrupted() 依然成立
        // 线程只是醒了一下，然后继续死循环 sleep
    }
}

这是初学者最容易犯的错：捕获了异常但没有恢复状态，导致"无限重启"。

Java 的中断机制是一种协议 ，一种礼貌的沟通方式。

1. 中断不是命令：它通过设置标志位来请求停止。

2. 响应是关键 ：无论是通过轮询 isInterrupted()，还是捕获 InterruptedException，代码必须主动响应中断。

3. 恢复现场 ：在捕获异常且无法抛出时，务必调用 Thread.currentThread().interrupt() 恢复状态。

4. 区分场景：了解你的代码是阻塞在 CPU、普通 IO 还是 NIO 上，从而选择正确的取消策略。