Spring事务传播机制7大类型详解

一、核心概念理解

首先要明确：事务传播机制（Propagation）解决的是当一个事务方法被另一个事务方法调用时，这个方法的事务该如何与调用方的事务进行交互的问题。

简单来说，就是定义了 “新事务” 和 “旧事务” 之间的关系规则，Spring 把这些规则封装成了Propagation枚举类，所有传播行为都基于这个枚举定义。

二、Spring 事务传播机制的 7 种类型

Spring 提供了 7 种核心的事务传播行为，我会按 “常用程度 + 易理解性” 排序讲解，每个类型都包含含义和代码示例：

1. REQUIRED（默认值）：必要的

• 含义：如果当前存在事务，就加入这个事务；如果当前没有事务，就新建一个事务。这是最常用的传播机制。
• 场景：绝大多数业务场景（如下单扣库存、支付扣余额）都用这个，保证操作在同一个事务里。
• 代码示例：

import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; @Service public class OrderService { // 调用方方法 @Transactional(propagation = Propagation.REQUIRED) public void createOrder() { // 1. 保存订单 saveOrder(); // 2. 调用库存服务扣减库存（被调用方） stockService.deductStock(); } @Service public class StockService { // 被调用方方法 @Transactional(propagation = Propagation.REQUIRED) public void deductStock() { // 扣减库存逻辑 } } }

• 执行逻辑：
  • 调用createOrder()时，没有现有事务，会新建一个事务；
  • 执行deductStock()时，发现已有事务，就加入这个事务；
  • 两个方法的操作要么都成功提交，要么都回滚。

2. SUPPORTS：支持的

• 含义：如果当前存在事务，就加入这个事务；如果当前没有事务，就以非事务方式执行。
• 场景：查询类方法（如查询订单详情），有事务时就跟着事务走，没有也不强制创建。

@Transactional(propagation = Propagation.SUPPORTS) public OrderVO getOrderDetail(Long orderId) { // 查询订单逻辑，无修改操作 return orderMapper.selectById(orderId); }

3. MANDATORY：强制的

• 含义：必须在现有事务中执行，如果当前没有事务，直接抛出IllegalTransactionStateException异常。
• 场景：必须依赖外层事务的核心修改操作（如订单状态更新，必须在下单 / 支付的事务中执行）。

@Transactional(propagation = Propagation.MANDATORY) public void updateOrderStatus(Long orderId, Integer status) { orderMapper.updateStatus(orderId, status); } // 如果直接调用这个方法（无外层事务），会抛异常；只有被其他事务方法调用才会执行。

4. REQUIRES_NEW：新建的

• 含义：无论当前是否有事务，都新建一个独立的事务；如果原有事务存在，会先暂停原有事务，新事务执行完后再恢复原有事务。
• 场景：日志记录、消息发送等 “不希望被主事务回滚影响” 的操作。

@Service public class OrderService { @Transactional(propagation = Propagation.REQUIRED) public void createOrder() { saveOrder(); // 主事务操作 logService.recordLog(); // 调用新建事务的方法 int i = 1 / 0; // 制造异常，主事务回滚 } } @Service public class LogService { @Transactional(propagation = Propagation.REQUIRES_NEW) public void recordLog() { // 记录订单创建日志 logMapper.insert(new Log("创建订单", LocalDateTime.now())); } }

• 执行逻辑：
  • recordLog()会新建独立事务，执行完就提交；
  • 即使createOrder()后续抛异常回滚，日志记录也不会回滚（因为是独立事务）。

5. NOT_SUPPORTED：不支持的

• 含义：以非事务方式执行；如果当前有事务，会先暂停原有事务，执行完后再恢复原有事务。
• 场景：耗时较长的非核心操作（如导出报表），避免占用事务资源导致事务超时。

6. NEVER：从不

• 含义：必须以非事务方式执行；如果当前存在事务，直接抛出IllegalTransactionStateException异常。
• 场景：完全不允许在事务中执行的操作（如纯查询且对性能要求极高的统计操作）。

@Transactional(propagation = Propagation.NEVER) public Long countAllOrders() { return orderMapper.count(); } // 如果被事务方法调用，会抛异常；只有直接调用（无事务）才会执行。

7. NESTED：嵌套的

• 含义：如果当前有事务，就在这个事务里创建一个嵌套事务（子事务）；如果没有，就新建一个事务。
• 核心特点：
  • 嵌套事务依赖外层事务，外层事务回滚时，嵌套事务也会回滚；
  • 但嵌套事务可以独立回滚（不影响外层事务），这是和REQUIRED的核心区别；
  • 底层依赖数据库的保存点（Savepoint）功能，所以需要数据库支持（如 MySQL InnoDB）。

@Service public class OrderService { @Transactional(propagation = Propagation.REQUIRED) public void createOrder() { saveOrder(); // 外层事务操作 try { stockService.deductStock(); // 嵌套事务 } catch (Exception e) { // 嵌套事务回滚，外层事务继续执行 log.error("扣减库存失败", e); } // 外层事务最终提交，saveOrder() 会生效，deductStock() 已回滚 } } @Service public class StockService { @Transactional(propagation = Propagation.NESTED) public void deductStock() { // 扣减库存逻辑，若失败则回滚自身，不影响外层 int i = 1 / 0; // 制造异常 } }

三、关键对比（易混淆类型）

总结

1. 核心作用：事务传播机制定义了 “方法间调用时事务的交互规则”，解决多事务方法嵌套调用的事务边界问题。
2. 常用类型：REQUIRED（默认，共用事务）、REQUIRES_NEW（独立事务）、SUPPORTS（查询用）是日常开发中最常使用的三种。
3. 关键注意：NESTED依赖数据库保存点，而REQUIRES_NEW是完全独立的事务，二者不要混淆；传播机制仅在Spring 管理的事务方法间调用时生效（如非 public 方法、内部调用会失效）。