Exchanger 无超时和失效检测机制，一方异常会导致另一方无限阻塞；应使用带超时的 exchange 并捕获 TimeoutException 和 InterruptedException，或改用 SynchronousQueue，辅以监控、探活和线程池隔离。
这是 Exchanger 使用中一个典型且隐蔽的生产问题：当两条线程通过 exchange() 交换数据时，若其中一方异常退出（如未捕获的 RuntimeException）、崩溃（JVM Crash）、或陷入死循环/无限等待（如在 exchange 前卡在 I/O 或 synchronized 块里），另一方就会在 exchange() 调用处无限阻塞——它无法感知对方“已消失”，只能一直等下去。
根本原因：Exchanger 没有超时和失效检测机制
Exchanger 的设计是严格配对的，它不维护线程生命周期状态，也不提供超时重试、心跳探测或自动清理能力。只要一个线程调用了 exchange(v)，它就默认“另一方一定会来”。一旦对方失联，等待线程就彻底失去响应能力，进而拖垮整个工作流。
规避方案：用带超时的 exchange + 显式异常处理
必须放弃无参 exchange()，改用带超时的重载，并主动处理超时与中断：
- 统一使用
exchange(V x, long timeout, TimeUnit unit)，超时时间设为业务可接受的上限（如 3~30 秒，依场景定） - 捕获
TimeoutException和InterruptedException，并做明确恢复动作（如释放资源、记录告警、触发降级逻辑） - 在 exchange 前确保线程处于健康状态（例如检查是否被中断、关键锁是否可快速获取）
更健壮的替代思路：用 SynchronousQueue + 显式超时控制
如果交换语义允许松耦合（即不强求“同一时刻”配对），SynchronousQueue 配合 offer(e, timeout, unit) 和 poll(timeout, unit) 更易管控失败路径：
- 发送方超时失败后可重试、丢弃或走备用通道
- 接收方超时后可主动退出、上报或切换策略
- 双方完全解耦，任一端挂掉不影响另一端继续判断和决策
兜底防护：监控 + 主动探活 + 线程池隔离
仅靠代码逻辑不够，需工程化兜底：
- 对使用 Exchanger 的线程打标（如命名规范、ThreadLocal 记录 start time），配合 JVM 线程 dump 定期扫描长时间阻塞的 exchange 调用栈
- 在关键路径外增设 watchdog 线程，定期检查配对线程存活状态（如通过 volatile 标志位 + 时间戳心跳）
- 将 exchange 逻辑部署在独立的、有拒绝策略的线程池中，避免单条故障线程拖垮全局线程资源
本质上，Exchanger 是一把锋利但高风险的工具——它高效，也极脆弱。真正稳定的并发协作，从来不是靠“理想配对”，而是靠“容忍失败 + 快速止血 + 明确归因”。
