spring事务传播分析

作为Java开发者，面试中Spring事务传播机制绝对是高频考点！今天我们就来掰开揉碎讲讲这个技术点，让你在面试中游刃有余。需要2025年Java面试宝典的同学，可以戳这里下载： 🔗 https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g 提取码: 9b3g

什么是Spring事务传播行为？

简单说，它定义了当一个事务方法被另一个事务方法调用时，事务该如何进行。这是Spring框架管理复杂业务逻辑下数据一致性的核心策略。理解好Spring事务传播机制，是搞定分布式事务、避免脏读幻读的关键！

常见的7种传播行为详解

Spring定义了7种传播行为，我们一个个来看它们在Spring事务传播中的表现：

面试鸭返利网

REQUIRED（默认）

场景：方法A（无事务）调方法B（REQUIRED）
行为：B会自己开一个新事务。Spring事务传播在这里表现为“没有就新建”。
场景：方法A（有事务）调方法B（REQUIRED）
行为：B直接加入A的事务，大家同生共死。这是最常见的Spring事务传播策略。

SUPPORTS

场景：方法A（无事务）调方法B（SUPPORTS）
行为：B就以非事务方式执行，没事务环境嘛。Spring事务传播特点是“随大流”。
场景：方法A（有事务）调方法B（SUPPORTS）
行为：B加入A的事务。适合查询操作，有无事务都能跑。

MANDATORY

场景：方法A（无事务）调方法B（MANDATORY）
行为：直接抛异常！Spring事务传播要求“必须有现成事务”，不然不干活。
场景：方法A（有事务）调方法B（MANDATORY）
行为：B乖乖加入A的事务。

REQUIRES_NEW

场景：方法A（有事务）调方法B（REQUIRES_NEW）
行为：不管A有没有事务，B都一定会启动一个全新的事务。A的事务会被挂起，等B的事务完了再继续。
关键点：B的事务和A的事务完全独立，互不影响。B提交/回滚，A的事务不受牵连。这个Spring事务传播行为常用于需要强隔离性的场景，比如记录日志（即使主业务失败，日志也得记下来）。

NOT_SUPPORTED

场景：方法A（有事务）调方法B（NOT_SUPPORTED）
行为：A的事务会被挂起，B以非事务方式执行。执行完B，A的事务再恢复。
用途：明确要求某个方法不参与事务，比如执行某些非核心的、不怕脏读的操作。Spring事务传播在这里是“强行暂停事务”。

NEVER

场景：方法A（有事务）调方法B（NEVER）
行为：直接抛异常！Spring事务传播策略明确禁止在事务内调用它。
场景：方法A（无事务）调方法B（NEVER）
行为：B以非事务方式执行。

NESTED（基于Savepoint）

场景：方法A（有事务）调方法B（NESTED）
行为：B不会启全新事务，而是在A的事务里创建一个嵌套的子事务（Savepoint）。如果B失败回滚，只会回滚到Savepoint，A的事务可以选择继续或回滚；如果A回滚，B肯定跟着回滚。
关键点：B是A的一部分，B能独立回滚不影响A，但A回滚会连带B。需要JDBC 3.0+驱动和DataSourceTransactionManager支持。这个Spring事务传播行为适合主从业务关联较强的场景（比如订单和订单项）。

面试鸭返利网

面试官最爱问：REQUIRES_NEW vs NESTED

REQUIRES_NEW：两个物理独立事务，完全隔离。B失败不影响A，A失败也不影响B（如果B已提交）。资源占用多（两个独立事务），隔离性强。
NESTED：是同一个物理事务下的逻辑嵌套。B失败，A可以决定后续；A失败，B必然失败。资源占用少（一个事务+Savepoint），业务关联紧密时用起来更合适。这是理解Spring事务传播精妙之处的好例子。

如何在实际中配置Spring事务传播

通常我们用@Transactional注解：

@Service
public class OrderService {

    @Transactional(propagation = Propagation.REQUIRED) // 默认就是REQUIRED
    public void placeOrder(Order order) {
        // ... 核心下单逻辑
        logService.saveOpLog(order); // 调用日志服务
    }
}

@Service
public class LogService {

    @Transactional(propagation = Propagation.REQUIRES_NEW) // 总是新启事务
    public void saveOpLog(Order order) {
        // ... 保存操作日志, 即使下单失败日志也要记
    }
}