1. 别再只看表面Transactional 失效背后的真实原因做了几年 Java 开发用 Transactional 注解管理事务可能是最稀松平常的事。但我见过太多项目里因事务失效引发线上数据不一致的“事故现场”——库存扣了、订单没生成账户扣款成功、余额表没变化。排查到最后问题往往不在数据库也不在 SQL而是 Transactional 压根没生效。我刚带团队时也踩过类似的坑。某个定时任务批量处理对账文件方法上加了 Transactional 注解测试环境数据量小一点问题没有。上线后某个批次处理到一半抛了运行时异常结果发现前一半已经入库的数据没有回滚彻底把库存数据搞花了。排查后才发现是同类内部方法调用代理根本没有拦截。这个注解到底怎么工作的失效场景有哪些传播机制、隔离级别、连接管理又该怎么选这篇文章不打算停留在“注解真方便”的层面直接把 Spring 事务从代理原理到实战配置拆一遍把那些常规文档不会写的细节讲透。先特别强调一句Spring 的声明式事务基于 AOP 动态代理实现所有“失效”问题几乎都能从代理机制上找到根源。Transactional 是 Spring 框架提供的一套声明式事务解决方案核心价值在于将事务开启、提交、回滚这些繁琐操作交给容器去管理开发者只需在方法或类上标注一个注解。但它的“自动”是有前提的背后隐藏着代理对象、事务同步管理器、连接绑定等一堆细节。搞懂这些细节才算真正会用这个注解而不是被它坑。2. 手写一个代理示例弄清方法调用为什么“穿透”代理2.1 Spring 事务的本质AOP 动态代理外加一个事务拦截器要理解 Transactional 失效原因先得从底层机制说起。我们平时写的业务 Bean经过 Spring 容器初始化后并不是直接返回那个原始对象而是返回一个经过 AOP 增强的代理对象。Spring 默认使用 JDK 动态代理也可以配置使用 CGLIB具体要看目标类是否实现了接口。代理对象跟原始对象有相同的接口或继承关系但内部包裹了事务拦截器逻辑。每次调用被 Transactional 标注的方法时实际调用链条是“调用方 - 代理对象 - 事务拦截器 - 原始对象方法”。事务拦截器会做这些事从配置中解析事务属性传播行为、隔离级别、超时时间、只读标志从 Spring 容器中获取 PlatformTransactionManager 事务管理器通过事务管理器开启事务、获取数据库连接把连接绑定到当前线程的 ThreadLocal 中执行原始对象的目标方法根据方法执行是否抛异常决定提交或回滚清理事务上下文把连接归还连接池这个“代理”的存在意味着目标方法被执行前和后Spring 都插入了额外逻辑。核心问题在于代理拦截的前提是调用要经过代理对象。如果调用没有经过代理而是直接调用了原始对象的方法事务拦截器根本没有机会介入注解自然失效。2.2 自己动手模拟代理链路的执行顺序为了说清这个问题我用简化代码模拟一下代理拦截的过程。虽然 Spring 的 TransactionInterceptor 肯定复杂得多但整体链路就是这么回事。public class TransactionInterceptor { // 模拟代理拦截逻辑 public Object invoke(MethodInvocation invocation) throws Throwable { // 1. 事务开启前获取事务管理器开启事务绑定连接 TransactionStatus status transactionManager.getTransaction(transactionAttribute); try { // 2. 执行目标方法 Object result invocation.proceed(); // 3. 方法正常返回提交事务 transactionManager.commit(status); return result; } catch (Exception e) { // 4. 方法抛异常按规则回滚事务 transactionManager.rollback(status); throw e; } finally { // 5. 清理事务同步状态 TransactionSynchronizationManager.clear(); } } }从这段链路就能看出几个关键点。目标方法正常结束才能提交抛了异常才回滚方法执行期间事务相关信息通过 ThreadLocal 与当前线程绑定。所以事务要不要回滚完全取决于你能不能“感知”到异常。感知不到异常Spring 就只能傻乎乎地提交。再进一步说如果调用方拿到的是原始对象而不是代理对象那这段拦截逻辑根本不会执行事务相当于不存在。这种情况最常见的触发点就是同类内部方法调用。Component public class OrderService { public void createOrder() { // 这里直接调用内部方法this 是原始对象不是代理对象 this.insertOrder(); this.insertOrderItem(); } Transactional public void insertOrder() { // 事务方法 } Transactional public void insertOrderItem() { // 事务方法 } }createOrder 方法内部this.insertOrder() 和 this.insertOrderItem() 调用的是 OrderService 原始对象的方法代理对象根本没有介入事务自然无效。如果 insertOrder 执行成功、insertOrderItem 执行失败前者不会回滚最终造成数据不一致。这个例子描述的问题实在太常见网上面试题也是高频考点。但真正落实到项目里很多人写的代码就是这个形态然后深夜查数据为啥不对。2.3 为什么 InvocationTargetException 会干扰你的问题判断排查事务问题时很多人被 InvocationTargetException 绕晕。这个异常是反射调用目标方法时的包装异常目标方法本身抛出的异常被包在它的 target 属性里。代理对象调用目标方法也是通过反射完成的所以事务方法内部抛出的异常经过反射层会被包装。Spring 处理回滚时会层层解包来解析具体异常类型判断是否匹配回滚规则。如果你自己用反射调用了事务方法你的 catch 逻辑没解包直接对比 InvocationTargetException 的类型肯定对不上预期异常事务回滚判断也可能出错。实际排查事务问题时第一步应该去看目标方法是否被代理而不是盯着异常栈一层层猜。最简单的方式是打印调用对象类型。// 容器中注入的类型是代理类 System.out.println(orderService.getClass().getName()); // 输出中会出现 CGLIB 或 JDK 代理相关字样 // 类似 OrderService$$EnhancerBySpringCGLIB如果在容器里这个类的名字带了 EnhancerByCGLIB说明走代理链路没问题如果就是普通类名那一定在配置层面出了岔子比如没有开启注解驱动事务。3. 失效场景全排查同类的坑、异常吞掉、非 public 方法3.1 同类自调用、私有方法、非事务方法互相调用事务方法被同类内部其他方法调用时事务失效这是压倒性的第一大坑。我整理一下这类问题的几种具体形式以及各自的解决思路。场景一同类内部 this 调用。如上面代码所示this.method() 调用绕过代理。解决办法有几个将事务方法拆分到独立的 Service Bean通过注入代理对象调用注入自身代理Component public class OrderService { Autowired private OrderService self; public void createOrder() { // 调用代理自身的 insertOrder事务能生效 self.insertOrder(); } Transactional public void insertOrder() { ... } }使用 AopContext.currentProxy() 获取当前代理对象public void createOrder() { OrderService proxy (OrderService) AopContext.currentProxy(); proxy.insertOrder(); }使用 AopContext.currentProxy() 需要在配置里设置 exposeProxy true否则运行时会直接抛 IllegalStateException。场景二方法不是 public。Spring 的注解驱动事务默认只对 public 方法生效private、protected、默认包可见方法上的 Transactional 都会失效。原因很简单Spring 的代理逻辑只对 public 方法进行拦截其他可见性方法要么被子类覆盖逻辑干扰要么根本不被代理链调用。项目里把这个坑踩穿的人不少特别是内部私有方法想“顺便”加个事务结果事务全程没参与。场景三在非事务方法里直接调用另一个类的事务方法但那个非事务方法也属于同一个 Bean而且标注事务的方法自己又调了内部方法。这个组合拳容易和“传播行为”叠加产生复杂效果需要先从结构上理清楚调用链。一般建议事务边界放在入口方法上而不是撒在多个内部方法上。你可以在一个方法上统一管理事务内部方法就不要再标注事务以免传播行为互相干扰。3.2 异常被 catch 吞掉事务提交了你以为回滚了这是事务失效的第二大场景。代码长这样Transactional public void transfer() { try { accountMapper.reduceBalance(fromId); // 这里抛了业务异常 throw new RuntimeException(余额不足); } catch (Exception e) { // 异常被吞掉方法正常返回 log.info(转账失败: {}, e.getMessage()); } }方法体内部把异常 catch 了没有重新抛出方法正常返回。Spring 事务拦截器看到方法正常返回认为一切成功就把事务提交了。结果是余额已经扣减但调用方根本不知道出了问题。这在真实项目中非常隐蔽因为日志里看起来有报错你以为事务回滚了实际数据库已经改动。排查手段也很反直觉要看日志打印顺序如果事务提交日志没打印那可能是异常没有被拦截器感知。正确做法有两种。要么在 catch 块中手工标记回滚Transactional public void transfer() { try { accountMapper.reduceBalance(fromId); throw new RuntimeException(余额不足); } catch (Exception e) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); log.info(转账失败: {}, e.getMessage()); // 这里可以继续做其他操作事务最终还是会回滚 } }要么就不要 catch让异常传到事务拦截器层面由 Spring 统一处理回滚。大多数情况下第二种更简洁。如果需要 catch 做一些日志记录可以 catch 之后再原样抛出或者使用自定义异常封装后抛出。吞异常是最不可取的。3.3 非异常导致回滚失效的其他隐蔽案例还有一个常见问题是 SQL 执行成功但没匹配到任何行。比如更新语句 set 的条件生效了但对列表为空导致影响行数为 0方法本身没有任何异常。此时事务虽然参与但没产生实际变化这不算事务失效只算业务逻辑问题。要判断事务是否真的提交了应该看数据库锁和日志而不是代码。另一种隐蔽问题是多线程。Spring 事务是通过 ThreadLocal 把数据库连接绑定到当前线程的。如果你在事务方法内启动了新线程去执行数据库操作那个新线程拿不到事务上下文绑定的连接也就无法参与当前事务。如果子线程里操作的是另一个数据源更是各走各的。这种场景在异步任务、消息处理中很常见正确的做法是把事务边界移到子线程要执行的方法上或者使用编程式事务确保子线程有自己的事务上下文。还有一点值得记录动态代理生效范围和方法可见性绑定。如果方法标注了 Transactional 但不是 publicSpring 不会直接报错而是静默忽略这很讨厌。建议团队 Code Review 时多加注意或者引入架构守护工具扫描非 public 方法上的 Transactional。4. 传播行为不是随便选的REQUIRED 与 REQUIRES_NEW 实战差异4.1 七种传播行为的概念与关键选择场景Spring 定义了七种事务传播行为默认是 REQUIRED。我用一张表把最常用的几种整理出来重点关注它们的事务关系和行为效果。传播行为当前存在事务时当前无事务时典型场景REQUIRED加入当前事务新建事务同一事务内多个操作默认选它REQUIRES_NEW挂起当前事务新建事务新建事务日志记录、审计、消息发送必须独立提交NESTED嵌套事务保存点回滚新建事务某一段逻辑失败不影响主事务整体回滚SUPPORTS加入当前事务非事务方式执行查询操作有事务就参与没有也行NOT_SUPPORTED挂起当前事务非事务执行非事务方式执行某些特殊操作不希望占用事务连接MANDATORY加入当前事务抛异常强制要求必须在一个事务中执行NEVER抛异常非事务方式执行严格禁止事务实际团队里用得最多的就是前三个。如果不理解 REQUIRES_NEW 和 REQUIRED 的区别可能会出现这样的场景用户下订单时往订单流水表插一条记录结果订单主流程回滚了流水也跟着回滚审计日志全没了。4.2 REQUIRES_NEW 是“停掉一个事务开另一个事务”不是嵌套REQUIRES_NEW 的行为是外层事务被挂起内层方法开启一个全新事务内外两个事务彼此隔离。内层事务提交后即使外层事务最终回滚内层事务已经提交的数据不会被回滚。这个特征特别适合某些“无论如何都要记录”的场景比如消息发送、审计日志、操作记录。但注意一点REQUIRES_NEW 是需要额外数据库连接资源的。事务挂起期间外层连接被持有但处于闲置状态内层再获取一个新连接高并发下连接池容易出现空闲等待。连接池如果很小这种方法容易成为瓶颈。如果确实想实现“部分成功、部分失败不影响主流程”可以选择 NESTED 结合保存点机制。NESTED 不会挂起外层事务而是使用数据库 savepoint 特性在内层方法出错时回滚到保存点。主事务依然持有连接连接资源消耗比 REQUIRES_NEW 小但 MySQL 等数据库支持嵌套事务的能力要看具体驱动配置。我在项目中通常优先使用 REQUIRES_NEW 处理日志类独立提交需求用 NESTED 处理复杂的批量业务分段回滚需求。4.3 自调用与传播行为的组合陷阱一个案例拆到底下面这个案例我去年在某项目排查了整晚正好把“自调用 传播行为”组合起来说明。Service public class OrderService { Autowired private OrderMapper orderMapper; public void createOrderWithLog() { // 同类调用事务不会在这里统一 this.saveOrder(); this.saveOrderLog(); } Transactional(propagation Propagation.REQUIRED) public void saveOrder() { orderMapper.insertOrder(...); } Transactional(propagation Propagation.REQUIRES_NEW) public void saveOrderLog() { orderMapper.insertOrderLog(...); } }执行 createOrderWithLog 时this.saveOrder() 和 this.saveOrderLog() 都是直接调用内部对象方法两个方法上的 Transactional 全部失效saveOrderLog 的 REQUIRES_NEW 根本不会新建独立事务。表面上看着是两个独立事务实际是零事务因为它们都没走代理。排查这类问题最典型的线索就是执行失败时数据库数据已经写入了。因为异常被同类内部调用“截断”代理层没有任何拦截。正确的结构应当是Service public class OrderService { Autowired private OrderService self; Autowired private OrderLogService orderLogService; public void createOrderWithLog() { // 通过代理调用自身主方法事务生效 self.saveOrder(); // 通过独立 Bean 调用REQUIRES_NEW 生效 orderLogService.saveOrderLog(); } }把 saveOrderLog 拆到 OrderLogService 中并且用 OrderLogService 的代理对象去调用REQUIRES_NEW 才会真正意义上开启新事务。自调用加传播行为的组合是最容易让经验丰富的开发者都掉坑的地方。5. 隔离级别、只读事务与连接绑定一次说清配置误区5.1 隔离级别不是越高越好关键是匹配业务场景Spring 事务注解通过 isolation 属性指定隔离级别默认使用数据库默认隔离级别MySQL 为 REPEATABLE_READ。很多新手一上来直接设置 SERIALIZABLE觉得“最高级最安全”但代价是性能和并发能力断崖式下降。各隔离级别解决的核心问题不同应对的选择应该是从业务需求出发READ_UNCOMMITTED能读到未提交数据脏读风险大几乎不会用在生产环境READ_COMMITTED解决脏读但不可重复读问题仍然存在适用对一致性要求不极致的查询类场景REPEATABLE_READ解决脏读和不可重复读MySQL 默认配合 MVCC 提供快照读SERIALIZABLE完全串行化写并发能力极差只用于极少数对数据一致性要求极端、写并发低的场景实际开发中如果两个并发事务要同时操作同一行库存数据用 READ_COMMITTED 加数据库悲观锁select ... for update通常比 REPEATABLE_READ 更可控。REPEATABLE_READ 在 MySQL 里通过快照读实现两个事务各自读到自己的快照反而可能让并发更新改为最后提交覆盖结果带来脏写风险。我见过有人把隔离级别升到 SERIALIZABLE 来解决并发扣库存问题结果压测直接打满数据库连接业务超时一大片这不是事务注解的锅是对隔离级别理解有偏差。5.2 readOnly true 到底做了什么别被名字误导readOnly 属性设置成 true 时Spring 会做两件事向数据库提示这是只读事务有些数据库会以此做优化但 MySQL 的 InnoDB 引擎并不会因此跳过加锁有些场景下Spring 会关闭某些持久层框架的脏检查、flush 机制提升一点性能但要注意readOnly true 并不能阻止你在事务方法里执行 insert、update、delete。它只是建议性提示不是硬性校验。Spring 默认并不会拦截写操作。如果你的项目里想通过 readOnly 做强制校验那是完全错误的用法。我平时会把 readOnly 用在以下两类方法上查询单条或多条数据的 Service 方法大批量只读统计方法配合超时时间控制写操作的方法一律不设 readOnly避免和事务拦截器的行为产生模糊地带。如果你的方法只读但内部还调了查询后写入 Redis 这类操作也最好别标 readOnly因为 Redis 操作不走数据库事务但 Spring 的只读提示没有太大意义。稳妥起见只对纯数据库查询才设置。5.3 事务超时时间和连接绑定ThreadLocal 的另一个细节事务超时时间timeout单位是秒默认 -1 表示不超时。如果设置超时一旦事务执行超过阈值Spring 会尝试回滚事务但具体行为取决于数据库驱动和底层连接状态并不保证一定会回滚。这里很容易出现“超时了但锁没释放”的棘手问题。数据库事务是通过连接绑定的连接又是从连接池借来的。Spring 把连接保存到 TransactionSynchronizationManager 的 ThreadLocal 中。每个线程里的操作都使用同一个线程绑定的连接确保整个事务操作的是同一个连接而不是从连接池里每次拿新连接。这就是事务一致性的基础。如果方法内部直接使用 new Thread() 或线程池去执行数据库操作子线程里的数据库访问不在同一个 ThreadLocal 上下文里自然不会继承父线程的事务连接。这种场景下的操作要么各自独立提交要么直接抛错。有些团队因为一个异步任务在事务里更新了两张表子线程更新另一张表最后数据乱套就是这个原因。6. 什么时候必须放弃声明式事务改用编程式事务6.1 声明式事务的灵活性边界Transactional 是“开箱即用”的代表但有个天然缺点方法粒度控制。事务边界是从方法进入开始方法结束提交或回滚。遇到下面这些场景声明式事务反而不好用同一个方法里想在不同阶段设置不同的回滚条件某一段逻辑失败单独回滚另一段逻辑失败也单独回滚但两者之间还有业务依赖需要动态决定事务是否开启、是否参与当前事务需要在一个循环里为多次操作各自开启独立事务需要精细控制事务的挂起与恢复这时编程式事务更香。Spring 提供了 TransactionTemplate直接手动控制事务的提交和回滚。6.2 TransactionTemplate 的正确打开方式TransactionTemplate 的使用非常简单但有的人会用成了“把声明式注解搬进了代码”Autowired private TransactionTemplate transactionTemplate; public void batchProcess(ListLong ids) { for (Long id : ids) { transactionTemplate.execute(status - { try { // 每一条数据一个事务某条失败不影响整体 mapper.update(id); return Boolean.TRUE; } catch (Exception e) { // 手动回滚当前事务 status.setRollbackOnly(); log.error(处理失败: {}, id, e); return Boolean.FALSE; } }); } }这个模式适合批处理任务。如果每个数据项的处理都希望独立提交无论后续数据项成功失败都不会相互影响这种结构非常稳定。注意 execute 方法返回后的状态当回调抛出异常时TransactionTemplate 会自动回滚当回调正常返回且没有调用 setRollbackOnly它会自动提交。所以 catch 块里一定要把业务异常往外抛或设置 rollbackOnly否则只 catch 不处理照样可能提交。另一种复杂场景手动开启事务、执行操作、根据条件决定提交或回滚Autowired private PlatformTransactionManager transactionManager; public void complexBiz() { DefaultTransactionDefinition definition new DefaultTransactionDefinition(); definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); definition.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); TransactionStatus status transactionManager.getTransaction(definition); try { // 业务操作1 // 业务操作2 boolean needRollback checkSomething(); if (needRollback) { transactionManager.rollback(status); return; } transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); throw e; } }这种写法适合在同一个方法里实现多段事务控制声明式注解做不到这么细腻。但它有个需要注意的地方代码里 commit 和 rollback 必须保证成功执行如果不小心写漏了事务会一直挂着连接无法释放。使用 TransactionTemplate 可以自动管理比手写 PlatformTransactionManager 的 commit/rollback 更安全。6.3 事务方法里调用远程接口的“长期锁”问题声明式事务一个隐蔽的大坑事务方法里调用了远程接口或 RPC但远程接口耗时很长事务一直没提交数据库连接一直占着。如果再涉及锁其他事务只能干等。我处理过的一个问题订单支付回调方法里Transactional 方法中调用了第三方 HTTP 接口原意是想在第三方确认后更新订单状态。结果第三方接口超时 10 秒整个事务就挂了 10 秒。高峰期并发一上来数据库连接直接被占满业务崩溃还把问题定位到“连接池大小不够”上误导了排查方向。正确做法是事务方法里尽量不调用远程接口把远程调用放到事务外面。先拿数据、再调远程、再开事务去更新或者反过来先更新本地事务再调远程失败后人工介入。远程调用参与事务只能增加锁等待时间和不可控性。如果一定要在事务内调远程也请把超时时间设置得短一些并评估连接池容量是否能扛住并发等待。7. 最终自查清单快速定位不生效或者回滚异常这里贡献一份我实际用过的排障清单按顺序检查大多数问题五分钟之内能定位。确认 Spring 配置里启用了 EnableTransactionManagement或 XML 的 tx:annotation-driven。没有开启注解驱动任何 Transactional 都不会生效。确认事务管理器是否配置正确数据源是否对得上。多数据源场景下不同数据源需要对应不同的事务管理器。确认目标方法是被代理调用的不是内部 this 调用。打印类名或判断增强逻辑。确认方法是 public 可见性否则 Spring 不会拦截。确认异常没有被 catch 吞掉且异常类型匹配回滚规则。默认只有 RuntimeException 和 Error 触发回滚checked exception 需要显式指定 rollbackFor。确认传播行为设置符合预期不会因为 REQUIRES_NEW 或 NESTED 改变事务边界。确认方法内部没有新开线程访问数据库或者确认子线程操作确实应该独立事务。确认没有配置 readOnlytrue 的方法执行了写操作且期望回滚以及是否出现锁等待。还有一条很实用的经验在方法入口和出口打印事务状态信息用TransactionSynchronizationManager.isActualTransactionActive()判断当前是否存在真实事务比用日志猜要容易得多。boolean txActive TransactionSynchronizationManager.isActualTransactionActive(); System.out.println(当前是否存在真实事务: txActive);这篇文章基于我实际踩坑后的总结把 Spring Transactional 的完整链路梳理了一遍。我个人特别想再强调一遍注解本身并不复杂复杂的是代理链路、异常传播和事务资源绑定这几条隐线。理解这几条隐线遇到多少事务问题都不会慌。如果之后还有时间我会再整理一篇基于 Spring Boot 3 多数据源的项目里不同事务管理器如何协同、如何通过事务同步事件做事务后的回调处理。