Exchanger不适用于分布式事务场景，仅限单JVM内两个线程间同步交换，无法跨进程、跨网络，也不支持序列化、重试或故障转移；柔性事务应使用消息队列+本地事务表+补偿逻辑实现。
Exchanger 本身不适用于分布式事务场景，也不能直接用于跨进程、跨网络的“柔性补偿”或“异步状态传递”。
Exchanger 的作用范围严格限于单 JVM 内的两个线程
它是一个线程间同步工具，底层依赖 LockSupport.park/unpark 和共享内存，所有交换操作发生在同一进程地址空间中。一旦涉及分布式（即服务部署在不同机器、不同 JVM），Exchanger 就完全失效——它无法穿透网络、不处理序列化、不提供重试、无故障转移能力。
常见误解是把“两个参与者协作”类比为“两个微服务协作”，但这是本质不同的层次：
- Exchanger 协作：Thread-A 和 Thread-B 在同一个 JVM 里碰头交换对象，毫秒级完成，无网络开销
- 分布式协作：Order-Service 和 Stock-Service 通过 HTTP/RPC/MQ 通信，存在延迟、超时、丢包、重复、幂等性等现实问题
柔性事务中真正承担“状态传递”角色的是消息队列
在柔性事务（如最终一致性）实践中，状态不是靠线程交换，而是靠可靠消息 + 本地事务表 + 补偿逻辑来传递和确认：
立即学习“Java免费学习笔记（深入）”；
- 订单服务执行本地事务成功后，向 MQ 发送“扣减库存”消息（带唯一业务 ID）
- 库存服务消费消息，执行本地扣减；成功则发“已处理”回执，失败则触发重试或进入死信队列
- 若库存服务长期不可用，订单服务可通过定时任务发起最大努力通知或人工干预
这个过程中的“状态”是持久化的（写入数据库或消息中间件），而非内存中瞬时交换的对象。
Exchanger 可能出现的误用场景及替代建议
有些开发者试图在本地模拟分布式流程，比如用两个线程分别代表“订单线程”和“库存线程”，再用 Exchanger 传递数据。这种写法：
- 无法反映真实网络异常（如超时、连接中断）
- 掩盖了幂等、重试、事务边界等关键设计点
- 测试通过不代表线上可用，属于伪分布式验证
正确做法是：
- 单元测试阶段：用 Mockito 模拟远程调用，验证补偿逻辑是否触发
- 集成测试阶段：启动真实 MQ（如 RocketMQ 或 Kafka）和两个 Spring Boot 服务实例，走端到端链路
- 状态跟踪：依赖 全局事务 ID + 日志埋点 + 追踪系统（如 SkyWalking），而非线程间变量
如果真要在本地做双线程协同，Exchanger 能做什么
它适合明确限定在单机、双线程、低延迟、强配对的场景，例如：
- 双缓冲图像处理：线程 A 渲染帧 N，线程 B 显示帧 N−1，两者在垂直同步点交换缓冲区引用
- 遗传算法中的个体配对：两个工作线程各自生成候选解，通过 Exchanger 交换并交叉变异
- 流水线阶段交接：前段线程加工完一批数据，与后段线程交换结果集，避免锁和队列开销
这些都不涉及事务、不跨服务、不要求持久化或可追溯，和分布式柔性事务没有技术交集。
