Exchanger本身不管理线程生命周期，但中断期间若未在catch InterruptedException后调用Thread.currentThread().interrupt()，JVM会自动清除中断状态，导致后续isInterrupted()检查失效，中断意图丢失。
Exchanger 本身不负责线程生命周期管理，但配合中断机制使用时，若在交换过程中发生中断（如调用 interrupt()），必须确保中断状态不丢失——尤其在清理逻辑执行后，要主动恢复中断标志，否则上层无法感知中断意图。
为什么 Exchanger 中的中断容易丢失
当线程在 exchange() 阻塞期间被中断，JVM 会：
- 抛出
InterruptedException； - 自动将当前线程的中断状态清为
false（即isInterrupted()返回false）； - 若未在 catch 块中重置，后续检查（如循环条件
!Thread.currentThread().isInterrupted()）将失效。
带超时的 exchange 场景下如何保持中断
使用 exchange(V, long, TimeUnit) 时，可能因超时或中断同时触发异常。需统一处理：
- 捕获
InterruptedException和TimeoutException； - 在
InterruptedException的 catch 块中，立即调用Thread.currentThread().interrupt()； - 清理资源（如关闭流、释放锁）后，再决定是否退出或重试。
任务清理阶段恢复中断的典型写法
以下是在 Runnable 或 Callable 中安全响应中断并完成清理的模式：
立即学习“Java免费学习笔记（深入）”；
- 先执行必要清理（如关闭数据库连接、回滚事务）；
- 紧接着调用
Thread.currentThread().interrupt()； - 然后 return 或抛出运行时异常（不建议吞掉异常后继续执行）；
- 避免在清理过程中再次调用阻塞方法（如
sleep、take），除非重新检查中断状态。
结合线程池使用时的注意事项
若 Exchanger 操作提交给 ExecutorService 执行，需注意：
- 线程池中的工作线程被中断时，
Future.cancel(true)会调用interrupt()； - 此时任务内部若正处在
exchange()调用中，会触发InterruptedException； - 必须在 catch 中恢复中断，否则线程池可能误判该线程“未被中断”，影响后续复用与终止逻辑。
