Exchanger同步机制深度解析：实现线程间的对象传递

Exchanger 是专为两个线程“面对面交货”设计的同步工具，要求双方同时到达交换点，原子交换对象引用、零拷贝、无中间状态；不支持多线程、广播或轮换，必须固定绑定两线程，且须使用带超时的 exchange 方法并严格遵循泛型类型安全。

聊到 Exchanger，很多人第一反应是“传数据”，但它的本质更像一次“面对面交货”——两个线程必须同时到达同一个交换点，一手交出自己的对象，一手接过对方的对象。整个过程是原子的，零拷贝，没有中间态，更不需要队列或者缓冲区来兜底。

它只服务一对线程，且必须成对到场

Exchanger 的设计前提非常明确：恰好两个活跃线程参与一次交换。先到的那个线程调用 exchange() 就像进了候车室，只能挂起等待；后到者一抵达，双方立刻完成双向移交。但如果第三个线程也来凑热闹，调用同一个实例，它不会和前两人中的任何一位配对，而是陷入无限等待——除非设了超时，否则极易引发隐性阻塞或资源卡死。因此，实际使用中必须固定绑定两个线程，避免线程池复用或生命周期错位带来的配对混乱。

• 不支持广播、轮换或多线程共享同一实例
• 无法保证“谁跟谁配对”，更不保证跨轮次伙伴一致
• 若某线程异常退出或启动延迟，另一方将长期阻塞

交换的是引用，不是副本

Exchanger 仅交换对象引用，不复制内容、不创建新实例、也不依赖队列缓存。这对 byte[]、ByteBuffer、GameState 等大对象尤其关键——渲染线程填满 backBuffer 后直接 exchange(backBuffer)，显示线程拿到的就是同一块内存地址。省去深拷贝开销的同时，也规避了读写竞争。但也要注意，返回值永远是对方传入的对象，不是自己原来的，交换后原对象的所有权立即转移。所以，双方得事先约定好清空和复用的责任，别把 received 对象误当作自己产出的数据来做逻辑判断。

• 返回值永远是对方传入的对象，不是自己原来的
• 交换后原对象所有权立即转移，需事先约定清空/复用责任
• 切忌把 received 对象误当作自己产出的数据做逻辑判断

超时是生产环境的硬性要求

裸用无参 exchange(V x) 是危险操作，这一点在实战中尤其要重视。网络抖动、GC 暂停、线程崩溃，任何一个环节出问题，都可能导致一方失联，进而拖垮整个流程。所以，必须配上超时机制：

• exchange(V x, long timeout, TimeUnit unit) —— 超时后抛 TimeoutException
• I/O 类任务建议 2–5 秒，计算密集型可设为 10–100 毫秒
• 捕获异常后应记录日志、释放资源，并决定是否降级或重试
• 注意：超时只影响当前线程，对方若后续到达仍会完成交换，但结果无人接收

类型安全与初始化细节不能忽略

泛型声明必须两端严格一致，否则运行时可能 ClassCastException。绕过泛型使用原始类型虽能编译，但强转失败的风险极高。同时，null 允许交换，但易触发 NPE，业务逻辑难以追溯。

• 推荐初始化为非 null 哑值，例如 new byte[0] 或 Optional.empty()
• 双方需提前约定 null 的业务含义（如“跳过本轮”或“重置信号”）
• 泛型如 Exchanger 能在编译期拦截类型混用

还是要强调一下：Exchanger 的适用场景其实非常窄，但一旦合适，效果极好。用它之前，先确认是不是真的一对一线程、是否允许超时报错，以及双方是否提前约定好了对象所有权和生命周期。想清楚这三件事，再用 Exchanger 才不会出乱子。