捕获 interruptedexception 后必须调用 thread.currentthread().interrupt() 恢复中断位，否则中断状态丢失导致上层无法感知；线程池任务中同样需正确处理，不可忽略或静默吞掉；循环中遇阻塞调用须在 catch 中重设中断并显式退出。
捕获 InterruptedException 后必须重设中断位
Java 线程被中断时，InterruptedException 是唯一明确告诉你“有人调用了 Thread.interrupt()”的信号。但抛出异常后，JVM 会自动清除当前线程的中断状态（即 Thread.currentThread().isInterrupted() 变成 false）。如果你只是简单地 catch 住、不处理，就等于把中断“吞掉”了——上层代码再也感知不到这次中断。
正确做法是：在 catch 块里立刻调用 Thread.currentThread().interrupt() 恢复中断位。
- 这是响应中断最基础、最关键的一步，否则任何依赖
isInterrupted()的逻辑（比如循环退出条件）都会失效 - 不要用
throw new RuntimeException(e)替代重设中断位；异常类型变了，语义就丢了 - 如果当前方法声明了
throws InterruptedException，也不应直接往上抛而不重设——除非你确定调用方会处理中断
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 必须加这句
return; // 或其他清理后退出逻辑
}线程池任务中不能忽略 InterruptedException
很多人以为提交到 ExecutorService 的 Runnable 或 Callable 不用管中断，反正线程池会管理。错。线程池本身不会帮你传播或恢复中断；它只负责在线程被中断时让 get() 抛 InterruptedException，或者让 awaitTermination() 提前返回。你的任务体内部该响应还是得响应。
- 在
Runnable.run()里调用sleep()、wait()、BlockingQueue.take()等阻塞方法时，必须处理InterruptedException - 别写
catch (InterruptedException e) { /* ignore */ }—— 这是最常见的静默吞中断写法，会导致任务卡死或无法及时取消 - 使用
Future.cancel(true)时，只有目标线程正在阻塞且你已正确恢复中断位，才能真正中断执行
while (!Thread.currentThread().isInterrupted()) 不是万能循环条件
这个写法看着很“标准”，但它只检查中断位，不处理阻塞调用可能抛出的 InterruptedException。一旦循环体内有 queue.poll(1, TimeUnit.SECONDS) 这类带超时的阻塞操作，它仍可能被中断并抛异常——而这时循环还没走到下一轮判断，就直接跳出了。
- 必须把阻塞调用放在
try/catch里，并在catch中重设中断位 + 显式跳出循环 - 不要指望靠循环条件自动退出；中断不是“轮询信号”，而是异步事件，需要主动捕获和响应
- 若循环体里有多个可能抛
InterruptedException的点（比如先take()再sleep()），每个都要单独处理
为什么 ReentrantLock.lockInterruptibly() 比 lock() 更适合可取消场景
lock() 是不可中断的：即使线程已被中断，它仍会一直阻塞直到获取锁。而 lockInterruptibly() 在等待锁的过程中能响应中断，并抛出 InterruptedException——这就让你有机会做清理、退出或重试。
- 在线程池任务中，若需等待共享资源（如数据库连接池、限流器），优先选支持中断的 API
- 注意：
lockInterruptibly()抛异常时，锁一定没拿到，不用解锁；但你要确保后续逻辑不因“以为已加锁”而出错 - 别在
synchronized块里试图中断——它不响应中断，也无法替代lockInterruptibly()
线程中断不是“软杀”，也不是“建议退出”。它是协作式取消的契约，而恢复中断位就是履约的第一行签名。漏掉这一句，整个取消链路就断在你这里。
