exchanger 的单向交换本质是强制两个线程一对一配对才能完成交换。仅一个线程调用 exchange() 会无限阻塞，直到另一线程参与；超时仅使当前线程退出，对方仍等待，无法解除配对逻辑。
Exchanger 的单向交换本质是什么
Exchanger 不是“双向同步工具”，它强制要求两个线程配对后才能完成一次交换。如果只有 1 个线程调用 exchange()，它会一直阻塞，直到另一个线程也调用 exchange() —— 这不是设计缺陷，而是语义本身：它描述的是“一对一交接”，不是“广播”或“多对一”。
常见错误现象：
- 线程数不匹配（比如 3 个线程调用
exchange()），导致其中 1 个永远卡在exchange()上 - 在异步任务中误用，以为能“发数据就走”，结果线程被锁死
- 和
BlockingQueue混淆，期待它支持超时后自动丢弃或 fallback
使用场景其实很窄：只适合严格成对协作的阶段式处理，比如双缓冲图像渲染、乒乓式数据处理。
为什么不能靠超时绕过单向限制
exchange(V x, long timeout, TimeUnit unit) 看似能解耦，但超时只是让当前线程跳出阻塞，并不解除配对逻辑。一旦超时，该次交换失败，但对方线程仍卡在原地等你——除非它也设了相同超时，否则形成“半悬挂”。
参数差异要注意：
-
timeout是针对当前线程等待配对者的时长，不是整个交换周期 - 超时后返回
null或抛TimeoutException，但对方线程的exchange()调用状态不受影响 - 若未设超时，就是无期限等待，JVM 线程 dump 里会看到
WAITING on java.util.concurrent.Exchanger$Node
性能影响不大，但可观察性差：没有内置监控，无法知道当前有多少线程在等配对，也没有重试或清理机制。
替代方案选型：按交互模式决定用什么
不要强行把 Exchanger 当通用线程通信工具。根据实际协作关系选：
- 一对多分发 → 用
CopyOnWriteArrayList+volatile标志位，或ConcurrentLinkedQueue做事件广播 - 多对一聚合 →
Phaser控制阶段到达，配合AtomicReferenceArray收集各线程结果 - 异步非对称交换（A 发、B 收，不要求 B 立即回）→
CompletableFuture链式编排，或TransferQueue（注意：仅SynchronousQueue实现了TransferQueue接口） - 需要带条件的交换（如“只和特定 ID 的线程交”）→ 自定义基于
AbstractQueuedSynchronizer的交换器，比改Exchanger更可控
Exchanger 的 Javadoc 明确写了：“It is useful in applications such as genetic algorithms and pipeline designs.” —— 如果你的场景不在这个范围，大概率它不是最优解。
最容易被忽略的线程生命周期问题
Exchanger 不感知线程生死。一个线程调用 exchange() 后崩溃或中断，另一个线程还在等，就会永久挂起。
必须做：
- 所有
exchange()调用都包在try/catch InterruptedException里，并在捕获后主动Thread.currentThread().interrupt() - 避免在
ExecutorService的短命线程（如newCachedThreadPool）中长期持Exchanger，线程复用可能让旧交换状态污染新任务 - 如果用在 Web 容器或 Actor 模型中，务必绑定到明确的生命周期（如请求 scope），而不是静态单例
它不报错，也不警告，只是静默卡住 —— 这类问题在线上往往表现为“偶发线程耗尽”，排查时容易绕远路。
