前天排查一个线上问题代码里明明白白写着Transactional(rollbackFor Exception.class)库存也扣了可订单状态偏偏没更新最后定位到是同一个类内部的this.updateStock()自调用事务管理器压根没参与。类似的事我这些年见过不少问题的根源几乎都指向同一个组件TransactionManager。这篇文章不打算复述官方文档我想从一个踩坑者的角度把 TransactionManager 的职责边界、选型逻辑、与Transactional的配合机制以及那些让事务静默失效的真实现场完整拆开讲一遍。适合被事务问题折磨过、或者想一次性把 Spring 事务底层搞明白的同学阅读如果你是刚接触事务的新手这篇文章也可以当作一份带导航的地图顺着章节走下来基本能绕开绝大多数高频的坑。1. TransactionManager到底在管什么把手工事务抽象成流水线1.1 没有框架时我们是怎么写事务的如果有人问事务管理很难吗你可能会说不就是拿到 ConnectionsetAutoCommit(false)执行 SQL成功 commit失败 rollbackfinally 里 close 嘛。单看一个数据库连接确实不难难的是当一堆业务方法互相嵌套、互相调用时谁来维护这条完整的边界多个 DAO 操作怎么保证用的是同一个物理连接内层方法想回滚、外层方法想提交最终听谁的这些问题分散在手写代码里很快就会变成一场灾难。TransactionManager 就是用来把这套生命周期管理抽象出来的角色。在 Spring 里它表现为PlatformTransactionManager接口核心方法只有三个getTransaction、commit、rollback。方法虽少每一个背后都挂着一大堆资源绑定、传播逻辑、保存点和回滚标记。理解了这个接口再看 Spring 事务的各种配置会顺畅很多。1.2 一次事务从开始到结束TransactionManager 具体做了什么以最常用的DataSourceTransactionManager为例当你的方法上带有TransactionalSpring 的TransactionInterceptor会执行下面的流程解析方法上的事务属性传播行为、隔离级别、超时时间、只读标志、回滚规则封装成一个TransactionAttribute。调用transactionManager.getTransaction(transactionAttribute)。如果当前线程还没有事务由TransactionSynchronizationManager维护事务管理器会从这个DataSource里getConnection()设置autoCommit false把连接绑定到当前线程的ThreadLocal中。执行业务方法。方法内所有数据库操作通过DataSourceUtils.getConnection(dataSource)获取连接这个方法会优先从当前线程的ThreadLocal里取而不是重新向连接池申请。这一步是关键事务内所有 SQL 必须落在同一个物理连接上。方法正常返回后TransactionInterceptor调用transactionManager.commit(status)方法抛出异常时调用rollback(status)。提交前还有一轮TransactionSynchronization回调给事件发布、缓存清理这类紧跟事务成功之后的逻辑留下钩子。提交或回滚完成后解绑ThreadLocal中的连接归还连接池。你仔细看第 4 步就会发现事务生效不是因为每条 SQL 都被神奇地包了一圈而是因为事务内所有数据库操作必须拿到同一个连接。连接一旦不一致commit 和 rollback 就各管各的了。DataSourceTransactionManager的核心工作之一就是确保当前线程 当前事务这组映射关系稳定存在。1.3 逻辑事务与物理事务isNewTransaction 和 rollbackOnly 的分量当方法嵌套调用时一个业务请求里可能同时存在多个带Transactional的方法。以默认的REQUIRED传播行为为例内层方法发现当前线程已经存在事务不会新开数据库事务而是直接加入现有事务。那么它返回后会 commit 吗不会。TransactionStatus里有一个isNewTransaction标识只有发起第一个物理事务的外层调用者才拥有最终 commit 或 rollback 的资格。在此基础上还有一个非常经典的坑叫rollbackOnly。内层方法如果自己触发了回滚它并不会立刻回滚数据库而是把共享事务标记成rollbackOnly向外层传递一个信号这个事务已经被污染别想提交成功了。外层即使没抛异常commit 时也会收到UnexpectedRollbackException。我第一次遇到这个异常时觉得莫名其妙明明是成功返回的怎么提交失败后来明白了这其实是 TransactionManager 在保护数据一致性既然某个参与者已经决定不做就不允许最终结果出现部分提交。遇到UnexpectedRollbackException优先去查内层方法是否抛过异常、是否把事务标记坏了而不是在最外层找原因。2. Spring里的TransactionManager选型单数据源、JPA与JTA2.1 DataSourceTransactionManager单数据源场景的正确默认Spring Boot 项目只要引入了spring-boot-starter-jdbc或者mybatis-spring-boot-starter容器里就会自动注册DataSourceTransactionManager。大多数情况下你什么都不用配置它就已经在为你工作了。它是最直接的事务管理器事务的粒度就是一个物理连接底层完全依赖Connection.setAutoCommit、commit、rollback。我个人的选型原则很简单——只有单个数据源持久层是 MyBatis 或 JdbcTemplate一律用它。逻辑最简单天然不容易出错。不要为了看起来很高级去换 JTA在没有多个 XA 资源的情况下JTA 只会在两层语义之间引入额外的协调开销。2.2 JpaTransactionManagerEntityManager 伴生的事务协调者如果项目用 Spring Data JPA 或 Hibernate默认注册的就是JpaTransactionManager。它和DataSourceTransactionManager最大的区别在于它要同时管理两个层面的资源——EntitManager 和它背后的 JDBC 连接。Hibernate 的Session本身持有 Connection一级缓存、脏检查、flush 时机全部要依附在一个事务会话里才有意义。JpaTransactionManager在getTransaction时会通过EntityManagerFactory创建并绑定一个EntityManager到当前线程后续 Repository 操作复用同一个EntityManager一级缓存和延迟加载才能正常工作。如果事务边界没覆盖到某个查询你会看到 No EntityManager with actual transaction available for current thread 这类经典报错本质就是当前线程没有绑定任何事务资源。另一个容易被忽视的点在 JPA 事务里混用 JdbcTemplate。JpaTransactionManager内部会把底层的 JDBC Connection 也暴露出来同步绑定到当前线程这样 JdbcTemplate 操作也能加入同一个事务。但如果你在事务里另起一个数据源连接那就是另一个故事了距离假事务只有一步之遥。2.3 JtaTransactionManager跨数据源的交通管制员当一个业务操作必须同时写两个数据库并且要求要么都成功要么都失败单数据源的事务管理器就无能为力了。这时会用到JtaTransactionManager。它自己不直接拿连接而是通过 JTA 事务协调器管理多个 XA 资源常见的实现有 Atomikos、Narayana或应用服务器内置的 JTA。JTA 能带来跨库原子性但代价非常现实两阶段提交期间相关资源要长时间持有锁prepare 之后如果协调者崩溃资源不能立即释放系统可用性会受到直接牵连。所以在架构上JTA 应当被视为最后手段而不是高级方案。能用单库解决的问题就不要制造跨库强一致需求。下面用一张表快速总结三者的适用边界事务管理器数据源数量典型场景主要代价DataSourceTransactionManager单数据源MyBatis / JdbcTemplate 单库操作无法跨库JpaTransactionManager单数据源内部联动 EntityManagerSpring Data JPA / Hibernate需要关注一级缓存与连接同步JtaTransactionManager多数据源XA 跨库强一致协调成本高、锁时间长、可用性风险大3. Transactional 是怎么驱动 TransactionManager 的3.1 默认回滚规则为什么检查异常不触发回滚Transactional的默认回滚规则是只有RuntimeException和Error才触发回滚检查异常checked exception不会。这个设计初衷是检查异常通常代表需要人工干预的问题不一定是数据不一致运行时异常才代表程序已经无法继续往下走。但业务系统往往不这么分类。很多团队复盘数据为什么没回滚时最终都发现业务方法抛的是自定义检查异常事务管理器压根没有收到回滚信号。我的经验是两条第一业务校验失败统一抛RuntimeException子类比如自定义的BizException第二在关键写方法上显式加Transactional(rollbackFor Exception.class)把回滚条件放宽到所有异常。两者结合能覆盖绝大多数由异常类型不匹配导致的脏数据问题。3.2 传播行为新建、加入还是挂起Spring 的七大传播行为从 TransactionManager 视角来看其实都是在回答一个问题当当前线程已存在事务我要怎么办。最关键的两个REQUIRED默认有事务就加入没有就新建。一个业务用例内互相调用所有方法共享同一个物理事务。REQUIRES_NEW挂起当前事务开一个全新的独立事务。典型用途是审计日志不随主业务回滚消息发送不受主业务失败影响。注意它不只是新开一个事务还会把外层连接暂时从当前线程解绑执行完再恢复所以连接获取和释放更频繁开销更高。还有NESTED有事务时创建保存点可以只回滚嵌套的那一部分。它依赖底层数据库的 savepoint 能力在单数据源场景基本可用但高并发环境仍需谨慎验证。至于SUPPORTS、NOT_SUPPORTED、MANDATORY、NEVER属于低频工具类知道它们存在即可生产代码里出现频率极低。3.3 隔离级别、超时和只读TransactionDefinition 的隐藏影响你写在Transactional里的isolation、timeout、readOnly最终都会被封装进TransactionAttribute传给transactionManager.getTransaction()。DataSourceTransactionManager会把隔离级别直接设置到 JDBC 连接的setTransactionIsolation上。这里最常见的失误是只想着用REPEATABLE_READ防幻读却忽略了隔离级别越高锁竞争越激烈长事务持锁时间越长最后连接池被耗尽反而把责任推到连接池配置头上。我的补充习惯是给纯查询方法标注Transactional(readOnly true)。一方面给底层一个只读提示另一方面也是一道语义防线。但不要迷信 readOnly 能提升多少性能真正决定性能的是事务的长度和锁的范围而不是这个标志本身。4. 那些让TransactionManager看不见事务的坑完整排查链路4.1 自调用AOP 代理根本没入场事务失效原因里自调用排在第一位。场景代码长这样Service public class OrderService { public void createOrder() { this.updateStock(); // 没有走代理 } Transactional public void updateStock() { // 扣库存 } }createOrder内部调用updateStock时this.updateStock()调用的是当前对象也就是原始 Bean 的方法而不是 Spring 包装后的代理对象。事务拦截器只挂在代理对象上所以Transactional被直接无视。排查手法把org.springframework.transaction的日志级别调到 TRACE执行一次调用链如果TransactionInterceptor完全没有输出基本可以确认代理没有入场。修复也直接把updateStock挪到独立的 Bean 中注入后调用或者使用AopContext.currentProxy()强制走代理前提是exposeProxy开启。前者更好理解也符合事务方法归属独立的业务协调组件的分层习惯。4.2 private、final、以及代理对象是否真的存在Spring Boot 默认使用 CGLIB 生成子类代理。CGLIB 通过继承目标类来创建子类因此private方法无法重写final方法无法被子类覆盖类声明为final时整个代理直接失效。这些情况下Transactional会被静默跳过不报错、不打日志最让人头疼。排查技巧在方法里用 debug 观察this.getClass().getName()如果类名中不包含$$EnhancerBySpringCGLIB或$Proxy说明当前对象不是代理对象。或者在启动日志里看 Spring 创建的 Bean 是否经过了代理包装。看到真实对象而非代理对象事务注解自然轮不上。4.3 try-catch 吞掉异常带来的假成功比自调用更隐蔽的是异常被吞掉Transactional(rollbackFor Exception.class) public void doBiz() { try { updateData(); } catch (Exception e) { log.error(update failed, e); // 吃掉了方法正常返回 } insertLog(); }TransactionInterceptor看到方法正常返回就认为业务成功于是调用 commit。如果updateData内部已经把共享事务标记为rollbackOnlycommit 会抛出UnexpectedRollbackException但如果你只是自己 catch 了一个异常而没有任何参与方标记事务状态数据库就会提交。数据账面上是没成功库里却是脏结果问题排查周期往往被拉得很长。我的处理原则不在事务方法内部 catch 那些需要让事务回滚的异常。如果确实需要局部补偿先把异常记录下来再继续抛或者把回滚语义明确改造成记录失败状态并正常返回。一句话别让事务方法在看起来正常的状态下偷偷提交一段失败的业务。4.4 新线程与异步ThreadLocal 决定了事务天然不跨线程事务连接绑定在当前线程的ThreadLocal上这是 TransactionManager 最底层的工作方式。因此在方法内new Thread、使用线程池、或者Async让另一个线程执行数据库操作时新线程里既拿不到已经绑定的连接也不会有事务上下文。看起来像事务没生效其实不是——是代码把数据库操作移出了事务范围。如果异步任务必须保证原子性有两条路一是把需要原子性保障的操作放在当前事务方法里同步执行异步只做事务提交后的通知二是异步任务内部自己用TransactionTemplate编程式开启事务。能选第一条就不要选第二条因为异步事务的边界肉眼不可见后期维护成本极高。下面把这一节最典型的失效特征整理成一张速查表方便你现场对照症状根因方向立即检查项事务方法没有 TRACE 日志AOP 代理未介入是否为同类自调用、方法是否 private/final修改了数据但回滚未生效异常被吞或异常类型不符检查 catch 块、检查异常是否 RuntimeException新线程里的操作不参与事务ThreadLocal 线程隔离确认是否在事务内另开线程外层提交时抛 UnexpectedRollbackException内层已标记 rollbackOnly查内层方法回滚路径多数据源下事务失效TransactionManager 绑定错误确认数据源与管理器的对应关系5. 实战订单扣减场景里的事务边界该画在哪5.1 事务边界的核心粒度是业务用例拿常见的电商下单来说一次下单往往涉及四个写操作锁定用户余额、创建订单记录、扣减库存、写入操作流水。这四个动作要么都成功要么都失败。如果事务写在每个 DAO 的 insert/update 方法上就会出现订单插入成功、库存扣减失败订单已提交但无法回滚的情况。事务边界一定要画在完整业务用例这一层通常就是 Service 实现类的一个 public 方法。示例骨架Service public class OrderApplicationService { private final OrderRepository orderRepository; private final StockRepository stockRepository; private final FlowRepository flowRepository; Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderCommand cmd) { memberBalanceService.lock(cmd.getUserId(), cmd.getAmount()); Order order Order.create(cmd); orderRepository.insert(order); int rows stockRepository.deduct(cmd.getSkuId(), cmd.getQuantity()); if (rows 0) { throw new BizException(库存不足); } flowRepository.insert(Flow.of(order)); return order.getId(); } }这里的锁余额、插入订单、扣减库存、写入流水会通过默认的REQUIRED传播共享同一个物理事务。扣减库存影响行数为 0 时抛出BizExceptionTransactionInterceptor捕获后调用 rollback之前的订单和流水全部撤回。5.2 DAO 层不要随手写 Transactional我见过不少团队习惯在每个 DAO 的 update 方法上贴Transactional理由是反正没坏处。实际坏处很明显事务被切得零碎一个用例链路里可能嵌套十几层事务连接可能在方法返回后就被决策逻辑释放后续维护者要反复揣摩这个事务到底想保护什么。更可持续的做法是Service 层方法作为事务单元入口DAO 层只聚焦 SQL 执行领域。如果某个子步骤需要独立提交单独抽到另一个 Bean 的 public 方法上标注Transactional(propagation Propagation.REQUIRES_NEW)并在命名和调用处明确表达独立事务的语义。这样代码结构上一眼就能看出边界。5.3 大事务、长事务和跨系统操作TransactionManager 管不住的边界事务方法里最容易埋雷的是顺手做远程操作——调用第三方 HTTP、写 Redis、发 MQ。这些远程操作不会跟随数据库回滚而且网络等待会拉长事务持有连接的时间。极端情况下一个事务里等上游接口 3 秒超时连接池就会被一堆半死不活的事务占满。我的拆分思路是核心数据库写操作留在事务内把提交后必须执行的远程动作放到事务成功后的回调里比如TransactionSynchronizationManager.registerSynchronization或者更直白地在事务提交之后人工调用发送。如果业务要求MQ 必须发布成功订单才算完成那就引入本地消息表把消息记录和订单数据放进同一个本地事务由后台任务负责投递和补偿。这是 TransactionManager 管不到、但真实业务绕不开的边界问题。6. 当单机事务不够用多数据源与分布式事务的边界6.1 多数据源的 TransactionManager 配置实战Spring Boot 多数据源场景最常见的错误是定义了两个 DataSource只写了Primary没有给另一个数据源单独定义 TransactionManager。结果要么是注入PlatformTransactionManager时冲突要么是所有Transactional都默认绑到主数据源上另一个数据源的操作根本没有事务保护。我的配置习惯是每个 DataSource 都配上自己的DataSourceTransactionManager主数据源对应的管理器标注Primary跨数据源的业务方法上用Transactional(otherTxManager)显式指定管理器不要在同一个事务方法里同时操作两个数据源——两个管理器各开各的事务相互之间没有任何协调关系。这里的本质是DataSourceTransactionManagerA 和 B 是完全独立的两套事务。在同一个方法里操作两个数据源看起来像一起成功实际回滚时各管各的数据一致性毫无保障。很多伪跨库问题就是从这里开始的。6.2 真正跨库强一致JTA 与最终一致性方案的选择如果业务真的无法规避跨库强一致订单表和库存表在两个独立数据库那么 JTA XA 是一类选择Seata 这类分布式事务框架是另一类。XA 的强一致来自两阶段提交但代价是 prepare 后的资源长时间锁定高并发和长事务环境下非常不友好。Seata 这类方案引入全局事务协调器和分支事务思想把跨资源问题转换成一个可延迟的协调流程牺牲部分强一致换取可用性。我个人的倾向是现代微服务架构下减少硬性跨库事务。能够把一个业务用例的数据收敛到单一数据库就尽量收敛确实分散的优先考虑本地消息表 对账补偿的最终一致性路线。这条路线不炫技但能被业务代码里的每个人理解和运维故障面也小得多。TransactionManager 在单机事务这一层已经把问题抽象得很好把它强行延伸到分布式场景往往引入的是比原问题更复杂的协调问题而不是解决方案。最后说一点个人体会。TransactionManager 本身不是一个需要读完所有源码才能用得好的组件它的设计处处透露着边界感连接绑定在哪个线程、物理事务由谁发起、谁有资格回滚、回滚标记如何传递。很多时候事务失效并不是 Spring 的 bug而是我们写代码时把调用链和资源边界搞混了。排查事务问题不要急着看日志先冷静回答三个问题当前线程是什么连接从哪个数据源来方法真的走了代理吗这三个问题答清楚八成的问题都已经有了答案。再分享一个小技巧可以在项目里封装一个自定义注解并通过BeanPostProcessor在启动阶段校验标注了事务的方法必须是public且非final。这类检查成本不高但能让团队在开发期就暴露一部分配置问题而不是等到线上数据错乱再去翻日志。我在几个中大型项目里实践过事务类事故率下降非常明显。
