1. 从一次线上数据错乱说起为什么你写的“事务”可能没生效那天下午系统监控突然报警提示核心订单表的库存字段出现了大量负数。我们紧急排查发现是一个批量更新用户积分的定时任务出了问题。代码逻辑看起来很简单先扣减积分再根据积分变动记录日志最后更新用户等级。为了保证一致性我理所当然地给这个方法加上了Transactional注解。但诡异的是日志表里成功插入了记录用户积分也扣了唯独等级没更新——因为更新等级的SQL执行时发生了唯一键冲突抛出了异常。按照我的理解既然抛了异常整个事务就应该回滚积分扣减和日志插入都应该撤销。但现实是积分扣减和日志记录被永久提交了只有最后一步失败了。用户积分凭空消失数据一致性被彻底破坏。这次事故让我彻底明白在Spring Boot里给一个方法加上Transactional远不等于上了保险。这里面有太多隐形的“坑”比如异常的默认回滚规则、事务的传播行为、甚至是数据库连接池的配置都可能让你以为的“原子操作”变成“部分提交”。事务这个在面试中被反复咀嚼的概念在实际开发中远比教科书上的ACID复杂。今天我们就抛开理论直接进入实战把Spring Boot中关于事务的几种核心操作场景——自动回滚、手动回滚、部分回滚——彻底拆解清楚。我会结合我踩过的坑和修复方案让你不仅知道怎么用更明白为什么这么用以及什么情况下会“失灵”。2. 自动回滚的“潜规则”你以为的回滚可能并未发生自动回滚是Spring声明式事务即Transactional注解最吸引人的特性看起来省心省力。但它的生效依赖于一系列严格的默认规则。如果不懂这些规则自动回滚就会变成“自动不滚”。2.1 默认的回滚异常RuntimeException 和 ErrorSpring事务管理器的默认行为是只有在目标方法抛出了未检查异常即RuntimeException及其子类或Error时才会自动触发回滚。而对于检查异常Exception的子类非RuntimeExceptionSpring默认是提交事务的。Service public class OrderService { Transactional public void createOrder(Order order) throws IOException { // 1. 插入订单 (成功) orderMapper.insert(order); // 2. 调用一个会抛出检查异常的方法 someMethodThrowsCheckedException(); // 抛出 IOException // 3. 扣减库存 (永远不会执行到这里) inventoryMapper.deduct(order.getProductId(), order.getQuantity()); } private void someMethodThrowsCheckedException() throws IOException { throw new IOException(文件写入失败); } }在上面的代码中当IOException抛出时事务不会回滚。订单记录已经持久化到数据库但库存没有扣减导致数据不一致。这是新手最常见的坑之一。为什么这么设计这其实是一种妥协。检查异常通常被认为是可预期的业务异常比如“用户名已存在”、“账户余额不足”框架设计者认为开发者应该主动捕获并处理它们而不是一概回滚。而RuntimeException如NullPointerException,IllegalArgumentException通常代表编程错误或不可预料的系统错误理应回滚。修复方案如果你希望特定的检查异常也能触发回滚必须在Transactional注解中显式声明。Transactional(rollbackFor {IOException.class, SQLException.class}) public void createOrder(Order order) throws IOException { // ... 业务逻辑 }反之如果你希望某个RuntimeException不触发回滚虽然很少见可以使用noRollbackFor属性。2.2 事务方法内的“自我消化”异常被捕获则无事发生另一个致命的误区是在事务方法内部捕获了异常却没有重新抛出。Transactional public void updateUser(User user) { try { userMapper.updateById(user); // 模拟一个会失败的操作 int i 1 / 0; // 抛出 ArithmeticException (RuntimeException) } catch (Exception e) { log.error(更新用户出错, e); // 糟糕异常在这里被捕获并处理了没有继续向外抛 // 事务管理器感知不到任何异常事务将会正常提交 } }在这个例子中ArithmeticException确实被抛出了但它被catch块“吞掉”了。从Spring事务管理器的视角看这个方法执行完毕没有异常因此会提交事务。userMapper.updateById(user)的操作就被永久保存了。正确做法如果需要在事务方法内进行异常处理并且发生异常时需要回滚你有两个选择在catch块中重新抛出异常throw e;或抛出一个新的业务异常。编程式设置回滚TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();。这标记了当前事务必须回滚即使方法正常结束。2.3 私有方法与跨类调用注解失效的隐形杀手Transactional注解的本质是Spring AOP面向切面编程。Spring通过代理对象来包裹目标方法在方法调用前后加入事务管理的逻辑。这个机制导致了两类常见的失效场景场景一同类中的私有方法调用Service public class AccountService { public void transfer(Long from, Long to, BigDecimal amount) { deduct(from, amount); // 调用同类私有方法 add(to, amount); } Transactional private void deduct(Long accountId, BigDecimal amount) { accountMapper.deductBalance(accountId, amount); } Transactional private void add(Long accountId, BigDecimal amount) { accountMapper.addBalance(accountId, amount); } }当你调用transfer方法时实际上是在调用AccountService的原始对象而不是Spring生成的代理对象。因此deduct和add方法上的Transactional注解完全不会被代理逻辑处理自然也就没有事务。这两个数据库操作会立即自动提交取决于数据库和连接池的默认设置。场景二同类中的非事务方法调用事务方法Service public class ProductService { public void updateProductPrice(Long productId, BigDecimal price) { // 这是一个非事务方法 doUpdate(productId, price); // 内部调用 } Transactional public void doUpdate(Long productId, BigDecimal price) { // ... 复杂的更新逻辑 } }同理在updateProductPrice中调用doUpdate走的是this.doUpdate()即对象自身的方法调用绕过了代理。Transactional失效。解决方案将事务方法放到另一个Bean中这是最清晰、最推荐的方式。通过调用另一个Bean的方法必然走代理。Service public class ProductService { Autowired private ProductTransactionService transactionService; public void updateProductPrice(Long productId, BigDecimal price) { transactionService.doUpdateInTransaction(productId, price); } } Service public class ProductTransactionService { Transactional public void doUpdateInTransaction(Long productId, BigDecimal price) { // ... } }自我注入在类中注入自己的代理实例然后通过它来调用。Service public class ProductService { Autowired private ProductService self; // 注入代理对象 public void updateProductPrice(Long productId, BigDecimal price) { self.doUpdate(productId, price); // 通过代理调用 } Transactional public void doUpdate(Long productId, BigDecimal price) { // ... } }使用AopContext.currentProxy()不推荐需要开启exposeProxy配置代码侵入性强。3. 手动回滚的精准控制当声明式事务不够灵活时声明式事务Transactional适用于大多数常规场景但它的控制粒度是方法级别的。有时我们需要更精细的控制比如在一个方法内根据不同的业务逻辑分支决定是否回滚或者在捕获异常后进行一些清理操作再决定回滚。这时就需要编程式事务——手动回滚。3.1 使用 TransactionTemplate 进行模板化编程TransactionTemplate是Spring提供的一个模板类它消除了使用底层PlatformTransactionManager的样板代码是手动控制事务最常用的方式。Service public class ManualRollbackService { Autowired private TransactionTemplate transactionTemplate; Autowired private OrderMapper orderMapper; Autowired private InventoryMapper inventoryMapper; public void placeOrderWithManualControl(Order order) { // 执行一个需要事务的代码块 Boolean result transactionTemplate.execute(status - { try { // 1. 插入订单 orderMapper.insert(order); // 2. 检查库存这里可能是一个复杂的业务判断 Inventory inventory inventoryMapper.selectForUpdate(order.getProductId()); if (inventory.getStock() order.getQuantity()) { // 库存不足手动设置回滚并返回一个标志 status.setRollbackOnly(); return false; // 返回执行结果 } // 3. 扣减库存 inventoryMapper.deduct(order.getProductId(), order.getQuantity()); // 4. 记录日志假设这个操作可能失败但我们希望订单和库存操作先提交 // 这里先不执行后续处理 return true; } catch (DataAccessException e) { // 捕获数据库异常手动回滚 status.setRollbackOnly(); throw e; // 可以选择重新抛出或者返回错误结果 } }); if (Boolean.TRUE.equals(result)) { // 事务成功提交后执行一些不需要事务性保证的后置操作 // 例如发送消息、记录非核心日志等 // 即使这里失败也不会影响已提交的订单和库存数据 logService.recordAsync(order); } else { log.warn(订单创建失败库存不足); } } }TransactionTemplate.execute的核心TransactionCallback这是一个函数式接口你的事务代码写在其doInTransaction方法内。参数TransactionStatus可以用来查询事务状态和手动触发回滚setRollbackOnly()。返回值execute方法返回的是回调函数返回的对象。你可以利用它来向外部传递业务执行结果如上面的true/false。异常处理在回调内部抛出的任何未检查异常都会导致事务回滚并传播到外部。你可以捕获异常调用status.setRollbackOnly()后选择是吞掉异常返回特定结果还是重新抛出。为什么用TransactionTemplate而不是直接使用PlatformTransactionManager因为TransactionTemplate帮你处理了事务生命周期的样板代码获取事务、提交、回滚、资源清理。你只需要关注业务逻辑代码更简洁不易出错。3.2 在声明式事务中手动标记回滚有时你已经在使用Transactional但在方法执行过程中遇到了某种业务条件不满足的情况非异常需要强制回滚。这时可以在方法内部直接获取当前事务状态并标记回滚。Service public class HybridTransactionService { Transactional public void complexBusiness(Long id, BigDecimal amount) { // ... 一些前置操作 // 复杂的业务规则校验 if (!someVeryComplexBusinessRule(id, amount)) { // 业务规则不通过需要回滚之前的所有数据库操作 // 但这不是异常是一个正常的业务判断结果 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); // 注意标记回滚后方法可以继续执行其他非数据库操作或者直接返回 log.info(业务规则校验未通过事务已标记回滚。); return; // 方法正常返回但事务最终会回滚 } // ... 后续的数据库操作 // 如果上面标记了回滚这里的操作也会被回滚掉 } }关键点TransactionAspectSupport.currentTransactionStatus()用于获取与当前线程绑定的事务状态。setRollbackOnly()是一个“标记”操作它告诉事务管理器“无论后面发生什么这个事务必须在结束时回滚”。即使方法最终正常退出没有抛出任何异常事务也会回滚。谨慎使用这种方式将回滚逻辑散落在业务代码中降低了代码的可读性。通常更推荐在Transactional注解中配置rollbackFor业务异常然后通过抛出特定业务异常来触发回滚这样逻辑更清晰。4. 部分回滚保存点的复杂场景与陷阱“部分回滚”是一个更高级的需求。它指的是在一个物理事务内部回滚到某个中间点而不是回滚整个事务。这类似于数据库的保存点Savepoint功能。Spring通过TransactionStatus对象提供了对保存点的支持。4.1 保存点的典型使用场景想象一个批量处理的任务你需要处理100条数据每条数据的处理都包含几个独立的步骤。你希望这100条数据的处理在一个大事务里保证最终一致性但其中某一条数据处理失败时只回滚这一条的操作而不是放弃整个批处理任务。Service public class SavepointService { Autowired private JdbcTemplate jdbcTemplate; Transactional public void batchProcess(ListData dataList) { TransactionStatus status TransactionAspectSupport.currentTransactionStatus(); for (int i 0; i dataList.size(); i) { Data data dataList.get(i); // 为当前条目的处理创建一个保存点 Object savepoint status.createSavepoint(); try { // 步骤1验证并更新主表 validateAndUpdateMaster(data); // 步骤2插入明细记录 insertDetail(data); // 步骤3更新统计信息可能失败 updateStatistics(data); // 假设这一步可能失败 } catch (BusinessException e) { // 当前这条数据处理失败回滚到这条数据开始前的状态 status.rollbackToSavepoint(savepoint); log.error(处理第{}条数据失败: {}, 已回滚此条操作, i, data.getId(), e); // 继续处理下一条数据 continue; } finally { // 非常重要释放保存点避免内存泄漏 status.releaseSavepoint(savepoint); } } // 循环结束如果没发生导致全局回滚的异常则提交事务。 // 此时只有那些失败的单条操作被回滚成功的操作都被保留了。 } private void updateStatistics(Data data) { // 模拟一个可能失败的业务操作 if (data.getId() % 7 0) { // 假设ID为7的倍数的数据会失败 throw new BusinessException(统计信息更新冲突); } jdbcTemplate.update(UPDATE stats SET count count 1 WHERE type ?, data.getType()); } }代码解析status.createSavepoint(): 在当前事务内创建一个保存点。这个点之后的数据库操作都可以通过回滚到这个点来撤销。status.rollbackToSavepoint(savepoint): 将事务状态回滚到指定的保存点。这只会撤销该保存点之后的所有数据库修改该保存点之前的修改依然有效。status.releaseSavepoint(savepoint):必须执行。在保存点不再需要后无论是否发生了回滚释放它占用的资源。如果不释放在某些数据库驱动或连接池实现下可能导致内存泄漏。4.2 保存点的重大限制与实战避坑保存点功能强大但限制也非常多稍不注意就会掉进坑里。坑一数据库支持性并非所有数据库都支持保存点也并非所有事务管理器都实现了保存点功能。DataSourceTransactionManager用于单数据源通常支持因为它直接委托给JDBC连接。但JpaTransactionManager或JtaTransactionManager用于分布式事务的支持情况取决于底层实现。在使用前务必确认你的数据库如MySQL的InnoDB引擎支持和事务管理器支持保存点。坑二保存点与连接池的兼容性问题这是最隐蔽的坑。许多数据库连接池如HikariCP默认会启用autoCommit探测和重置。当一个连接被还回连接池时池子可能会执行conn.setAutoCommit(true)来重置连接状态。问题在于在保存点存在的情况下改变autoCommit模式可能会导致保存点失效甚至引发不可预知的错误。解决方案在配置连接池时显式关闭可能干扰保存点的行为。以HikariCP为例# application.yml spring: datasource: hikari: auto-commit: false # 让Spring事务管理器完全控制提交连接池不要动 connection-init-sql: SET autocommit0 # 对于MySQL建立连接后显式设置同时确保你的代码不会在事务中意外地执行任何会改变连接autoCommit状态的操作。坑三保存点不是嵌套事务保存点提供的是“部分回滚”的能力它仍然在同一个物理数据库连接和同一个数据库事务内。这与Spring的PROPAGATION_NESTED传播行为在概念上相似后者在支持保存点的数据库上就是用保存点实现的但它不是一个独立的事务。这意味着保存点内部的代码不能单独提交。保存点内部的代码如果获取了行锁这个锁会一直持有到外层事务结束可能增加死锁风险。如果外层事务最终回滚那么所有操作包括保存点之前的操作都会被回滚。何时使用保存点保存点适用于同一个业务逻辑单元内的细粒度错误恢复。对于跨服务、跨资源的“部分回滚”需求保存点无能为力这需要引入更复杂的分布式事务方案如Seata的AT/TCC模式、基于消息的最终一致性等这完全是另一个维度的话题。5. 事务失效的深度排查从配置到源码当你发现Transactional没有按预期工作时需要一个系统性的排查链路。以下是我总结的从外到内、从配置到代码的排查步骤。5.1 第一步检查基础配置与环境是否启用了事务管理在Spring Boot中只要引入了spring-boot-starter-jdbc或spring-boot-starter-data-jpa事务管理通常是自动配置的。但最好确认主配置类或启动类上有EnableTransactionManagementSpring Boot默认已启用但如果你用了自定义配置可能需要检查。数据源配置是否正确错误的数据库连接URL、用户名密码会导致连接失败事务自然无法启动。检查application.properties/yml。数据库引擎是否支持事务如果你用的是MySQL确认表使用的是InnoDB引擎而不是MyISAM。SHOW CREATE TABLE your_table;连接池配置是否干扰如上文所述检查连接池如HikariCP的auto-commit相关配置。5.2 第二步检查代码层面的常见陷阱按照优先级排查方法修饰符Transactional注解在protected、private方法上无效。Spring默认使用基于代理的AOP而代理无法继承这些方法的访问权限。确保方法为public。自调用问题回顾第2.3节检查是否存在同类调用导致注解失效的情况。异常类型检查抛出的异常是否是RuntimeException或Error。如果不是检查Transactional(rollbackFor...)配置。异常被捕获检查方法内是否用try-catch吞掉了异常。多线程调用事务信息是与当前线程绑定的通过ThreadLocal。如果你在方法内部启用了新线程去执行数据库操作这个新线程不在原有事务上下文中操作将是自动提交的。5.3 第三步利用调试工具与日志定位当以上步骤都无法定位问题时需要更深入的工具。开启Spring事务调试日志logging: level: org.springframework.transaction.interceptor: TRACE org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG观察日志输出可以看到事务何时开启、提交、回滚以及为何回滚。如果根本没看到事务相关的日志说明事务切面没有生效。检查代理对象在调试器中查看自动注入的Service Bean的类名。如果它是YourService$$EnhancerBySpringCGLIB或...$Proxy这样的格式说明它是一个代理对象事务AOP在理论上应该生效。如果它就是YourService本身则代理可能未创建需检查切面配置或Bean的作用域例如原型作用域Scope(prototype)的Bean在某些情况下可能影响AOP。使用TransactionSynchronizationManager在代码中临时添加调试语句打印当前线程的事务状态。import org.springframework.transaction.support.TransactionSynchronizationManager; // ... boolean actualTransactionActive TransactionSynchronizationManager.isActualTransactionActive(); String currentTransactionName TransactionSynchronizationManager.getCurrentTransactionName(); log.debug(当前事务是否活跃: {}, 事务名: {}, actualTransactionActive, currentTransactionName);如果isActualTransactionActive()返回false说明当前代码确实不在一个活跃的事务中。5.4 一个综合排查案例事务传播行为引发的“幽灵提交”我曾经遇到一个诡异的问题在一个标记为Transactional的方法A中调用了另一个Service的methodBmethodB也是Transactional。当methodB抛出异常时methodA的事务并没有回滚。代码片段Service class ServiceA { Autowired private ServiceB serviceB; Transactional public void methodA() { // 操作1 updateTable1(); // 调用B serviceB.methodB(); // 这里抛出了RuntimeException // 操作2 (未执行) updateTable2(); } } Service class ServiceB { Transactional(propagation Propagation.REQUIRES_NEW) // 关键在这里 public void methodB() { updateTable3(); throw new RuntimeException(B失败); } }现象updateTable1()生效了updateTable3()被回滚了但methodA的事务没有回滚updateTable2自然也没执行。这看起来像是“部分回滚”但不是我们想要的。根因分析问题出在Propagation.REQUIRES_NEW。这个传播行为要求创建一个新的事务并挂起当前事务methodA的事务。methodB在新事务中执行它抛出的异常导致了这个新事务回滚。但这个异常传播到methodA时由于methodA的事务在methodB执行时被挂起了methodB的异常并不会导致methodA的事务回滚除非这个异常在methodA中没有被捕获。在这个例子里methodA没有捕获所以methodA的事务也应该回滚等等这里有个关键细节。更深层的真相实际上Propagation.REQUIRES_NEW创建的新事务和原事务是物理上独立的。methodB的事务回滚后异常会抛给methodA。默认情况下methodA的事务管理器会看到这个RuntimeException并标记methodA的事务为回滚。所以理论上updateTable1()也应该被回滚。但为什么我观察到它提交了呢最终发现经过日志追踪发现是项目中的全局异常处理器ControllerAdvice拦截了这个RuntimeException并返回了一个友好的错误信息给前端。全局异常处理器在处理异常后默认情况下异常就被“消化”了不会再向上传播到事务拦截器。因此事务拦截器没有接收到任何异常认为methodA执行成功于是提交了事务解决方案不推荐在全局异常处理器中对于需要回滚的事务性异常重新抛出。推荐在业务设计上仔细考虑事务边界。在这个案例中methodB可能并不需要REQUIRES_NEW。如果改为默认的Propagation.REQUIREDmethodB会加入methodA的事务它的异常就会导致整体回滚这更符合业务预期。或者将methodB中不需要与methodA一起回滚的操作移到事务外部例如在methodA提交后再异步执行。这个案例告诉我们事务的传播行为、异常处理机制与事务回滚机制交织在一起任何一个环节理解不透彻都会导致与预期不符的结果。排查时必须将日志、代码逻辑和Spring事务的底层机制结合起来分析。