exchanger仅交换对象引用而非数据所有权，不保证内存可见性与线程安全，需配合显式同步、volatile封装、超时机制及缓冲池等策略确保大型数据安全传递。
Exchanger 本身不保证大型 POJO 或字节数组在交换后的线程安全访问，它只做引用交换——传递的是对象地址，不是内容拷贝，也不自动建立内存可见性或所有权边界。要安全传递大型数据，必须额外约定协作协议和同步策略。
明确交换的是引用，不是数据所有权
Exchanger
- 必须约定：交换即“移交使用权”——接收方获得独占读/写权，发送方此后不得再访问该数组
- 推荐做法：发送方交换后立即将本地引用设为 null 或复位（如 Arrays.fill(buffer, (byte)0)），避免误用
- 若需多次复用，建议配合缓冲池（如 ByteBuffer.allocateDirect）+ 显式生命周期管理，Exchanger 不参与回收
确保大对象内容对对方线程可见
即使引用已交换，JVM 不保证数组元素修改对另一线程立即可见。Exchanger 内部虽含内存屏障，但仅保障 exchange() 调用前后的 happens-before 关系，不延伸到数组内部字段。
- 不要依赖数组元素的隐式可见性；若内容由发送方填充，应在 exchange() 前完成所有写操作，并确保无重排序（可用 volatile boolean flag 配合，或直接使用 VarHandle.storeFence）
- 更稳妥方式：将 byte[] 封装进带 volatile 字段的容器类（如 class BufferHolder { volatile byte[] data; }），并在 exchange 前写入 data
- 避免在 exchange() 调用中执行耗时填充逻辑——阻塞配对线程，破坏实时性
强制成对调用 + 超时防护，防止卡死
两个线程必须严格一对一、轮次对齐。任意一方延迟、异常退出或漏调 exchange()，另一方就会无限等待（或超时失败）。
- 永远使用带超时的 exchange(V x, long timeout, TimeUnit unit)，例如 100ms～500ms，视业务延迟容忍度而定
- 捕获 TimeoutException 后，应主动清理状态（如重置 buffer、记录告警、触发降级逻辑），不可忽略
- 禁止第三个线程意外加入；可在启动时用 AtomicBoolean 校验参与线程数，或封装成专用双线程执行器
替代方案更适配大型数据场景
当传输的是 MB 级 byte[] 或复杂 POJO 序列化结果时，Exchanger 的“零拷贝”优势被可见性、生命周期、错误恢复等开销抵消，此时应考虑更健壮的机制：
- 用 SynchronousQueue
+ DirectBuffer 池，支持显式 offer/take 语义和中断响应 - 对 POJO，优先走序列化 + Netty ByteBuf 或 Kryo 零拷贝传输，配合 RingBuffer 实现背压
- 若需绑定物理核与确定性延迟，应结合 Thread Affinity 库（如 Java-Thread-Affinity）+ MappedByteBuffer 共享内存，而非依赖 Exchanger
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
