Java线程中断仅设置中断标志而非强制终止，线程是否响应由代码决定；阻塞方法抛出InterruptedException并清空中断状态，非阻塞逻辑需手动轮询isInterrupted()并妥善处理中断。
Java线程中断不是“杀掉线程”，而是设置中断标志
很多人以为 Thread.interrupt() 会强制终止线程，实际它只是给目标线程打上一个中断标记（isInterrupted() 返回 true），线程是否响应、何时响应、如何响应，完全由你自己代码决定。JVM 不会替你停止线程执行，也不会抛出异常——除非线程正在阻塞中。
常见错误现象：interrupt() 调用后线程还在跑；或调用后立即抛出 InterruptedException 却没处理，导致中断状态被清除又丢失。
- 阻塞方法（如
Thread.sleep()、Object.wait()、LockSupport.park()）检测到中断时会主动抛出InterruptedException，并自动清除中断状态（即isInterrupted()变为false） - 非阻塞逻辑必须手动轮询
Thread.currentThread().isInterrupted()判断是否该退出 - 若捕获
InterruptedException后不重设中断状态（Thread.currentThread().interrupt()），上层调用者可能再也感知不到中断请求
在循环中正确响应中断的写法
多数业务线程都在 while 循环里干活，中断响应必须嵌入循环条件或内部判断，否则中断永远不生效。
while (!Thread.currentThread().isInterrupted()) {
// 执行任务
try {
doWork();
Thread.sleep(1000); // 可能抛 InterruptedException
} catch (InterruptedException e) {
// 关键：重新设置中断状态，让外层 while 条件能退出
Thread.currentThread().interrupt();
break; // 或直接 return
}
}
注意：isInterrupted() 是实例方法，检查的是当前线程自身；不要用 someThread.isInterrupted() 去轮询别的线程——那只是快照，不可靠，也不符合协作式中断设计原则。
立即学习“Java免费学习笔记（深入）”；
- 避免用
Thread.interrupted()（静态方法）做循环条件，因为它会清空中断状态，导致下一次检查永远为false - 如果循环体耗时长且不包含阻塞调用，必须在关键位置插入
if (Thread.currentThread().isInterrupted()) break; - 不要在
catch (InterruptedException)中“吞掉”异常又不重置中断——这是最常被忽略的坑
ExecutorService.submit() 提交的任务怎么中断
通过 ExecutorService 提交的 Runnable 或 Callable，不能直接调用 thread.interrupt()，因为线程由线程池管理，你拿不到原始 Thread 引用。必须借助 Future.cancel(true)。
但要注意：Future.cancel(true) 的效果取决于任务是否响应中断：
- 如果任务内部用了
sleep()、wait()等可中断阻塞，cancel(true)会触发InterruptedException，任务提前结束 - 如果任务纯计算、无阻塞、也未轮询中断状态，
cancel(true)只是把Future状态设为 cancelled，线程仍继续跑完 -
Future.isCancelled()返回true并不代表任务已停止，只代表取消请求已发出
实操建议：自己封装的 Runnable 应始终检查中断；使用 CompletableFuture 时，cancel(true) 对底层线程无影响，需配合 Thread.currentThread().isInterrupted() 主动退出。
中断与异常处理混用时的典型陷阱
中断不是异常机制的替代品，但二者常交织。最典型的错误是把 InterruptedException 当普通异常“吃掉”或转成其他异常后丢弃中断语义。
例如：
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException("sleep failed", e); // ❌ 错误：中断状态已丢失
}
正确做法是优先恢复中断状态，再按需包装：
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // ✅ 先恢复
throw new RuntimeException("sleep interrupted", e);
}
- 所有声明抛出
InterruptedException的方法（如BlockingQueue.take()），调用者都有责任决定是否传播中断 - 在框架代码（如 Spring 的
@Async方法）中，中断可能被拦截或忽略，不要依赖它作为唯一退出手段 - 日志中打印
InterruptedException时，务必确认线程是否真正退出——否则可能掩盖资源泄漏或死循环
中断机制的脆弱性在于它完全依赖开发者自觉维护状态和响应逻辑。哪怕只漏掉一处 interrupt() 重置，整个协作链就断了。别指望 JVM 替你兜底。
