Spring 的事务传播机制有哪些？

2026年02月03日

面试考察点

面试官提出这个问题，绝不仅仅是希望你能背出那七种传播行为的名字。其深层次的考察意图通常包括：

基础概念掌握：你是否能准确说出 Spring 定义的七种事务传播行为及其含义。
场景理解与应用能力：这通常是核心考察点。面试官想知道你能否根据不同的业务场景（如方法嵌套调用），选择最合适的传播行为。例如，何时该让方法加入已有事务，何时必须开启一个全新独立的事务。
对事务本质和 Spring 抽象的理解：你是否理解传播机制是为了解决“业务方法相互调用时，事务如何定义和传递”这一核心问题，以及 Spring 是如何通过 ThreadLocal、AOP 和事务管理器来抽象并实现这一机制的。
实际开发经验与避坑意识：你是否在实际项目中因为错误配置传播行为导致过数据不一致、事务失效或性能问题？能否指出常见的使用误区和最佳实践。

核心答案

Spring 的事务传播机制定义了当一个事务方法被另一个事务方法调用时，事务应该如何进行。它提供了 7 种不同的行为，定义在 Propagation 枚举中。最常用的是 REQUIRED、REQUIRES_NEW 和 NESTED。

REQUIRED：默认值。如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式继续运行。
MANDATORY：强制性。如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
REQUIRES_NEW：无论如何都会创建一个新的事务。如果当前存在事务，则挂起当前事务。
NOT_SUPPORTED：以非事务方式运行。如果当前存在事务，则挂起当前事务。
NEVER：以非事务方式运行。如果当前存在事务，则抛出异常。
NESTED：嵌套事务。如果当前存在事务，则在当前事务内创建一个嵌套事务（保存点）来执行；如果当前没有事务，其行为与 REQUIRED 类似。

深度解析

原理/机制

传播机制的核心在于，Spring 需要决定被调用方法执行时，是应该 “加入（Join）” 调用者的事务上下文，还是应该 “新建（New）” 一个独立的事务上下文，或是完全 “脱离（Suspend）” 事务环境。

Spring 通过 TransactionInterceptor 拦截带有 @Transactional 注解的方法。当方法被调用时，事务管理器会根据 @Transactional(propagation = ...) 的配置，结合当前线程绑定的 TransactionStatus（事务状态），来决定创建新的事务资源（如数据库连接）还是复用已有的。

对比分析与场景实战

我们来深入剖析最核心、最易混淆的三种传播行为。

REQUIRED (默认且最常用)
- 场景：适用于绝大多数业务逻辑。例如，用户下单服务调用扣库存服务和创建订单服务，我们希望这三个操作在同一个事务中，要么全成功，要么全失败。
- 特点：形成一个大事务。任何一点失败都会导致全部回滚。
REQUIRES_NEW (关键区分点)
- 场景：子操作必须独立提交或回滚，不受父事务影响。经典场景是操作日志记录：无论主业务逻辑是否成功提交，日志都必须被持久化。
- 与 REQUIRED 的对比： | 特性 | REQUIRED | REQUIRES_NEW | | :----------- | :----------------------------------- | :--------------------------------------------------------- | | 事务关系 | 加入，同一事务 | 全新，独立事务 | | 回滚影响 | 子方法异常，整个事务（含父方法）回滚 | 子方法异常，仅自身回滚，不影响父事务（除非父方法捕获异常） | | 提交顺序 | 一起提交 | 子事务先提交，父事务后提交 | | 连接资源 | 通常共享同一数据库连接 | 使用新的数据库连接（可能增加连接池压力） |
- 代码示例：
```
@Service
public class OrderService {
    @Transactional(propagation = Propagation.REQUIRED)
    public void placeOrder(Order order) {
        // 1. 核心业务：扣减库存，创建订单
        inventoryService.deduct(order);
        orderDao.create(order);

        // 2. 记录日志：无论成败都需要记录，应独立事务
        try {
            logService.saveOperationLog("ORDER_CREATED", order.getId());
        } catch (Exception e) {
            // 捕获日志异常，避免影响主业务提交
            logger.error("记录操作日志失败，订单ID: " + order.getId(), e);
        }
    }
}

@Service
public class LogService {
    @Transactional(propagation = Propagation.REQUIRES_NEW) // 关键在此！
    public void saveOperationLog(String type, Long orderId) {
        // 插入日志记录...
    }
}
```
NESTED (易误解且依赖数据库)
- 场景：希望实现 “部分回滚”。例如，一个批量处理任务，其中某条记录处理失败，只回滚该条记录的操作，而不影响其他已处理的记录和主事务状态。
- 原理：基于数据库的 Savepoint（保存点）机制实现。它不是一个完全独立的事务，而是外部事务的一个“嵌套”子集。
- 与 REQUIRES_NEW 的关键区别：
  - NESTED 是外部事务的子事务，回滚时只回滚到保存点，外部事务可以继续。其提交依赖于外部事务。
  - REQUIRES_NEW 是完全独立、平级的事务，与外部事务无关。
- 注意：并非所有数据库都支持保存点，使用前需确认。

最佳实践与常见误区

最佳实践：
1. 首选 REQUIRED：除非有明确理由，否则使用默认的 REQUIRED，它能满足大部分需求且简单高效。
2. 慎用 REQUIRES_NEW：它会创建新连接，可能导致数据库连接池压力增大。务必确认业务上是否需要“绝对独立提交”。
3. 了解 NESTED 的支持情况：在使用 NESTED 前，确认你的数据库和 JDBC 驱动是否支持。
4. 避免在循环中调用 REQUIRES_NEW：极易导致连接耗尽。考虑批量处理或调整设计。
5. 注意自调用失效问题：在同一个类中，A 方法（非事务）调用 B 方法（@Transactional），由于 Spring AOP 基于代理的特性，B 方法的事务注解会失效。这是另一个高频考点。
常见误区：
1. 认为 NESTED 是万能解药：实际上，很多公司项目因为数据库或 MyBatis 等兼容性问题，很少使用 NESTED，更倾向于用编程式事务或 REQUIRES_NEW 配合补偿机制来实现类似功能。
2. 滥用 REQUIRES_NEW：在不必要时使用，不仅增加开销，还可能破坏数据一致性预期。例如，在核心链路上使用，可能导致部分成功部分失败的非原子状态。

总结

Spring 的事务传播机制，其本质是定义业务方法在相互调用时事务上下文的边界和规则。理解并正确使用 REQUIRED、REQUIRES_NEW 和 NESTED 是解决复杂业务中数据一致性问题、设计鲁棒性系统的关键技能之一。记住，没有最好的，只有最适合当前场景的。

发布于2026年02月03日|12:45:44