Thread.interrupt()仅设置中断标志，不强制终止线程；线程是否响应取决于其是否主动检查isInterrupted()或进入阻塞态抛出InterruptedException并正确处理。
Thread.interrupt() 本身不会终止线程，它只设置中断标志位；能否安全中断，完全取决于目标线程是否主动检查并响应这个标志。
中断不是“杀线程”，而是发协作信号
调用 thread.interrupt() 后，目标线程的中断状态变为 true，但它的栈帧照常执行、CPU 时间照常分配。Java 不提供强制停机能力（Thread.stop() 已废弃且危险）。这意味着：
- 若线程正执行纯计算（如遍历大数组、加密运算），不会有任何反应，除非它主动调用
isInterrupted()或interrupted() - 若线程正阻塞在
sleep()、wait()、join()、BlockingQueue.take()等方法上，会立即抛出InterruptedException，且中断状态被自动清为false - 中断信号可能“滞留”：如果线程长期不检查、也不进入阻塞点，
interrupt()就只是设了个没人读的 flag
阻塞中被中断：必须恢复中断状态
捕获 InterruptedException 时，最常见错误是“吞掉异常”或仅打印日志后继续运行。这会让上层调度逻辑（比如 ExecutorService.shutdownNow()）彻底丢失中断意图。
正确做法是立即恢复中断状态，并退出当前任务：
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // ← 关键：重置中断标志
return; // 或 throw new RuntimeException("task interrupted", e);
}
-
Thread.currentThread().interrupt()是唯一能重置中断状态的方法 - 不要用
e.printStackTrace()替代处理；更不要写成Thread.interrupted()（那是静态方法，会清空状态） - 如果当前方法声明了
throws InterruptedException，可直接抛出，由调用方处理
非阻塞循环中如何响应中断
对 CPU 密集型任务，需在循环体中显式轮询中断状态。注意别误用 interrupted()：
while (!Thread.currentThread().isInterrupted()) { // ✅ 安全：不改变状态
doHeavyWork();
// 可选：让出时间片，提升中断响应及时性
if (Thread.currentThread().isInterrupted()) break;
}
- 避免
while (!Thread.interrupted())—— 因为interrupted()是静态方法，每次调用都清空状态，第二次进循环就永远为true - 若循环内有子任务（如解析多个文件），应在每个子任务前后检查
isInterrupted() - 长时间计算中插入
Thread.yield()或短时sleep(1)可防止线程独占 CPU 导致中断延迟
和 ExecutorService 配合时的典型陷阱
用 executor.shutdownNow() 并不等于所有任务立刻停止。它只是对所有活跃线程调用 interrupt()，然后返回尚未开始执行的 Runnable 列表。
- 如果提交的任务没响应中断（比如用
while(true)死循环 + 无检查），该线程会持续运行，导致awaitTermination()超时失败 -
shutdownNow()返回的列表里，任务仍可能被后续线程执行——它只取消队列中未启动的，不保证已启动任务退出 - 建议任务实现统一模板：入口检查
if (Thread.currentThread().isInterrupted()) return;，并在关键资源操作前后加检查
真正难的从来不是调用 interrupt()，而是让每一段业务逻辑都默认具备中断感知能力——尤其那些封装在工具类、回调、流式处理中的长时操作。
