Exchanger仅支持严格配对的两线程交换，多线程需拆分为独立线程对并各用专属实例；必须使用带超时的exchange()并处理TimeoutException和InterruptedException；交换的是对象引用，需统一缓冲区状态管理与类型语义约定。
Exchanger 本身不支持多线程协同计算，它只保障两个线程之间严格配对交换的稳定性。所谓“多线程协同”，必须拆解为多个独立的线程对（如 A-B、C-D、E-F），每对独占一个 Exchanger 实例；若强行让三个及以上线程共用同一个 Exchanger，第三个线程将永久阻塞——因为它永远等不到“第二个对手”。
必须成对使用，禁止共享实例
Exchanger 内部没有等待队列，也不做轮换或调度。它的状态是二元的：空闲 ↔ 配对中。一旦两个线程完成交换，槽位即清空。第三个线程调用 exchange() 时，发现无人可配，只能挂起等待。
- 错误做法：用固定大小为 3 的线程池共用一个 Exchanger → 必然卡住一个线程
- 正确做法：按业务逻辑明确划分协作关系，例如渲染线程与显示线程配对、校验线程1与校验线程2配对，每对初始化专属 Exchanger 实例
- 若需一对多（如主控线程分发任务给多个工作线程），应改用 Phaser、BlockingQueue + 分发器等更合适的工具
超时机制是稳定性的底线要求
生产环境中，无限等待的 exchange(V) 是高危操作。线程崩溃、GC 暂停、网络抖动、调度延迟都可能导致配对失败，进而引发整对线程长期挂起、资源泄漏甚至服务不可用。
- 必须统一使用带超时版本：
exchange(buf, 3, TimeUnit.SECONDS) - 捕获
TimeoutException后应主动降级：重用上一帧状态、触发断线检测、暂停本方演算、上报监控告警 - 同时响应
InterruptedException，捕获后调用Thread.currentThread().interrupt()恢复中断状态，确保协作循环可被外部终止
交换前后保持对象状态可控
Exchanger 只传递引用，不复制内容。这意味着双方线程共享同一对象实例，任何一方在 exchange() 前后修改其内部状态（如 ByteBuffer 的 position、limit），都可能破坏对方逻辑。
立即学习“Java免费学习笔记（深入）”；
- 缓冲区应在各自线程内长期复用，避免每轮 new，减少 GC 压力
- 生产者流程建议为：
写入数据 → buf.flip() → exchanger.exchange(buf) → buf.clear() - 消费者流程建议为：
接收 buf → 处理数据 → buf.clear() 或 compact() - 严禁在 exchange() 调用中嵌入耗时操作（如日志打印、磁盘 IO、远程调用），否则会拉长阻塞窗口，掩盖真实瓶颈
类型安全与语义对齐不可妥协
泛型声明（如 Exchanger<ByteBuffer>）仅保证编译期类型一致，运行时仍需双方对数据结构、空值约定、缓冲区生命周期达成一致。
- 禁止混用
byte[]和ByteBuffer；避免传null，推荐用哑值替代（如Optional.empty()或new byte[0]） - 交换后拿到的对象是对方传来的快照，不是你刚填的内容——不能当作本地处理结果直接使用
- 校验逻辑应紧接 exchange() 返回之后执行，例如游戏帧同步中立即检查坐标突变、血量异常等作弊信号
