SpringBoot 声明式事务与编程式事务

上一篇我们详细讲解了 Transactional 注解的用法、原理和失效场景其实 Transactional 属于「声明式事务」是 SpringBoot 中最常用的事务管理方式。但很多开发者不知道SpringBoot 还支持另一种事务管理方式——「编程式事务」。实际开发中经常有同学纠结什么时候用声明式事务什么时候用编程式事务两者到底有什么区别选错了不仅会增加开发成本还可能导致事务失效、数据不一致等问题。一、什么是声明式事务什么是编程式事务在对比之前我们先明确两种事务的核心定义用通俗的语言拆解不用死记硬背重点理解「使用方式」的差异。1. 声明式事务声明式事务是 SpringBoot 中最主流、最常用的事务管理方式核心是「通过注解或 XML 配置声明事务」无需手动编写事务开启、提交、回滚的代码由 Spring 自动管理事务生命周期。简单来说只需要在方法或类上添加 Transactional 注解Spring 就会自动为该方法添加事务支持开发者只需关注核心业务逻辑无需关心事务的底层实现。核心特点无侵入式、配置简单、代码简洁符合 Spring「约定大于配置」的理念适合 90% 以上的企业级开发场景。✅ 代码示例Service public class OrderService { // 声明式事务一个注解搞定事务管理 Transactional(rollbackFor Exception.class) public void createOrder(OrderDTO orderDTO) { // 核心业务逻辑扣库存、生成订单、扣余额 stockMapper.decreaseStock(orderDTO.getProductId(), orderDTO.getQuantity()); orderMapper.insert(buildOrder(orderDTO)); userMapper.decreaseBalance(orderDTO.getUserId(), orderDTO.getTotalAmount()); } }2. 编程式事务编程式事务是「通过手动编写代码控制事务」开发者需要手动调用 Spring 提供的 API完成事务的开启、提交、回滚操作事务的每一个环节都需要手动控制。简单来说事务的生命周期完全由开发者掌控需要手动写代码开启事务、执行业务逻辑、判断是否提交或回滚侵入业务代码但灵活性极高。核心特点侵入式、配置复杂、代码繁琐但灵活性强适合复杂的事务场景比如多事务嵌套、动态控制事务开关。✅ 代码示例使用 TransactionTemplateService public class OrderService { Autowired private TransactionTemplate transactionTemplate; // 编程式事务手动控制事务的开启、提交、回滚 public void createOrder(OrderDTO orderDTO) { // 手动开启事务执行核心逻辑 transactionTemplate.execute(status - { try { // 核心业务逻辑 stockMapper.decreaseStock(orderDTO.getProductId(), orderDTO.getQuantity()); orderMapper.insert(buildOrder(orderDTO)); userMapper.decreaseBalance(orderDTO.getUserId(), orderDTO.getTotalAmount()); return true; // 执行成功自动提交事务 } catch (Exception e) { status.setRollbackOnly(); // 执行失败手动回滚事务 throw new RuntimeException(e.getMessage()); } }); } }补充说明编程式事务有两种实现方式① 使用 TransactionTemplate推荐简化代码② 使用 PlatformTransactionManager原生 API代码繁琐几乎不用。本篇重点讲解 TransactionTemplate 的用法。二、底层原理对比两种事务管理方式的底层都依赖 Spring 的「事务管理器PlatformTransactionManager」但实现逻辑、触发方式有本质区别这也是两者优缺点、适用场景差异的核心原因。1. 声明式事务原理声明式事务的底层是Spring AOP 动态代理和 Transactional 注解的原理一致核心流程如下1. Spring 容器启动时扫描带有 Transactional 注解的类或方法为其生成动态代理对象JDK 动态代理或 CGLIB 动态代理2. 调用目标方法时实际上调用的是代理对象的方法3. 代理对象在方法执行前通过事务管理器开启事务设置事务属性传播行为、隔离级别等4. 执行目标方法的核心业务逻辑5. 方法正常执行代理对象通过事务管理器提交事务6. 方法抛出异常代理对象通过事务管理器回滚事务根据 rollbackFor 配置判断是否回滚。核心结论声明式事务是「AOP 增强 事务管理器」的结合无需手动干预Spring 自动完成事务生命周期管理。2. 编程式事务原理编程式事务的底层是手动调用事务管理器 API开发者直接通过代码控制事务的每一个环节核心流程如下1. 开发者通过 TransactionTemplate 或 PlatformTransactionManager手动触发事务开启2. 在事务范围内执行核心业务逻辑3. 手动判断业务逻辑执行结果成功则提交事务失败则手动触发回滚4. 事务执行完成后手动释放资源Spring 会自动处理但开发者可手动控制。核心结论编程式事务是「手动调用 API 事务管理器」的结合事务的每一个环节都由开发者掌控不依赖 AOP 动态代理因此不会出现 AOP 代理相关的失效问题。三、全方位对比这是本篇文章的核心内容我们从「使用方式、代码侵入性、灵活性、配置复杂度、事务控制粒度、失效风险、性能、适用场景」8个核心维度对两种事务做全面对比用表格呈现清晰易懂方便选型和记忆。对比维度声明式事务Transactional编程式事务TransactionTemplate使用方式通过 Transactional 注解或 XML 配置声明无需手动写事务代码通过 TransactionTemplate 手动编写代码控制事务开启、提交、回滚代码侵入性无侵入式仅添加注解不修改业务代码侵入式事务代码与业务代码耦合在一起灵活性较低事务属性传播行为、隔离级别等固定配置无法动态调整极高可动态控制事务开关、提交/回滚时机支持复杂的事务逻辑如多事务嵌套配置复杂度极低单数据源无需额外配置多数据源只需指定事务管理器较高需要注入 TransactionTemplate手动编写事务执行逻辑代码繁琐事务控制粒度较粗只能控制类或方法级别无法控制方法内的某一段代码极细可控制方法内的任意一段代码比如某几行代码需要事务其他代码不需要失效风险较高容易出现 AOP 代理相关的失效问题如 private 方法、同类内部调用、未配置 rollbackFor 等极低不依赖 AOP 代理手动控制事务只要代码编写正确几乎不会失效性能稍低依赖 AOP 动态代理有轻微的性能损耗可忽略不影响业务稍高无 AOP 代理损耗手动控制事务性能略优于声明式事务适用场景大部分常规场景单事务、简单业务逻辑如下单、支付、新增数据追求代码简洁、开发高效复杂事务场景多事务嵌套、动态控制事务、方法内局部代码需要事务、对事务粒度要求极高的场景重点提醒不要盲目追求编程式事务的「高性能」和「高灵活性」大部分场景下声明式事务的性能损耗可以忽略且开发效率更高、代码更简洁只有在声明式事务无法满足需求时才考虑使用编程式事务。四、两种事务的完整用法结合「下单场景」分别用声明式事务和编程式事务实现对比两种方式的代码差异方便大家在项目中直接复用。1. 环境准备单数据源导入依赖SpringBoot 2.x配置 application.yml 数据源此处省略和上一篇事务实战的环境完全一致可直接复用。2. 声明式事务实战需求下单操作扣库存、生成订单、扣余额三个操作必须在同一个事务中任意一个失败全部回滚日志记录用独立事务即使主事务回滚日志也要保存。Service Slf4j public class OrderService { Autowired private OrderMapper orderMapper; Autowired private StockMapper stockMapper; Autowired private UserMapper userMapper; Autowired private OrderLogService orderLogService; // 声明式事务主事务默认传播行为 REQUIRED Transactional(rollbackFor Exception.class, timeout 5) public void createOrder(OrderDTO orderDTO) { try { // 1. 扣减库存 int stockRows stockMapper.decreaseStock(orderDTO.getProductId(), orderDTO.getQuantity()); if (stockRows 0) { throw new BusinessException(库存不足); } // 2. 生成订单 Order order buildOrder(orderDTO); orderMapper.insert(order); // 3. 扣减余额 int userRows userMapper.decreaseBalance(orderDTO.getUserId(), orderDTO.getTotalAmount()); if (userRows 0) { throw new BusinessException(用户余额不足); } // 4. 记录日志独立事务 orderLogService.recordOrderLog(order.getOrderNo(), 下单成功); } catch (Exception e) { log.error(下单失败{}, e.getMessage(), e); throw new RuntimeException(e.getMessage()); } } // 构建订单对象辅助方法 private Order buildOrder(OrderDTO orderDTO) { Order order new Order(); order.setUserId(orderDTO.getUserId()); order.setProductId(orderDTO.getProductId()); order.setQuantity(orderDTO.getQuantity()); order.setOrderNo(UUID.randomUUID().toString().replace(-, )); order.setCreateTime(new Date()); return order; } } // 日志 Service独立事务声明式 Service public class OrderLogService { Autowired private OrderLogMapper orderLogMapper; Transactional(rollbackFor Exception.class, propagation Propagation.REQUIRES_NEW) public void recordOrderLog(String orderNo, String content) { OrderLog log new OrderLog(); log.setOrderNo(orderNo); log.setContent(content); log.setCreateTime(new Date()); orderLogMapper.insert(log); } }✅ 特点代码简洁仅通过注解控制事务无需关注事务的底层实现开发效率高。3. 编程式事务需求下单操作分两步① 扣库存、生成订单必须在事务中② 扣减余额可选事务根据用户配置动态决定是否开启事务。这个场景用声明式事务无法实现无法动态控制事务开关必须用编程式事务Service Slf4j public class OrderService { Autowired private OrderMapper orderMapper; Autowired private StockMapper stockMapper; Autowired private UserMapper userMapper; Autowired private TransactionTemplate transactionTemplate; // 编程式事务动态控制事务开关 public void createOrder(OrderDTO orderDTO, boolean needBalanceTransaction) { // 第一步扣库存、生成订单必须在事务中 Order order transactionTemplate.execute(status - { try { // 扣减库存 int stockRows stockMapper.decreaseStock(orderDTO.getProductId(), orderDTO.getQuantity()); if (stockRows 0) { status.setRollbackOnly(); // 手动回滚 throw new BusinessException(库存不足); } // 生成订单 Order newOrder buildOrder(orderDTO); orderMapper.insert(newOrder); return newOrder; // 事务提交返回订单对象 } catch (Exception e) { status.setRollbackOnly(); log.error(扣库存、生成订单失败{}, e.getMessage()); throw new RuntimeException(e.getMessage()); } }); // 第二步扣减余额动态控制是否开启事务 if (needBalanceTransaction) { // 开启事务扣减余额 transactionTemplate.execute(status - { try { int userRows userMapper.decreaseBalance(orderDTO.getUserId(), orderDTO.getTotalAmount()); if (userRows 0) { status.setRollbackOnly(); throw new BusinessException(用户余额不足); } return true; } catch (Exception e) { status.setRollbackOnly(); log.error(扣减余额失败{}, e.getMessage()); throw new RuntimeException(e.getMessage()); } }); } else { // 不开启事务直接扣减余额非事务操作 userMapper.decreaseBalance(orderDTO.getUserId(), orderDTO.getTotalAmount()); } } private Order buildOrder(OrderDTO orderDTO) { // 同声明式事务的辅助方法省略 Order order new Order(); order.setUserId(orderDTO.getUserId()); order.setProductId(orderDTO.getProductId()); order.setQuantity(orderDTO.getQuantity()); order.setOrderNo(UUID.randomUUID().toString().replace(-, )); order.setCreateTime(new Date()); return order; } }✅ 特点灵活性极高可根据参数needBalanceTransaction动态控制是否开启事务还能分步骤控制事务范围这是声明式事务无法实现的。五、注意事项1. 声明式事务上一篇我们详细讲解了声明式事务的8种失效场景这里重点回顾3个最常见的• 不要在 private、protected 方法上使用 Transactional无法被 AOP 代理事务失效• 同类内部调用时不要用 this.方法()调用的是目标对象不是代理对象事务失效• 务必配置 rollbackFor Exception.class避免 checked 异常不回滚。2. 编程式事务• 不要忘记手动设置 rollbackOnly业务逻辑失败时必须调用 status.setRollbackOnly()否则事务会自动提交• 避免事务嵌套时的资源泄露Spring 的 TransactionTemplate 会自动释放资源但手动使用 PlatformTransactionManager 时需手动释放• 不要过度使用编程式事务简单场景用编程式事务会增加代码复杂度降低开发效率。八、文末小结声明式事务和编程式事务没有绝对的优劣之分核心是「适配业务场景」1. 声明式事务简单、高效、无侵入是日常开发的首选适合大部分常规业务2. 编程式事务灵活、可控、低失效风险适合复杂事务场景是声明式事务的补充。核心选型原则「能⽤声明式就不用编程式」只有在声明式事务无法满足需求时再考虑编程式事务。同时无论使用哪种事务都要牢记避坑点确保事务生效保证数据一致性。如果你在项目中遇到事务选型或事务失效的问题或者有其他疑问欢迎在评论区留言交流一起避坑、一起进步别忘了点赞在看收藏三连关注我解锁更多 SpringBoot 实战干货下期再见❤️