Exchanger仅保证交换动作原子、配对、线程安全，可靠性依赖使用方式：严格一对一配对、独占实例、时机对齐、超时防护（必用exchange(V, timeout, unit)）及收发两端数据校验。

Exchanger 本身不保证数据内容正确，只保证交换动作原子、配对、线程安全。可靠性必须靠使用方式来构建——重点在配对控制、时机把控、超时防护和数据校验。

严格限定“一对一”协作关系

Exchanger 天然只服务两个线程：A 等 B，B 等 A。第三个线程调用 exchange() 就会无限等待，没有排队机制，只有死等。

• 每个协作单元（比如一对图像渲染+显示线程）应独占一个 Exchanger 实例，不要在线程池里复用
• 避免动态增减线程，例如某线程因异常退出后，另一方仍在阻塞等待，建议配合 try-finally 或生命周期钩子做兜底通知
• 不要把 Exchanger 当作通用通信通道，它不是 BlockingQueue，也不支持多线程广播或轮询

交换时机必须与数据就绪严格对齐

exchange() 是交付动作，不是启动信号。提前调用等于交出未完成的数据。

• 写完 buffer 再 exchange，而不是 new 出对象就立刻交换
• 发送前完成所有预处理（如序列化、校验、填充），接收后立即做基础检查（非 null、长度合法、关键字段存在）
• 耗时操作（IO、计算、网络请求）一律放在 exchange() 前后，不在其调用栈内执行

超时是生产环境的强制要求

无超时的 exchange(V) 在 GC 暂停、逻辑卡顿或线程崩溃时会导致协作流程彻底僵死。

• 统一使用 exchange(V, timeout, unit)，3 秒是多数流水线场景的合理起点
• 捕获 TimeoutException 后必须有明确策略：跳过本轮、触发告警、走降级路径，不能仅打印日志
• 同时处理 InterruptedException，并调用 Thread.currentThread().interrupt() 恢复中断状态

接收端要做最小必要校验

对方传来的数据不等于可用数据。Exchanger 不校验内容，只交换引用。

• 检查返回值是否为 null（尤其对方可能提前退出或抛异常）
• 验证关键字段是否存在、类型是否匹配、业务标识是否有效
• 避免把解析逻辑塞进 exchange() 返回值处理中，应在交换后单独解包并容错