interruptedexception抛出时会自动清空中断状态，正确做法是在catch块末尾调用thread.currentthread().interrupt()恢复；若方法声明throws interruptedexception应直接抛出；自定义同步逻辑需手动维护中断状态；completablefuture默认不传递中断。
InterruptedException 发生时，线程中断状态会被清空
调用 Thread.sleep()、Object.wait()、LockSupport.park() 等阻塞方法时，若线程被中断，这些方法会抛出 InterruptedException，同时**自动清除当前线程的中断状态**（即 Thread.interrupted() 会返回 false）。这是最常被忽略的前提。
常见错误现象：捕获异常后直接吞掉，或只打日志不恢复状态，导致上层逻辑无法感知中断意图。
- 正确做法是立即恢复中断状态：在
catch (InterruptedException e)块末尾加一句Thread.currentThread().interrupt(); - 不要用
throw new RuntimeException(e)包装后往上抛——这会让调用方失去对中断语义的控制权 - 如果当前方法声明了
throws InterruptedException，优先选择直接抛出，而不是捕获再恢复
在 Runnable/Callable 中处理中断需区分场景
实现 Runnable 或 Callable 时，中断不是“可选优化”，而是协作式取消的核心契约。JDK 线程池（如 ThreadPoolExecutor）依赖中断信号来终止任务。
使用场景举例：定时任务、异步计算、IO 轮询等长生命周期操作。
立即学习“Java免费学习笔记（深入）”；
- 若任务中包含循环，应在每次迭代开头检查
Thread.currentThread().isInterrupted()，避免忽略中断信号 - 不要仅靠捕获
InterruptedException来响应中断——比如在非阻塞计算中，它根本不会触发 - 对于已声明
throws InterruptedException的方法（如BlockingQueue.take()），应让异常穿透，而非强制 try-catch
自定义锁或等待逻辑必须手动维护中断状态
当你写类似自旋等待、条件重试、或基于 Unsafe / LockSupport 的底层同步逻辑时，JVM 不会自动帮你处理中断语义。
参数差异点：相比 Object.wait() 这类标准方法，LockSupport.park() 抛出 InterruptedException 后同样清空中断状态，但不会抛出检查异常，容易漏处理。
- 每次从
park()返回后，必须显式调用Thread.interrupted()判断是否因中断退出 - 若检测到中断，且业务允许取消，应立即清理资源并退出；否则需调用
Thread.currentThread().interrupt()恢复状态 - 避免在 finally 块里无条件恢复中断——可能把本不属于当前任务的中断状态“还回去”
CompletableFuture 链式调用中中断不传递
CompletableFuture 默认不响应中断：即使上游任务被中断，下游 thenApply、join() 等操作也不会抛 InterruptedException，甚至 get() 超时后也只抛 TimeoutException。
性能影响：盲目在回调里加 if (Thread.interrupted()) return; 可能引入额外分支开销，但比丢弃中断更关键。
- 需要中断感知时，改用
CompletableFuture.orTimeout()+exceptionally()捕获ExecutionException并检查 cause 是否为InterruptedException - 若使用
supplyAsync(..., executor)，确保传入的Executor支持中断（如new ThreadPoolExecutor(...)而非ForkJoinPool.commonPool()） - 不要在
thenRun里调用Thread.sleep()却忽略其抛出的InterruptedException——这里仍是普通线程上下文
中断不是错误，是线程间协商取消的信号。最难的不是写那行 Thread.currentThread().interrupt()，而是在层层封装、异步跳转、第三方库嵌套之后，还能让这个信号不被吃掉、不被污染、不被误判。
