Exchanger.exchange 必须一对一配对，仅支持一个生产者与一个消费者线程协作；多于两个线程调用会导致永久阻塞，因其内部无等待队列，仅实现“两人碰头即换”的同步点配对机制。

Exchanger.exchange 不能用于两个生产者或两个消费者之间，它只支持严格的一对一线程协作——必须是一个生产者线程 + 一个消费者线程，且双方调用 exchange() 才能完成缓冲区交换。用错配对关系，线程会永久阻塞。

为什么必须是一对一，而不是“两个生产者”

Exchanger 的设计模型是“同步点配对”，不是“广播”或“队列”。它的内部没有缓冲、不支持重入、不允许多线程竞争同一个实例。如果你启动两个生产者线程都调用 exchanger.exchange(buf)，第一个会卡死等待“那个唯一的另一方”，而第二个会继续卡死——因为没人扮演消费者角色。

• 错误现象：jstack 显示两个线程都停在 Exchanger$Node.block，CPU 低，无异常日志
• 常见误用：把 Exchanger 当作 BlockingQueue 用，试图让多个线程轮流 exchange
• 根本原因：Exchanger 不维护等待队列，只做“两人碰头即换”，多于两人就没人可配对

正确初始化与线程绑定方式

必须在启动前明确固定两个线程的身份，并共用同一个 Exchanger 实例。不能每次 new 一个新实例，也不能在线程池中复用线程执行 exchange。

• ✅ 正确做法：启动时创建两个专用线程，各自持有局部 ByteBuffer，循环调用 exchange()
• ❌ 错误做法：用 Executors.newFixedThreadPool(2) 提交两个 Runnable，线程可能被复用，导致上一轮未配对的等待残留
• ⚠️ 注意：Exchanger 的泛型类型必须一致，否则运行时强转失败（如一个传 ByteBuffer，另一个传 byte[]）

exchange() 调用位置决定双缓冲节奏

交换时机直接控制数据吞吐节奏。填满才换、取空才换，是双缓冲语义的核心。别在缓冲区还剩一半时就调用 exchange()，否则消费者拿到的是脏/不完整数据。

• 生产者侧典型流程：fillData(buf); buf.flip(); exchanger.exchange(buf); buf.clear();
• 消费者侧典型流程：buf = exchanger.exchange(null); process(buf); buf.clear();（注意：传 null 合法，但需双方约定）
• 关键点：交换后必须重置缓冲区状态（clear() 或 compact()），否则下次写入会覆盖或越界
• 别在 exchange() 前后加耗时操作（如 System.out.println、文件写入），这会拉长配对等待窗口，掩盖真实延迟瓶颈

超时机制不是兜底方案，而是故障信号

exchange(V, timeout, unit) 的作用不是“让系统更健壮”，而是帮你快速发现配对缺失。超时后你不该忽略异常继续跑，而应终止线程或触发告警。

• 超时抛出 TimeoutException 意味着：另一端线程已退出、被中断未处理、或逻辑卡死在上游
• 不要设置过长超时（如 30 秒），这会让问题延迟暴露；建议从 500ms 起步，根据实际处理耗时调整
• 捕获 InterruptedException 后务必调用 Thread.currentThread().interrupt()，否则中断信号丢失，上层无法感知

最易被忽略的一点：Exchanger 不管理缓冲区内容生命周期。交换的只是引用，如果某一方在 exchange 后继续读写原缓冲区，就会和另一方产生竞态——必须靠代码约定或封装容器（如带状态标记的 wrapper）来规避。