spring事务通过threadlocal实现同一线程内connection复用，核心是transactionsynchronizationmanager的resources（threadlocal）；子线程因threadlocal隔离无法获取主线程连接，需手动干预如transactiontemplate或资源快照复制。

Spring 事务能保证同一线程内多次数据库操作复用同一个 Connection，关键就在于 ThreadLocal 和 TransactionSynchronizationManager 的配合。它不是靠“传递”连接，而是让每个线程自己“认领”属于自己的那一份资源。

ThreadLocal 是怎么存连接的

TransactionSynchronizationManager 内部用了多个 ThreadLocal 变量，其中最重要的是：

• resources：类型是 ThreadLocal<map object>></map>，key 是 DataSource，value 是封装了 Connection 的 ConnectionHolder
• synchronizationActive：标记当前线程是否处于事务中
• synchronizations：存放事务生命周期回调（比如提交后发消息）

当你在 @Transactional 方法里第一次调用 JdbcTemplate 或 MyBatis，DataSourceTransactionManager 就会从数据源获取一个 Connection，包装成 ConnectionHolder，然后通过 TransactionSynchronizationManager.bindResource(dataSource, holder) 存进当前线程的 resources Map 里。

后续操作怎么拿到同一个连接

只要还在同一个线程里，任何后续 DAO 调用都会走同样的流程：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 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，把主线程的资源快照复制过去（仅限简单场景，不推荐用于生产资金类业务）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南