interrupt() 不会强制终止线程，而是通过设置中断标志并触发可中断阻塞方法抛出 InterruptedException 来实现协作式中断，仅对 sleep、wait、join、LockSupport.park、NIO Channel 操作等有限阻塞有效，需线程主动检查中断状态或处理异常；传统 IO 阻塞和 synchronized/lock() 无法响应中断，应使用 lockInterruptibly() 或超时机制替代。
Java 中 interrupt() 并不能“强制停止”线程，而是给线程打一个中断标记，并在某些阻塞方法中触发 InterruptedException，从而让线程有机会响应并退出。关键在于：**它只对处于可中断阻塞状态（如 sleep、wait、join、LockSupport.park、NIO 的 Channel.read/write 等）的线程生效，且必须由线程自己检查或捕获异常来配合处理。**
哪些阻塞操作会被 interrupt() 打断？
以下常见阻塞调用在被中断时会立即抛出 InterruptedException，并清除当前线程的中断状态（即 isInterrupted() 变为 false）：
Thread.sleep(millis)-
Object.wait()/wait(timeout) Thread.join()-
LockSupport.park()（注意：parkNanos/parkUntil同样响应中断，但不会抛异常，而是返回，需手动检查Thread.interrupted()） - java.nio.channels.InterruptibleChannel 相关操作（如
FileChannel.read()、SocketChannel.connect()等）
interrupt() 对普通循环或 IO 流读取（非 NIO）无效
比如以下代码不会因 interrupt() 而退出：
while (!Thread.currentThread().isInterrupted()) {
// 普通计算或 System.out.println，不涉及可中断阻塞
}
又比如传统 BIO 的 InputStream.read() 是同步阻塞，**不可中断**——调用 interrupt() 不会唤醒它，也不会抛异常，线程会一直卡住，除非数据到达或流关闭。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
✅ 正确做法：改用 NIO 的 InterruptibleChannel（如 SocketChannel），或配合超时机制 + 定期检查中断状态。
如何正确响应中断？
不是调用了 interrupt() 就万事大吉，线程需主动配合。典型模式：
- 在
catch(InterruptedException e)中，通常应恢复中断状态：Thread.currentThread().interrupt();（尤其在无法直接退出当前方法时） - 在循环中，用
Thread.interrupted()（静态方法，会清中断标志）或isInterrupted()（实例方法，不清除）判断是否该退出 - 避免“吞掉”中断异常却不做任何处理（例如空 catch）
示例：
while (!Thread.currentThread().isInterrupted()) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
break; // 或抛出 RuntimeException，让上层处理
}
doWork();
}
interrupt() 不会打断 synchronized 或 Lock.lock()
synchronized 关键字进入临界区的过程不可中断；同样，ReentrantLock.lock() 也是不可中断的（会一直阻塞直到获取锁）。若需可中断的锁等待，应使用：
-
ReentrantLock.lockInterruptibly()—— 调用时若被中断，抛InterruptedException - 或用
tryLock(long, TimeUnit)配合超时和中断检查
基本上就这些。interrupt() 是协作式中断机制，不是暴力终止开关。理解哪些操作可中断、如何响应、以及何时该恢复中断状态，才能写出健壮可取消的并发代码。
