当前位置：首页 > news >正文

spring传播机制事务相关

news 2026/3/26 18:41:48

spring传播机制事务相关

一、`REQUIRED` 核心规则（一句话记住）

有则加入，无则新建

完整严谨描述：

当一个被 @Transactional 标记的目标方法执行时，先检查当前执行环境是否已经存在事务；
如果当前已有事务 → 该方法不会新建事务，而是加入到这个已存在的事务中，成为「同一个事务」的一部分；
如果当前没有事务 → 该方法就自己新建一个全新的独立事务来执行。

二、准备基础测试代码（通用）

为了让示例直观，我们定义一个业务 Service，包含 2 个带事务的「子方法」，模拟数据库的增删改操作（事务只对增删改生效，查询无意义），所有方法抛出的是RuntimeException（Spring 事务默认只对运行时异常回滚，贴合实际开发）。

1. 核心业务 Service

java

运行

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;@Service
public class OrderService {// 事务方法1：模拟【创建订单】操作，带默认事务(REQUIRED)@Transactional // 等价于 @Transactional(propagation = Propagation.REQUIRED)public void createOrder() {System.out.println("执行逻辑：向数据库插入【订单】数据");// 这里可以写真实的 mapper.insert(订单对象)}// 事务方法2：模拟【扣减库存】操作，带默认事务(REQUIRED)@Transactionalpublic void deductStock() {System.out.println("执行逻辑：修改数据库的【商品库存】数据");// 这里可以写真实的 mapper.update(库存对象)// 手动抛出运行时异常，模拟业务执行失败throw new RuntimeException("扣减库存失败！库存不足");}
}

2. 补充说明

两个方法都加了@Transactional，都是默认的REQUIRED传播机制；
deductStock() 方法中手动抛出异常，用于模拟「业务执行失败」的场景，验证事务的回滚规则；
真实开发中，这里就是调用 Mapper/DAO 层操作数据库，效果完全一致。

三、场景一：外层方法【无事务】，调用内层事务方法 ✅ 无则新建

这是 REQUIRED 规则的第一种情况：当前执行环境无事务 → 内层方法各自新建独立事务。

1. 新增「无事务的外层方法」

在上面的OrderService中新增一个不加任何事务注解的方法，用来调用两个事务子方法：

java

运行

// 无事务的外层方法：没有@Transactional注解
public void doBizWithoutTx() {// 调用第一个事务方法this.createOrder();// 调用第二个事务方法（会抛异常）this.deductStock();
}

2. 执行结果 + 事务分析

调用 doBizWithoutTx() 方法后，最终执行结果：
✅ 数据库中，订单数据插入成功，库存数据无修改（扣减库存回滚）

核心分析（重中之重）：

外层方法doBizWithoutTx() 无事务，执行时「当前无事务环境」；
调用createOrder()时 → 无事务，触发REQUIRED → 新建独立事务 A，执行完订单插入后，事务 A 正常提交；
调用deductStock()时 → 无事务，触发REQUIRED → 新建独立事务 B，执行库存扣减后抛出异常，事务 B 触发回滚；
结论：两个事务方法各自是独立的事务，互不影响！一个成功提交，一个失败回滚。

四、场景二：外层方法【有事务】，调用内层事务方法 ✅ 有则加入（重点 + 高频）

这是 REQUIRED 规则的第二种情况，也是实际开发中最常用的场景：当前执行环境有事务 → 内层方法加入外层事务，成为同一个事务。

1. 新增「有事务的外层方法」

在OrderService中新增一个加了 @Transactional的外层方法，同样调用两个事务子方法：

java

运行

// 有事务的外层方法：自己带默认事务(REQUIRED)
@Transactional
public void doBizWithTx() {// 调用第一个事务方法this.createOrder();// 调用第二个事务方法（会抛异常）this.deductStock();
}

2. 执行结果 + 事务分析

调用 doBizWithTx() 方法后，最终执行结果：

✅ 数据库中，订单数据无插入、库存数据无修改，两个操作全部回滚！

核心分析（必须吃透）：

外层方法doBizWithTx() 加了@Transactional，执行时先新建了一个「主事务 T」；
调用createOrder()时 → 当前已有事务 T，触发REQUIRED → 不新建事务，直接加入主事务 T，订单插入逻辑成为事务 T 的一部分；
调用deductStock()时 → 当前已有事务 T，触发REQUIRED → 不新建事务，直接加入主事务 T，库存扣减逻辑也成为事务 T 的一部分；
deductStock()抛出异常 → 整个「主事务 T」触发回滚，事务内的所有操作都会回滚（包括之前执行的 createOrder 的订单插入）；
结论：外层有事务时，所有内层的 REQUIRED 事务方法，都会合并成一个事务，要么全部成功，要么全部失败回滚！

五、补充 2 个关键知识点（面试 / 开发高频）

✅ 知识点 1：同一个事务的核心特性

当多个方法「加入到同一个事务」时，它们共享同一个事务的所有属性：

事务的隔离级别、超时时间、只读属性等，都和外层主事务一致；
事务的提交 / 回滚是全局的：只有所有方法都执行成功，事务才会最终提交；只要有任意一个方法抛出异常触发回滚，整个事务全部回滚。

✅ 知识点 2：REQUIRED 是 Spring 的默认选择，为什么？

Spring 把REQUIRED作为默认传播机制，是因为它完美贴合 99% 的业务场景：
实际开发中，我们的业务逻辑都是「组合操作」（比如：下单 = 创建订单 + 扣减库存 + 扣减余额），这些操作必须是原子性的（要么都成，要么都败），否则会出现「数据不一致」的脏数据（比如：订单创建成功，但库存没扣减，商品超卖）。

REQUIRED的机制刚好满足这个需求，这也是它成为默认值的核心原因。