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

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

Exchanger 不是“传数据”，而是“面对面交货”——两个线程必须同时到达同一个交换点，一手交出自己的对象，一手接过对方的对象，整个过程原子、零拷贝、无中间状态。

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

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

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

交换的是引用，不是副本

Exchanger 仅交换对象引用，不复制内容、不创建新实例、不依赖队列缓存。这对 byte[]、ByteBuffer、GameState 等大对象尤其关键——渲染线程填满 backBuffer 后直接 exchange(backBuffer)，显示线程拿到的就是同一块内存地址，省去深拷贝开销，也规避了读写竞争。

• 返回值永远是对方传入的对象，不是自己原来的
• 交换后原对象所有权立即转移，需事先约定清空/复用责任
• 切忌把 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<GameState> 能在编译期拦截类型混用