exchanger 的技术核心是服务成对线程的无锁 rendezvous：严格双向配对、零拷贝引用交换、无等待队列；需独占实例、轻量调用、显式超时与中断处理，并保障类型安全和缓冲区状态自管理。
Java 中 Exchanger 实现多线程数据高效协同的技术核心，不在于支持“多线程”，而在于精准服务“成对线程”——它本质是双线程间的轻量级 rendezvous（会合）点，靠无锁配对、引用交换和状态自管理达成零拷贝、低延迟协作。
严格双向配对：不是队列，而是手拉手
Exchanger 不维护等待队列，也不调度轮换。两个线程调用同一实例的 exchange()，就像在路口同时抵达并交换包裹：一方交出对象，立刻拿到对方对象，全程无中间存储、无复制、无锁竞争。
- 第三个线程调用会永久阻塞——因为前一次交换后内部槽位已清空，没有“排队”或“接力”机制
- 线程池中复用同一实例极易错配：线程被回收再分配后，可能与上一轮残留等待者“跨轮配对”，导致逻辑混乱或卡死
- 正确做法是每对协作线程独占一个 Exchanger 实例，例如渲染线程 ↔ 显示线程、预处理线程 ↔ 后处理线程
交换动作必须轻量：同步点 ≠ 执行点
exchange() 方法本身只做一件事：原子性地交换两个线程传入的对象引用。所有耗时操作（如 I/O、序列化、GC 触发、复杂计算）都必须放在调用前后，否则会拖慢配对线程，放大端到端延迟。
- 缓冲区场景下，应先填满 buffer → 再调用 exchange(buffer) → 拿到对方 buffer 后立即 clear() 或 compact()
- 避免在 exchange() 内部做日志打印、网络请求或资源释放，这些行为会延长阻塞窗口，掩盖真实瓶颈
- 图像/音视频流水线中，常配合两块固定 ByteBuffer 循环复用，exchange 就是切换控制权的开关
超时与中断必须显式响应：生产环境的健壮底线
无参 exchange(V) 在生产环境风险极高。任一线程因异常退出、延迟启动或被中断，都会导致另一方无限等待。带超时的版本是强制要求。
- 统一使用 exchange(x, timeout, unit)，超时值略大于正常处理耗时（如平均处理 800ms，设 1.5s）
- 捕获 TimeoutException 后需主动释放资源、上报监控、触发降级（如跳过本帧、返回哑值 new byte[0]）
- 捕获 InterruptedException 后必须恢复中断状态：Thread.currentThread().interrupt();，否则协作协议断裂，配对线程无法感知终止信号
类型安全与缓冲区状态自管理：引用交换背后的隐性契约
Exchanger 交换的是对象引用，不是内容拷贝。这意味着双方必须对类型、生命周期和缓冲区状态达成明确约定。
- 泛型声明必须两端一致：Exchanger
不能混用 byte[]，否则运行时 ClassCastException - 避免传 null；若业务允许，用哑值或 Optional 封装，防止 NPE 难以追溯
- 缓冲区对象建议在线程内长期持有，每次 exchange 后由接收方负责重置 position/limit（如 flip() 或 clear()），而非依赖对方清理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
