exchanger 通过“成对交换”契约、双向栅栏协议、两级 slot/arena 结构、volatile+内存屏障、严格双线程语义、泛型类型安全及无状态设计，确保数据交换的确定性、原子性与可预测性。
Exchanger 在 Java 并发编程中是一个小众但设计精巧的同步工具，其逻辑严密性体现在“成对交换”这一核心契约上：两个线程必须同时到达 exchange() 点，才能完成数据交换；任一参与者提前或缺席，另一方就会阻塞等待——这种强耦合机制天然排除了竞态、丢失更新和中间状态暴露等问题。
基于双向栅栏的原子交换协议
Exchanger 不依赖锁或 CAS 循环重试，而是采用类似“双向栅栏”的协作式协议。内部使用一个 slot + arena 的两级结构：初始阶段尝试用单个 volatile slot 快速配对；失败后转入 arena 数组，按线程哈希分散等待位置，避免伪共享与争用。整个交换过程在底层由 Unsafe.park/unpark 驱动，所有状态变更（如 slot 置空、arena 槽位标记）均通过 volatile 写+内存屏障保证可见性与有序性，确保任意时刻最多只有一对线程能成功交换。
严格双线程语义杜绝数据错配
Exchanger 明确限定仅支持两个线程协作，API 层面不提供多线程广播或轮询能力。这种限制不是缺陷，而是逻辑闭环的关键：
- 每个 exchange() 调用必然对应且仅对应另一次调用，不存在“一对多”或“多对一”导致的数据覆盖或丢失
- 超时参数仅作用于单次等待，不累积、不继承，避免因异常线程退出引发后续调用逻辑漂移
- 若线程在 exchange 中被中断，Exchanger 会主动清理自身状态并抛出 InterruptedException，不会留下残留等待节点
空值与类型安全的边界控制
Exchanger 允许交换 null 值，但要求双方约定语义（例如作为“结束信号”）。它本身不做空值拦截，而是将判空责任交给业务逻辑——这恰恰体现设计克制：不替用户做假设，但通过泛型 T 保证编译期类型一致。若线程 A 传入 String，线程 B 传入 Integer，编译即报错，从源头防止运行时 ClassCastException。
异常传播与资源可预测性
当 exchange() 抛出异常（如 TimeoutException、InterruptedException），调用栈清晰指向具体线程上下文，且 Exchanger 内部无静态资源泄漏。它不持有线程引用、不注册回调、不启动后台线程，所有状态随线程生命周期自然消亡。这意味着在容器化或短生命周期任务中，无需显式销毁或重置实例。
它的严密性不在功能繁复，而在每一条约束都服务于“确定性协作”这一目标：没有魔法，没有隐式状态，没有妥协的兜底逻辑——只要两个线程按契约抵达，结果就唯一、可重现、可推理。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
