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></bytebuffer>的泛型类型必须一致，否则运行时强转失败（如一个传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）来规避。
