Spring事务通过ThreadLocal实现同一线程内Connection复用，核心是TransactionSynchronizationManager的resources（ThreadLocal<Map<DataSource, ConnectionHolder>>）；子线程因ThreadLocal隔离无法获取主线程连接，需手动干预如TransactionTemplate或资源快照复制。
Spring 事务能保证同一线程内多次数据库操作复用同一个 Connection，关键就在于 ThreadLocal 和 TransactionSynchronizationManager 的配合。它不是靠“传递”连接，而是让每个线程自己“认领”属于自己的那一份资源。
ThreadLocal 是怎么存连接的
TransactionSynchronizationManager 内部用了多个 ThreadLocal 变量，其中最重要的是：
-
resources：类型是
ThreadLocal<Map<Object, Object>>，key 是 DataSource，value 是封装了 Connection 的ConnectionHolder - synchronizationActive：标记当前线程是否处于事务中
- synchronizations：存放事务生命周期回调（比如提交后发消息）
当你在 @Transactional 方法里第一次调用 JdbcTemplate 或 MyBatis，DataSourceTransactionManager 就会从数据源获取一个 Connection，包装成 ConnectionHolder，然后通过 TransactionSynchronizationManager.bindResource(dataSource, holder) 存进当前线程的 resources Map 里。
后续操作怎么拿到同一个连接
只要还在同一个线程里，任何后续 DAO 调用都会走同样的流程：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 调用
DataSourceUtils.getConnection(dataSource) - 这个方法会先查
TransactionSynchronizationManager.getResource(dataSource) - 如果查到了，就直接返回 holder 里的 Connection；没查到才新建连接
所以，“同一个事务内用同一个 Connection”这件事，本质上是靠 ThreadLocal 实现的线程内单例——不是 Spring 主动分发，而是每个线程自己去“取自己存过的那个”。
为什么子线程拿不到主线程的事务连接
因为 ThreadLocal 天然隔离：
- 主线程存的 ConnectionHolder，只存在主线程自己的 ThreadLocal 副本里
- 子线程有自己的 ThreadLocal 实例，里面是空的，所以它会新建连接、开启新事务（或不开启事务）
- 即使你把主线程的 TransactionStatus 对象传给子线程，也没用——Connection 没绑定过去，事务上下文就断了
这就像每人一把钥匙，只能开自己房间的锁。你把房间号告诉别人，不代表他能用你的钥匙开门。
想跨线程共享事务怎么办
不能靠 ThreadLocal 自动传递，得手动干预：
- 用 TransactionTemplate 在子线程里显式开启新事务，并控制其传播行为（如
REQUIRES_NEW或NOT_SUPPORTED） - 对必须强一致的场景，改用编程式事务 + 补偿逻辑（比如子线程失败后，主线程主动调用回滚接口）
- 避免在事务方法里直接 new Thread 或用普通线程池；如需异步，优先考虑
CompletableFuture.supplyAsync(..., taskExecutor)配合自定义 TaskDecorator，把主线程的资源快照复制过去（仅限简单场景，不推荐用于生产资金类业务）
