InterruptedException 是线程被主动中断时抛出的检查异常，必须显式处理；它仅在调用特定阻塞方法且线程已被 interrupt() 时触发，本质是设置中断状态位并在阻塞点抛异常，而非强制终止线程。
InterruptedException 是线程被主动中断时抛出的检查异常
Java 中 InterruptedException 不是运行时异常，必须显式处理（捕获或声明抛出），否则编译不通过。它只会在调用某些阻塞方法（如 Thread.sleep()、Object.wait()、BlockingQueue.take()）时，且当前线程已被其他线程调用 thread.interrupt() 后才会触发。
关键点：中断不是“杀死线程”，而是设置一个中断状态位 + 在阻塞点抛出异常。你不能靠它来强制终止正在执行 CPU 密集型任务的线程。
正确响应中断：不要简单吞掉 InterruptedException
常见错误是捕获后空 catch 或只打日志，这会丢失中断信号，导致上层无法感知线程已被请求停止。正确做法是恢复中断状态或明确退出逻辑。
- 在 catch 块末尾调用
Thread.currentThread().interrupt()，把中断标志重新设回去 - 如果当前方法能直接退出（比如循环中的工作线程），就 return 或 break，无需重置中断
- 不要在 finally 里重置中断——可能掩盖本应传播的中断
while (!Thread.currentThread().isInterrupted()) {
try {
doWork();
Thread.sleep(1000);
} catch (InterruptedException e) {
// 恢复中断状态，让外层可检测
Thread.currentThread().interrupt();
break; // 或直接 return
}
}
哪些方法会抛出 InterruptedException？
不是所有阻塞操作都响应中断。只有明确声明 throws InterruptedException 的方法才可能抛出它。典型包括：
立即学习“Java免费学习笔记（深入）”；
Thread.sleep(long)-
Object.wait()及带超时的变体 Thread.join()- JUC 包中大部分阻塞工具类方法：
BlockingQueue.put()、BlockingQueue.take()、CountDownLatch.await()、Semaphore.acquire()
注意：Lock.lockInterruptibly() 会响应中断；但 Lock.lock() 不会。同样，ReentrantLock.tryLock() 也不抛中断异常。
中断与线程安全没有直接关系，但常被误用
InterruptedException 本身不涉及共享变量、锁或可见性问题，它只是协作式线程取消机制的一部分。但实践中容易踩坑：
- 在 synchronized 块内被中断，锁仍会被正常释放（JVM 保证），但中断处理逻辑若修改共享状态，需额外同步
- 使用
ExecutorService.shutdownNow()会尝试中断所有 worker 线程，此时每个 task 必须正确处理InterruptedException，否则线程池可能无法真正关闭 - 自定义 Runnable/Callable 中忽略中断，会导致 submit 的任务“假死”——看似运行中，实则无法响应 shutdown
真正影响线程安全的是你怎么在中断响应逻辑里读写共享数据，而不是中断本身。
