Spring事务管理从原理到实战：@Transactional失效场景与排查指南

Spring的事务管理说句实话是我这些年面试Java开发必问的一块也是日常代码里踩坑最密集的区域之一。很多同事一上来就甩一个Transactional在方法上然后该提交提交、该报错报错看着挺正常可一旦遇到自调用、异常被吞、传播行为选错这类场景线上数据就悄悄出问题。这篇文章我就从实际项目经验出发把Spring事务管理从核心原理到实操细节、再到问题排查一次性讲透适合刚接触Spring Boot的初学者也适合那些“注解用了一年但没想过为什么”的开发同学。1. 先搞明白Spring事务管理到底在管什么1.1 从数据库事务说起Spring在哪个层面做文章事务不是什么Spring发明的概念它本质上是数据库层面的能力。一组SQL要么全部成功提交要么全部失败回滚保证数据不会停留在中间状态。经典的ACID四个特性——原子性、一致性、隔离性、持久性都是数据库引擎提供的。那Spring事务管理到底在管理什么简单说Spring做的事情是把“开启事务”、“提交事务”、“回滚事务”这三件事从繁琐的JDBC代码里抽象出来用一套统一API封装好。你不再需要手动connection.setAutoCommit(false)、connection.commit()、connection.rollback()而是声明一下“这个方法需要事务”Spring就在方法执行前开启事务、方法正常结束后提交、方法抛异常后回滚。我之前带过一个新人他以为事务是Spring“做”出来的所以遇到问题总往Spring配置上想。其实绝大多数情况下事务的底层还是数据库在撑着Spring只是那个“发号施令”的调度员。理解这一点对后面排查“事务为什么不回滚”特别重要——如果一个异常在进到Spring的代理逻辑之前就被吞掉了那Spring根本不知道要回滚数据自然就留下了一半。1.2 三个核心接口事务运转的骨架Spring事务抽象的核心就三个接口把这几个看明白了整个事务框架的脉络就清晰了。第一个是PlatformTransactionManager这是事务管理的门面。它定义了三个方法getTransaction获取或创建事务commit提交rollback回滚。Spring下面所有的事务行为最终都通过这个接口落地。第二个是TransactionDefinition它定义了一次事务的“规则参数”包括传播行为、隔离级别、超时时间、是否只读。第三个是TransactionStatus它代表一次事务运行时的状态可以理解成数据库连接的包装状态Spring通过它来判断当前事务能不能提交、有没有被标记为rollback-only。这三个接口的关系可以类比成一次网购TransactionDefinition是订单规则多久发货、能不能退换TransactionStatus是运单状态包裹走到哪了PlatformTransactionManager是快递公司调度中心负责按规则把运单状态推进到签收提交或者退回回滚。1.3 事务管理器该选哪个实现Spring的事务管理器有很多实现最常见的是DataSourceTransactionManager它基于java.sql.Connection实现事务控制适配一切通过DataSource获取连接的场景MyBatis、JdbcTemplate用的都是它。如果你用了Spring Data JPA默认会走JpaTransactionManager它把EntityManager的事务纳入Spring管理。还有JtaTransactionManager这个一般用在真·分布式事务场景比如应用跨了多个数据库或者多个资源需要JTA规范来协调日常业务开发很少用到而且引入它往往会带来不少复杂度和性能损耗。Spring Boot的自动配置帮我们把大部分选择做掉了——引入spring-boot-starter-jdbc或mybatis-spring-boot-starter后会自动装配一个DataSourceTransactionManager。你基本不需要手动声明除非有多数据源或者特殊定制需求。2. 声明式事务 Transactional 的真相与失效场景2.1 注解背后的AOP代理机制Transactional之所以能用“声明”的方式管理事务靠的是Spring AOP。Spring在启动时会扫描被Transactional标记的Bean为其生成代理对象。当外部调用这个Bean的方法时实际上调用的是代理对象的方法代理对象在方法执行前开启事务方法返回后提交抛出未被捕获的异常时回滚。这个机制有一个很关键的推论只有通过代理对象调用方法事务才会被拦截。如果你在类的内部用this.xxx()调用另一个加了Transactional的方法那调用的是原始对象的方法代理逻辑完全没有介入事务自然不生效。这是所有事务失效问题里出现频率最高的一种我后面专门用一节来讲怎么判断和解决。另外Spring Boot 2.x之后默认使用CGLIB代理也就是基于子类生成的代理不再强制要求目标类实现接口。这比早期JDK动态代理要省心一些但还是绕不开“调用必须经过代理”这条铁律。2.2 传播行为7种选择但日常就这几种Transactional的propagation属性控制事务的传播行为默认值是Propagation.REQUIRED。这个默认值的含义是当前有事务就直接加入没有就新建一个。大多数业务场景用默认值就够了。REQUIRES_NEW也常用它的作用是挂起当前事务新建一个独立事务。比如你在一个业务方法里要记录操作日志日志入库失败不应该回滚主业务那就应该把日志方法标记为REQUIRES_NEW。但要注意被挂起的事务并没有提交它要等新事务结束、自己恢复后继续执行所以日志记录这个“独立事务”提交了而主事务还在跑这时候外面查日志能查到但主业务数据还没提交。NESTED则是嵌套事务基于数据库的Savepoint实现。它的特点是内部事务回滚时可以只回滚到保存点不影响外部事务之前的操作但如果外部事务最终回滚内部事务的修改也会一并回滚。这个语义和REQUIRED不同REQUIRED是“加入同一个事务”内部异常一旦触发回滚会标记整个事务为rollback-only外部事务往往也会跟着挂掉。如果你需要部分回滚NESTED比REQUIRED更可控。剩下几个——SUPPORTS、NOT_SUPPORTED、MANDATORY、NEVER日常业务用的频率低。SUPPORTS是有事务就加入没有就以非事务方式运行MANDATORY要求当前必须有事务否则直接异常NEVER反过来不允许有事务。这些更多用于框架级代码业务开发知道存在即可。2.3 事务失效那些我以为加了注解就万事大吉的时刻我梳理一下过去几年在生产环境里真实遇到过的Transactional失效场景每一个都是血泪教训。私有方法加Transactional不生效。CGLIB代理是通过子类重写方法来增强的私有方法无法被子类访问天然不能被代理。同理static方法也不行final方法也不行因为CGLIB无法重写final方法。所以事务方法必须是非private、非static、非final的public方法。异常被try-catch捕获后不抛出不回滚。这是最常见的问题。Spring事务回滚的触发条件是“事务方法抛出未被捕获的异常”如果你在方法内部把异常捕获了没再抛出去代理对象看到的是方法正常返回自然就提交了。有些同学说“用户余额扣减了但订单没生成事务没回滚”查到最后往往是这种问题。默认只对RuntimeException和Error回滚检查时异常checked exception默认不触发回滚。因为Spring的设计哲学是受检异常代表业务可预见的失败不一定需要回滚。如果你希望自定义异常也触发回滚要显式声明Transactional(rollbackFor Exception.class)。调用方和被调用方在同一个类内部走了this调用而不是代理调用。这个场景我会在排查章节专门演示。多线程环境下新线程里的事务和主线程事务无关。Transactional基于ThreadLocal传播子线程拿不到父线程的事务上下文。这些失效场景归根结底都能用一句话概括Spring事务是AOP代理驱动的任何绕开代理、绕开异常抛出路径的操作都会让事务形同虚设。3. 一套能直接落地的实操配置与编码3.1 Spring Boot下的基础配置在Spring Boot项目里事务管理几乎是零配置。引入依赖、配置好数据源框架就能自动装配事务管理器。我这里给一份规范的示例spring: datasource: url: jdbc:mysql://localhost:3306/demo?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver业务代码里事务方法写在Service层Service public class OrderService { Transactional(rollbackFor Exception.class) public void createOrder(OrderCreateDTO dto) { orderMapper.insert(dto.toOrder()); inventoryMapper.deduct(dto.getSkuId(), dto.getQuantity()); accountMapper.deductBalance(dto.getUserId(), dto.getAmount()); } }rollbackFor Exception.class是我在所有业务代码里的默认选择。虽然Spring默认只回滚运行时异常但我个人在业务团队里更倾向于“所有异常都回滚”这个保守策略宁可多回滚也不能让数据落成半拉子状态。如果你没有用Spring Boot而是在普通Spring项目中需要手动配置Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { DataSourceTransactionManager manager new DataSourceTransactionManager(); manager.setDataSource(dataSource); return manager; }同时还要在配置类上开启EnableTransactionManagement。Spring Boot里这个开关由自动配置处理不用你操心。3.2 编程式事务TransactionTemplate兜底声明式事务再方便也有不可控的时候。比如你要在一个方法里动态决定是否开启事务或者事务边界根据业务条件动态变化这时候Transactional这种“先声明后执行”的方式就不太灵活了。我的习惯是用TransactionTemplate做编程式事务兜底。Service public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(TransactionTemplate transactionTemplate) { this.transactionTemplate transactionTemplate; } public void createOrder(OrderCreateDTO dto) { boolean needInventory dto.getQuantity() 0; transactionTemplate.execute(status - { try { orderMapper.insert(dto.toOrder()); if (needInventory) { inventoryMapper.deduct(dto.getSkuId(), dto.getQuantity()); } accountMapper.deductBalance(dto.getUserId(), dto.getAmount()); return null; } catch (Exception e) { status.setRollbackOnly(); throw e; } }); } }TransactionTemplate的底层是PlatformTransactionManager它同样遵循“抛出异常即回滚”的原则只是把事务边界从注解挪到了代码块里。它的优势在于条件控制更灵活而且同一个方法里可以出现多个独立的事务块——这在声明式事务里几乎做不到。不过我要提醒一句能用Transactional的地方还是优先用注解。因为编程式事务容易在业务代码里堆出大量模板代码可读性会下降。TransactionTemplate更适合那些“注解说不清边界”的特殊场景。3.3 多数据源事务别硬刚分布式很多项目做到后面会引入多数据源比如订单库和用户库分开。这时候你如果在两个数据源的操作上分别加Transactional它们各自管理各自的事务合起来并不是一个原子操作。业务第一步往订单库插入数据成功第二步往用户库扣减余额失败订单库的数据已经提交了不会因为用户库的事务回滚而撤销。这就是跨数据源事务难题。面对这个问题我建议按下面这个优先级来权衡如果业务允许最终一致比如订单创建后通过消息队列异步扣减库存那优先使用本地消息表或消息队列保证最终一致性不要硬用一个事务去包两个库。如果两个库的操作必须强一致账务类业务尤其如此那要上真正的分布式事务方案比如Seata的AT模式。但分布式事务会带来明显的一致性和性能代价要谨慎评估。还有一个务实的小技巧在一个主数据源上执行事务另一个数据源的操作放在事务提交后的TransactionSynchronizationManager.registerSynchronization回调里执行。这样主数据源失败时副操作不会发生主数据源提交后再触发副操作是一个轻量的补偿思路。它不能做到绝对强一致但能把不一致窗口缩得很小。4. 大事务、性能与边界控制4.1 事务里最怕的三件事事务不是越大越安全恰恰相反事务范围太大往往是性能问题的主要源头。我总结了三类在事务内做会拖垮性能的操作。第一是远程调用。事务方法里调第三方API、调另一个服务的HTTP接口、调用RPC都是大忌。事务持有数据库连接远程调用期间连接一直占着不放。一次远程调用最快几十毫秒慢则几秒连接池就这么被耗尽了。我之前接手过一个系统高峰期经常报连接池超时排查发现是一个Transactional方法里同步调了短信平台的接口短信平台偶尔响应两三秒数据库连接池就被拖垮了。第二是消息发送。往MQ里发消息虽然比HTTP快但同样是在事务里做额外IO操作。更麻烦的是如果消息发送成功了但后面SQL执行失败回滚消费者已经拿到了这个消息会处理一个实际上并未生效的业务操作。正确姿势是事务提交后再发送消息可以用TransactionSynchronizationManager.registerSynchronization的afterCommit回调。第三是批量大循环。比如在事务里for循环几千上万条数据逐条update每条SQL一次网络往返整体时间呈线性增长。把大循环拆成批次批量执行或者干脆把大事务拆成多个小事务性能会好很多。4.2 缩小事务边界的两个常用姿势第一个姿势是把非事务操作移到事务方法外面。比如一个方法既要做参数校验、组装数据又要做数据库更新那你应该让只有更新那一段走事务方法校验和组装放在事务外。实现方式可以是拆Service方法也可以借助TransactionTemplate精确控制事务范围。第二个姿势是异步化。允许异步的操作不要放在事务里比如通知推送、日志上报可以用Async方法异步执行或者投递到消息队列。这样主链路的事务方法只保留必要的数据库操作事务周期大幅缩短。还有一个小经验SQL本身也要优化。事务时间的长短除了业务操作数量之外单条SQL的执行效率同样关键。缺少索引导致的慢查询会让本可以几十毫秒完成的事务拖到几百毫秒并发一上来就会形成连接积压。给高频查询条件建好索引往往比调整事务边界收益更快。4.3 只读事务不是摆设Transactional(readOnly true)看起来只是告诉Spring“这个方法不修改数据”实际上它在底层做了两件事一是给数据库一个只读提示某些数据库或者连接池会据此做优化比如MySQL的InnoDB在只读事务里可以走只读副本二是Spring本身也会做一些优化减少不必要的写入检查。不过要泼一盆冷水readOnly true并不能真正阻止代码里执行insert/update语句它更多是一个“声明”和“优化提示”。如果你抱着“加了这个属性误操作就不会落库”的幻想那是会翻车的。数据安全还是要靠代码审核和数据库权限控制。我的习惯是查询列表、查询详情等纯读接口一律加readOnly true一方面语义清晰另一方面在数据库连接层面给DBA一个优化依据。但这属于锦上添花不是雪中送炭。5. 事务问题排查手册从现象到根因5.1 事务没生效先看代理场景Service里两个方法createOrder调用了updateStock两个方法都加了Transactional但是updateStock里的异常没有让事务回滚。这种问题十有八九是自调用。代码大概长这样Service public class OrderService { public void createOrder(OrderCreateDTO dto) { // 一系列订单操作 this.updateStock(dto.getSkuId(), dto.getQuantity()); } Transactional(rollbackFor Exception.class) public void updateStock(Long skuId, Integer quantity) { inventoryMapper.deduct(skuId, quantity); throw new RuntimeException(库存不足); } }createOrder没有加Transactional但它内部调用this.updateStock()时走的是当前对象的直接调用不是代理对象所以updateStock上的事务注解根本没有机会被解析。解决方案有两种。最简单的把updateStock拆到另一个Service类中让createOrder通过注入的Bean调用。这样调用链路上会经过代理事务就能生效。另一种方案在OrderService里注入自身代理比如用Lazy注入OrderService再通过self.updateStock()调用。两种都行我更推荐拆类因为职责更清晰。5.2 异常没回滚多半是异常“跑了”场景事务方法里明明抛了异常但数据还是提交了。排查步骤我一般这么走第一步看异常是在哪一层被处理的。如果是在Controller层或者调用方catch掉了事务方法本身已经正常返回Spring认为方法执行成功自然提交。第二步看抛出的异常类型。如果是自定义的受检异常比如BizException extends Exception默认是不会触发回滚的。这时候要检查有没有配rollbackFor Exception.class。第三步看事务方法内部有没有“脏”的try-catch把异常吞掉。我见过最暧昧的写法是这样Transactional(rollbackFor Exception.class) public void createOrder(OrderCreateDTO dto) { try { orderMapper.insert(dto.toOrder()); inventoryMapper.deduct(dto.getSkuId(), dto.getQuantity()); } catch (Exception e) { log.error(创建订单失败, e); // 没有重新抛出 } }这代码日志里红通通一片但数据库那边该提交还是提交了。所谓“事务没回滚”其实是异常被拦截了Spring根本没有感知到。解决方式就是catch之后重新抛出或者直接不catch让异常自然向上传播。5.3 连接池被打满事务持有连接时间太长场景系统某个时间段内频繁出现Connection is not available, request timed out应用没有挂但请求大面积超时。这种问题的排查思路不是看Spring配置而是看谁长时间持有连接。常见元凶就是事务方法里做了慢操作比如同步远程调用、大批量遍历、慢SQL。定位手段有两个。第一打开连接池的监控Druid或者HikariCP都有现成的监控指标可以看到活跃连接数、等待获取连接的线程数。第二看线程堆栈jstack导出线程栈找那些处于WAITING状态、正在获取数据库连接的线程再看它们在哪里阻塞。我之前解决过一次类似问题最终定位到是一个事务方法里循环调用了远程库存接口平均每个订单耗时1.2秒。把远程调用移到事务外、改成事务提交后异步处理系统立刻恢复。这类问题往往不是事务配置错了而是事务边界划得太大。还有一个容易被忽略的场景事务方法里做了Thread.sleep或者等待锁。比如事务里加了ReentrantLock另一个线程持有锁不释放当前线程一直阻塞数据库连接被这个线程占着不放池子很快就被拖垮。事务方法内尽量不要做任何和数据库无关的耗时操作。结尾说点我的私人体会我在实际项目里见过太多次“加了Transactional就以为万事大吉”导致的线上事故归根结底是对Spring事务的AOP代理机制和回滚触发条件理解不够透。如果你能把本文里讲到的几个失效场景牢牢记在心里——自调用不走代理、受检异常默认不回滚、异常被吞不抛、事务里做远程调用——那我相信你在事务这条路上能少走很多弯路。最后再分享一个小技巧写事务相关代码的时候可以在本地起一个测试故意让事务方法抛异常然后去数据库确认数据有没有被回滚。用这种“破坏性验证”的方式一次就能确认你的事务配置到底生没生效。这个方法我每次带新人都会让他们试一遍比看十篇原理文章都管用。