北京时间 2026 年 4 月 10 日

Spring 框架在企业级 Java 开发中占据绝对主导地位，其声明式事务管理能力几乎是每一个涉及数据库写操作的后端项目都在默默使用的功能-40。而事务传播行为（Transaction Propagation Behavior），正是 Spring 事务体系中最核心、最易混淆、也最常被面试官追问的高频知识点。当多个事务方法相互调用时，事务该如何“传播”？这个问题看似简单，背后却隐藏着 REQUIRED、REQUIRES_NEW、NESTED 等 7 种传播行为的复杂逻辑，许多开发者只会用默认注解，一旦遇到嵌套调用不回滚、数据异常等问题便无从下手。本文将从痛点出发，通过概念拆解、代码示例、底层原理到面试要点，帮你彻底吃透 Spring 事务传播行为。

一、痛点切入：为什么我们需要事务传播行为？

在没有 Spring 声明式事务的年代，开发者需要手动管理事务的开启、提交和回滚：

// 没有Spring事务的传统写法——代码冗余且耦合
public void transfer(String from, String to, int amount) {
    Connection conn = null;
    try {
        conn = dataSource.getConnection();
        conn.setAutoCommit(false);      // 手动关闭自动提交
        // 业务操作：A账户扣钱
        jdbcTemplate.update(conn, "UPDATE account SET balance = balance - ? WHERE id = ?", amount, from);
        // 业务操作：B账户加钱
        jdbcTemplate.update(conn, "UPDATE account SET balance = balance + ? WHERE id = ?", amount, to);
        conn.commit();                  // 手动提交
    } catch (Exception e) {
        if (conn != null) conn.rollback();  // 手动回滚
    } finally {
        if (conn != null) conn.close();
    }
}

这种编程式事务管理存在三大痛点：

1. 代码冗余严重：每个需要事务的业务方法都要重复编写 commit/rollback 逻辑；

2. 事务与业务高度耦合：事务控制代码混在业务逻辑中，可读性和维护性差；

3. API 不统一：JDBC 用 Connection、Hibernate 用 Session，切换技术栈需重写事务代码-43。

Spring 通过 AOP 代理机制实现了声明式事务管理，开发者只需在方法上标注 @Transactional，便能将事务控制与业务逻辑解耦。当多个带 @Transactional 的方法相互调用时，一个全新的问题随之而来：被调用方应该复用调用方的事务，还是新建独立事务？如果发生异常，回滚范围如何界定？

这些问题，正是事务传播行为要解决的。

二、核心概念讲解：什么是事务传播行为（Propagation Behavior）？

标准定义：事务传播行为（Transaction Propagation Behavior）定义了当一个事务方法被另一个事务方法调用时，事务应如何在这些方法之间进行传播——是复用当前事务、新建事务，还是以非事务方式执行-2-11。

一句话理解：传播行为就是“事务方法之间的调用规则”——告诉你新方法是该“加入老大哥的事务”，还是“自己开个新摊子”，抑或“根本不参与”。

Spring 共定义了 7 种事务传播行为，通过 @Transactional(propagation = Propagation.XXX) 配置。其中最核心、最常用的三种分别是 REQUIRED（默认）、REQUIRES_NEW 和 NESTED，掌握它们便能覆盖 95% 以上的业务场景-5。

三、三种核心传播行为深度解析

1. REQUIRED（必须有）——默认行为，99% 业务场景的选择

定义：如果当前存在事务，则加入该事务；如果当前没有事务，则新建一个事务-4。

通俗理解：REQUIRED 就像一个“合群者”——有团队就加入团队，没团队就自己拉一个团队。

典型场景：电商下单场景——创建订单和扣减库存必须在同一事务中，要么全部成功，要么全部失败-11。

代码示例：

@Service
public class OrderService {
    @Autowired
    private StockService stockService;
    
    // 调用方：带有事务
    @Transactional(rollbackFor = Exception.class)
    public void createOrder(Long productId, Integer count) {
        // 1. 创建订单
        orderRepository.save(new Order(productId, count));
        // 2. 调用扣减库存方法（复用当前事务）
        stockService.deductStock(productId, count);
    }
}

@Service
public class StockService {
    // 被调用方：propagation = REQUIRED（默认值，可省略）
    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    public void deductStock(Long productId, Integer count) {
        Stock stock = stockRepository.findByProductId(productId)
            .orElseThrow(() -> new RuntimeException("库存不存在"));
        if (stock.getCount() < count) {
            throw new RuntimeException("库存不足");
        }
        stock.setCount(stock.getCount() - count);
        stockRepository.save(stock);
    }
}

执行结果：若 deductStock 抛出异常，createOrder 的订单创建操作会一并回滚，不会出现“有订单无库存”的脏数据-11。

2. REQUIRES_NEW（新建事务）——独立事务，互不影响

定义：总是创建一个新的事务。如果当前存在事务，则把当前事务挂起（暂停），待新事务执行完毕后，再恢复原事务-4。

通俗理解：REQUIRES_NEW 就像“另立门户”——不管外面有没有团队，我都自己新拉一个团队，两个团队各干各的，互不干扰。

典型场景：日志记录、审计、发送邮件——这些操作必须独立提交，不能被主事务的回滚所影响-5。

代码示例：

@Service
public class LogService {
    // REQUIRES_NEW：无论外层是否有事务，都新建独立事务
    @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
    public void logAction(String msg) {
        logRepository.save(new Log(msg));
        // 即使这里抛异常，也不会影响外层事务
        if (msg.contains("fail")) {
            throw new RuntimeException("日志写入失败");
        }
    }
}

@Service
public class MainService {
    @Autowired
    private LogService logService;
    
    @Transactional
    public void mainJob(String data) {
        // 核心业务操作
        saveCoreData(data);
        try {
            // 日志记录：独立事务，失败不影响主流程
            logService.logAction("processing: " + data);
        } catch (Exception e) {
            // 必须 catch 异常，否则会传染到外层事务！
            log.error("日志记录失败，但不影响主业务", e);
        }
    }
}

关键注意点：外层事务方法必须 catch 内层抛出的异常，否则异常会向上传播导致外层事务一并回滚-7。

3. NESTED（嵌套事务）——存档点机制，支持部分回滚

定义：如果当前存在事务，则在嵌套事务（基于数据库 Savepoint 机制）内执行；如果当前没有事务，则行为等同于 REQUIRED-4。

通俗理解：NESTED 就像“在游戏中设置存档点”——内部事务可以独立回滚到“存档点”的位置，而不会影响外部事务已经完成的操作。它与 REQUIRES_NEW 的本质区别在于：REQUIRES_NEW 是完全独立的事务，两个事务彼此无关；NESTED 则是父子关系，子事务是父事务的一部分，父事务回滚时子事务也会回滚。

典型场景：批量处理中需要部分回滚的场景——比如保存订单成功后，发优惠券环节失败，只回滚发券部分，保留订单-5。

代码示例：

@Service
public class BatchService {
    
    @Transactional(rollbackFor = Exception.class)
    public void processBatch(List<Order> orders) {
        for (int i = 0; i < orders.size(); i++) {
            try {
                // NESTED：每个订单独立存档，一个失败不影响其他
                processSingleOrder(orders.get(i));
            } catch (Exception e) {
                log.error("订单{}处理失败，已回滚该订单操作", i, e);
                // 继续处理下一个订单
            }
        }
    }
    
    @Transactional(propagation = Propagation.NESTED, rollbackFor = Exception.class)
    public void processSingleOrder(Order order) {
        // 该订单的完整业务处理
        // 如果失败，只回滚该订单的操作，不影响其他订单
    }
}

四、概念关系与区别总结

一句话记忆口诀：

• REQUIRED：“能蹭就蹭，没蹭自建”——99% 场景用它-5

• REQUIRES_NEW：“老子另起炉灶，跟你没关系”——日志审计专用-5

• NESTED：“在你家院子里搭个小屋，拆小屋不拆你家”——批量部分回滚-5

五、底层原理解析：为什么加个注解就能管理事务？

@Transactional 之所以能让方法拥有事务能力，核心依赖 Spring 的 AOP（Aspect Oriented Programming，面向切面编程） 和 动态代理 机制。

Spring 在启动时会扫描所有带有 @Transactional 注解的 Bean，不直接返回原对象，而是创建一个代理对象（JDK 动态代理或 CGLIB 代理）-22。当外部调用该方法时，实际调用的是代理对象，代理对象将调用委托给 TransactionInterceptor（事务拦截器） ——它根据事务配置（传播行为、隔离级别等），调用 PlatformTransactionManager（平台事务管理器） 获取数据库连接并开启事务，然后将连接绑定到当前线程的 ThreadLocal 中，确保事务内的多个数据库操作使用同一个连接-22。方法执行成功后代理对象提交事务，发生异常则根据配置决定回滚。

支撑上层功能的底层知识点：

• AOP 代理机制：JDK Proxy（有接口）或 CGLIB（无接口）；

• PlatformTransactionManager：事务核心接口，常用实现为 DataSourceTransactionManager；

• TransactionInterceptor：事务拦截器，负责事务增强逻辑的织入；

• ThreadLocal：用于将数据库连接绑定到当前线程，实现事务上下文传递-4-22。

⚠️ 特别提醒：传播行为生效的前提是调用路径必须走 Spring 代理。同类中非事务方法直接调用带 @Transactional 的方法，不会触发代理，事务将失效！ 这是开发中最常见、最隐蔽的坑-7。

六、高频面试题与参考答案

Q1：Spring 事务传播行为有哪些？REQUIRED、REQUIRES_NEW 和 NESTED 有什么区别？

参考答案：
Spring 定义了 7 种事务传播行为：REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED。最核心的是 REQUIRED（默认）、REQUIRES_NEW 和 NESTED。三者的核心区别如下：

• REQUIRED：有事务则加入，无则新建。内外共用一个事务，一个回滚全部回滚；

• REQUIRES_NEW：总是新建独立事务，挂起当前事务。两个事务完全独立，互不影响；

• NESTED：有事务则创建嵌套事务（基于 Savepoint），无则新建。嵌套事务可独立回滚，但父事务回滚时子事务也回滚-4-5。

Q2：@Transactional 失效的常见场景有哪些？

参考答案（回答时按以下三点展开即可）：

1. 自调用问题：同一类内非事务方法直接调用带 @Transactional 的方法，不走代理，事务失效-35；

2. 方法不是 public：@Transactional 默认只对 public 方法生效，protected/private 会被忽略-36；

3. 异常被 catch 吞掉：手动 catch 异常后未重新抛出，Spring 无法感知异常，不会回滚-40。

Q3：编程式事务和声明式事务有什么区别？

参考答案：

• 编程式事务：通过 TransactionTemplate 或 PlatformTransactionManager 在代码中显式控制事务边界，灵活性高但代码侵入性强，事务代码与业务代码耦合；

• 声明式事务：基于 AOP 实现，通过 @Transactional 注解声明事务边界，由 Spring 自动管理事务的开启、提交和回滚，代码简洁、解耦好，是大多数场景的推荐做法-12。

七、总结

回顾全文的核心知识点：

1. 事务传播行为是 Spring 事务体系中定义“事务方法之间调用规则”的核心机制，决定了被调用方是复用、新建还是嵌套事务；

2. REQUIRED（默认）适用于绝大多数业务场景，REQUIRES_NEW 适用于需要独立提交的操作（如日志），NESTED 适用于需要部分回滚的批量处理；

3. 底层原理基于 AOP 动态代理 + TransactionInterceptor + PlatformTransactionManager，事务上下文通过 ThreadLocal 传递；

4. 高频失效场景包括自调用、非 public 方法、异常被吞掉等，务必注意事务生效的前提是调用路径走 Spring 代理。

易错点提示：

• 不要在同类的非事务方法中直接 this.xxx() 调用带 @Transactional 的方法；

• 使用 REQUIRES_NEW 时，外层记得 catch 内层异常；

• 明确指定 rollbackFor = Exception.class，否则受检异常不会触发回滚。

Spring 事务传播行为看似复杂，但只要理清 REQUIRED、REQUIRES_NEW、NESTED 三条核心路径，就能应对绝大多数实战和面试场景。如果本文对你有帮助，欢迎持续关注本系列后续内容——下一篇我们将深入探讨 Spring 事务的隔离级别与回滚规则，不见不散！