Spring事务在Exchanger中失效，是因为事务上下文基于ThreadLocal绑定、无法跨线程传递；Exchanger使两个线程各自执行事务方法，形成独立事务，破坏原子性与一致性。
Exchanger 是 Java 并发包中用于线程间**双向交换数据**的工具，它本身不涉及事务上下文，也不感知 Spring 的事务管理机制。而 Spring 声明式事务（@Transactional）依赖于 **代理机制 + ThreadLocal 绑定的事务同步器（如 TransactionSynchronizationManager）**，其生效前提是：方法调用必须经过 Spring 代理、且在同一个线程内完成事务的开启、执行与提交/回滚。
为什么 Exchanger 内部直接调用声明式事务方法会失效？
当你把带 @Transactional 的方法交给两个线程通过 Exchanger.exchange() 交叉执行时，常见风险包括：
- 事务上下文（
TransactionSynchronizationManager中的资源、状态）是线程绑定的，无法跨线程传递； - 若 A 线程在 exchange 前开启了事务，B 线程无法继承或共享该事务；
- 若你在 exchange 后（比如在回调、Runnable 或新线程中）再调用
@Transactional方法，该方法虽能开启新事务，但已脱离原始业务逻辑的原子边界； - Exchanger 不提供“事务协同”能力——它不协调数据库连接、不传播事务定义，更不保证两个操作属于同一逻辑事务。
安全执行的关键原则：事务必须在单一线程内闭环
Spring 的声明式事务无法跨线程生效，这是设计使然，不是配置问题。因此，“在 Exchanger 内部安全执行声明式事务方法”的正解是：不把事务逻辑拆到 exchange 的两端，而是让事务包裹整个协作流程——即把 Exchanger 的数据交换视为**本地内存协作步骤**，所有数据库操作仍由单一线程驱动。
- ✅ 正确做法：主线程（或统一调度线程）先调用
exchanger.exchange()获取另一方数据，再在**同一线程内**调用@Transactional方法处理完整业务（含双方数据）； - ❌ 错误做法：A 线程在自己的事务里调 exchange，然后 B 线程在自己事务里处理数据——这本质是两个独立事务，无法保证 ACID 中的原子性和一致性；
- 若必须双线程协作并写库，应改用异步消息（如 RabbitMQ + 本地事务表）或 Saga 模式，而非 Exchanger。
替代方案建议：避免在并发交换中耦合事务
Exchanger 适合低开销、无状态的数据交换场景（如缓冲区交换、预热数据对齐）。如果业务天然需要跨参与者强一致性（如转账双方账户更新），它就不是合适工具。可考虑：
立即学习“Java免费学习笔记（深入）”；
-
用单线程编排 + 多次 DAO 调用：主线程分别查 A、查 B、校验、更新 A、更新 B，全部包在同一个
@Transactional方法里； - 用分布式事务框架（如 Seata AT 模式），适用于真正跨服务/跨数据源的场景；
- 用事件驱动+补偿：A 更新成功后发事件，B 订阅并执行，失败则触发逆向补偿操作。
补充提醒：即使强行“传事务”，也不安全
有人尝试将 TransactionStatus 或 Connection 手动绑定到另一个线程，这违反 Spring 事务设计约束，会导致：
- 连接被多线程并发使用，引发
SQLException: Connection is closed或数据错乱； - ThreadLocal 状态污染，影响后续请求；
- 事务超时、只读标记、隔离级别等属性失效；
- Spring 无法正确触发
afterCommit回调（如发消息、清理缓存）。
