java.util.Exchanger作为同步器的最优适用场景有哪些？

很多人觉得Exchanger可以被TransferQueue替代，本质是没搞清楚两者的设计目标差异：Exchanger是仅面向两个线程双工对等交换对象的极简同步器，没有队列存储、多生产者消费者调度的额外开销；而TransferQueue是面向多生产多消费的通用传输队列，为了通用性牺牲了两两交换场景的性能和代码简洁度。

典型最优适用场景 #

• 遗传算法/分布式计算的交叉迭代场景
  这类场景下通常会启动偶数个工作线程，每两个线程配对完成局部计算后，需要交换各自的计算中间结果做交叉迭代。直接调用exchange(partialResult)即可完成双向交换，不需要额外实现配对逻辑，也不需要维护并发容器存储中间结果。对比TransferQueue实现，代码量可减少50%以上，单对线程交换性能提升30%~70%。
• 高吞吐组件的缓冲区交换场景
  比如日志采集、网络IO转发这类双缓冲实现场景：一个线程负责往缓冲区写数据，另一个线程负责把满缓冲区的数据落地/转发。当缓冲区写满时，两个线程通过Exchanger直接交换空缓冲区和满缓冲区，不需要维护双队列、容量计数器等额外状态，天然避免缓冲区泄漏、队列积压问题。这种场景下Exchanger的无锁slot实现完全没有入队出队的拷贝开销，性能远高于TransferQueue的队列实现。
• 压力测试/链路追踪的请求响应对齐场景
  做接口压测、全链路延迟统计时，需要将请求发送记录和响应结果一一对应。用Exchanger的话，请求发送线程可以将请求ID、发送时间戳直接传递给响应接收线程，响应线程收到响应后直接将响应数据、耗时回传，不需要维护并发HashMap存储请求上下文，省掉了哈希表的读写、扩容开销，也避免了上下文过期清理的逻辑。

什么时候确实不该用Exchanger #

如果你的场景不是严格的两两线程双工交换，比如需要多个生产者、多个消费者，或者只需要单向传递数据，那TransferQueue确实是更合适的选择，这也是很多入门示例用TransferQueue也能实现的原因——示例为了简化通常不会还原Exchanger最优的真实场景。

内容的提问来源于stack exchange，提问作者Victor Grazi