在Java后端开发中，Spring事务是保证数据一致性的核心手段，也是中高级工程师面试的“高频重难点”。很多开发者只会简单使用@Transactional注解开启事务，却不懂事务传播机制的作用、隔离级别的区别，导致生产环境中出现事务失效、数据脏读、死锁等问题，面试时被追问底层逻辑和实战选型就“无从下手”。本文从事务核心概念入手，深度拆解Spring事务传播机制的7种类型、事务隔离级别的5种规范，结合实战场景分析选型技巧，搭配面试高频考点和避坑指南，帮你彻底吃透Spring事务，既能解决生产问题，又能轻松应对面试追问。

Spring事务核心基础

事务（Transaction），是数据库操作的最小不可分割单元，核心满足ACID四大特性（面试必记），这是理解事务传播机制和隔离级别的前提：

① 原子性（Atomicity）：事务中的所有操作要么全部成功，要么全部失败，不会出现部分成功、部分失败的情况（比如转账，扣款和到账必须同时成功或同时失败）；

② 一致性（Consistency）：事务执行前后，数据库的完整性约束不被破坏（比如转账前两人总余额为1000，转账后总余额仍为1000）；

③ 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不会被其他事务干扰，避免出现脏读、不可重复读、幻读等问题；

④ 持久性（Durability）：事务一旦提交，其修改的数据会永久保存到数据库，即使数据库崩溃，数据也不会丢失。

补充（面试高频）：① Spring事务的核心价值：基于AOP思想，将事务控制逻辑（开启、提交、回滚）与核心业务逻辑解耦，无需手动编写事务管理代码；② Spring事务支持两种方式：编程式事务（手动通过TransactionTemplate控制）和声明式事务（通过@Transactional注解，主流方式）；③ 事务失效的常见原因：@Transactional注解标注在非public方法上、异常被try-catch捕获未抛出、数据源未配置事务管理器等（后续实战避坑会详细说明）。

简单示例（Spring声明式事务基础使用）：

@Servicepublic class UserService {    @Autowired    private UserMapper userMapper;    @Autowired    private OrderService orderService;    // 开启事务，默认传播机制和隔离级别    @Transactional    public void createUserAndOrder(User user, Order order) {        // 核心业务1：新增用户        userMapper.insertUser(user);        // 核心业务2：新增订单（调用另一个带事务的方法）        orderService.createOrder(order);    }}

核心说明：上述示例中，@Transactional注解会自动为createUserAndOrder方法开启事务，若insertUser或createOrder执行失败，整个事务会回滚，保证数据一致性。而这里就隐含了两个关键问题：① 当createUserAndOrder方法（有事务）调用createOrder方法（有事务）时，两个事务如何协同工作？这就是事务传播机制的作用；② 多个线程同时调用createUserAndOrder方法时，如何避免并发问题？这就是事务隔离级别的作用。

Spring事务传播机制

事务传播机制（Transaction Propagation），定义了当一个带事务的方法调用另一个带事务的方法时，当前事务如何传播到被调用方法。Spring提供了7种传播机制，全部定义在Propagation枚举类中，其中4种常用，3种冷门，需重点掌握常用类型的适用场景。

1. 传播机制核心定义

先明确两个核心概念（避免理解偏差）：

- 外层事务：调用方方法的事务（如上述示例中的createUserAndOrder方法）；

- 内层事务：被调用方方法的事务（如上述示例中的createOrder方法）。

（1）REQUIRED（默认值）：如果当前有事务，就加入当前事务；如果没有，就创建一个新事务

① 核心逻辑：内层事务融入外层事务，共用一个事务，只要有一个步骤失败，整个事务全部回滚；

② 实战场景：最常用，适用于“多个操作必须同时成功或同时失败”的场景（如新增用户+新增订单、扣款+到账）；

③ 示例解析：上述createUserAndOrder（REQUIRED）调用createOrder（REQUIRED），两者共用一个事务，若createOrder失败，insertUser也会回滚。

（2）REQUIRES_NEW：无论当前是否有事务，都创建一个新事务，新事务与原事务相互独立

① 核心逻辑：内层事务独立于外层事务，外层事务失败不会影响内层事务，内层事务失败也不会影响外层事务（除非手动回滚）；

② 实战场景：适用于“内层操作必须独立提交，不受外层事务影响”的场景（如日志记录、消息发送）；

③ 示例：

@Servicepublic class UserService {    @Transactional(propagation = Propagation.REQUIRED)    public void createUser(User user) {        userMapper.insertUser(user);        // 调用日志方法（独立事务）        logService.recordLog(user.getId());    }}@Servicepublic class LogService {    // 独立事务，即使外层事务回滚，日志也会提交    @Transactional(propagation = Propagation.REQUIRES_NEW)    public void recordLog(Long userId) {        logMapper.insertLog(userId, "新增用户");    }}

解析：若insertUser失败，外层事务回滚，但recordLog的内层事务已独立提交，日志会正常保存（符合“操作失败也要记录日志”的需求）。

（3）SUPPORTS：如果当前有事务，就加入当前事务；如果没有，就以非事务方式执行

① 核心逻辑：内层事务是否有事务，完全依赖外层事务，自身不主动创建事务；

② 实战场景：适用于“可选事务”的场景（如查询操作，有事务则加入，无事务则正常执行，不强制事务）；

③ 注意：若外层无事务，内层方法的操作不会被事务管理，出现异常不会回滚。

（4）NOT_SUPPORTED：无论当前是否有事务，都以非事务方式执行，若当前有事务，就暂停当前事务

① 核心逻辑：内层方法强制非事务执行，即使外层有事务，也会暂停外层事务，内层执行完成后，再恢复外层事务；

② 实战场景：适用于“无需事务”的场景（如批量查询、数据导出，避免事务占用资源）；

③ 注意：内层方法的操作不受事务控制，出现异常不会回滚，也不会影响外层事务。

（5）MANDATORY：必须在有事务的环境中执行，若当前没有事务，直接抛出异常

① 核心逻辑：内层方法依赖外层事务，外层必须有事务，否则无法执行；

② 实战场景：适用于“必须在事务中执行”的核心操作（如资金扣减，强制要求外层有事务，避免无事务导致数据不一致）；

③ 冷门：日常开发中较少使用，多用于严格的资金、权限相关操作。

（6）NEVER：必须在无事务的环境中执行，若当前有事务，直接抛出异常

① 核心逻辑：内层方法禁止在事务中执行，外层有事务则报错；

② 实战场景：适用于“绝对不能有事务”的操作（如日志清理、临时数据删除，避免事务锁定资源）；

③ 冷门：几乎不用，仅用于特殊场景。

（7）NESTED：如果当前有事务，就在当前事务中创建一个嵌套事务；如果没有，就创建一个新事务

① 核心逻辑：嵌套事务依赖外层事务，内层事务可以独立回滚，但外层事务回滚会带动内层事务一起回滚；内层事务回滚不会影响外层事务；

② 与REQUIRES_NEW的区别：NESTED是“嵌套事务”（共用一个事务上下文），REQUIRES_NEW是“独立事务”（两个完全独立的事务）；

③ 冷门：需数据库支持（如MySQL的SavePoint），日常开发中极少使用。

2. 传播机制实战对比

重点对比最常用的3种传播机制，避免混淆：

Spring事务隔离级别

事务隔离级别（Transaction Isolation Level），定义了多个事务并发执行时，相互之间的隔离程度，用于解决并发事务带来的脏读、不可重复读、幻读三大问题。Spring事务隔离级别基于数据库的隔离级别规范，提供了5种隔离级别，对应数据库的4种标准隔离级别（Spring新增一种默认级别）。

1. 并发事务三大问题

在讲解隔离级别前，先明确并发事务的三大问题（从严重到轻微排序），这是隔离级别的设计初衷：

① 脏读（Dirty Read）：一个事务读取了另一个事务未提交的数据，若另一个事务回滚，读取到的数据就是“脏数据”（无效数据）；

示例：事务A执行“扣款100元”（未提交），事务B读取到A的扣款后余额，此时A回滚，B读取的余额就是脏数据。

② 不可重复读（Non-Repeatable Read）：一个事务内多次读取同一数据，在读取过程中，另一个事务修改并提交了该数据，导致多次读取结果不一致；

示例：事务A第一次读取用户余额为1000元，事务B修改余额为800元并提交，事务A再次读取余额为800元，两次读取结果不同。

③ 幻读（Phantom Read）：一个事务内多次查询符合条件的记录，在查询过程中，另一个事务新增/删除了符合条件的记录，导致多次查询的记录数量不一致；

示例：事务A查询“年龄>18的用户”有10条，事务B新增1条年龄20的用户并提交，事务A再次查询时，结果变为11条，出现“幻读”。

2. Spring事务隔离级别（5种，按隔离程度从低到高排序）

Spring的隔离级别定义在Isolation枚举类中，与数据库隔离级别对应，其中DEFAULT是Spring默认，其余4种对应数据库标准级别：

（1）DEFAULT（默认值）：使用数据库默认的隔离级别

① 核心逻辑：Spring不指定隔离级别，直接沿用数据库的默认隔离级别；

② 数据库默认隔离级别：MySQL默认是REPEATABLE READ（可重复读），Oracle默认是READ COMMITTED（读已提交）；

③ 实战场景：日常开发中最常用，无需手动指定，适配大多数业务场景。

（2）READ_UNCOMMITTED（读未提交）：最低隔离级别，允许读取未提交的数据

① 核心逻辑：不解决任何并发问题，会出现脏读、不可重复读、幻读；

② 优点：并发性能最高（无需加锁）；

③ 实战场景：几乎不用，仅适用于“对数据一致性要求极低，追求极致并发”的场景（如实时监控数据，允许少量脏数据）。

（3）READ_COMMITTED（读已提交）：允许读取已提交的数据，禁止读取未提交的数据

① 核心逻辑：解决脏读问题，但会出现不可重复读、幻读；

② 优点：并发性能较好，兼顾数据一致性；

③ 实战场景：大多数业务场景（如电商订单、用户管理），适合对数据一致性有一定要求，但不追求极致隔离的场景（Oracle默认级别）。

（4）REPEATABLE READ（可重复读）：保证同一事务内多次读取同一数据的结果一致

① 核心逻辑：解决脏读、不可重复读问题，MySQL默认通过“MVCC多版本控制”解决幻读（Spring中仍可能出现幻读）；

② 优点：数据一致性较好，并发性能适中；

③ 实战场景：对数据一致性要求较高的场景（如金融、支付、库存管理），MySQL默认级别，也是日常开发中最常用的隔离级别之一。

（5）SERIALIZABLE（串行化）：最高隔离级别，所有事务串行执行，禁止并发

① 核心逻辑：解决所有并发问题（脏读、不可重复读、幻读），通过加表锁实现，事务排队执行；

② 缺点：并发性能极差，容易出现死锁；

③ 实战场景：极少使用，仅适用于“对数据一致性要求极高，不允许任何并发问题”的场景（如资金对账、核心账务处理）。

3. 隔离级别与并发问题对应关系（面试必背）

传播机制+隔离级别怎么选？

日常开发中，无需盲目追求“高隔离、高传播”，需结合业务场景选型，核心原则是“兼顾数据一致性和并发性能”，以下是最常用的选型方案（直接套用）：

1. 通用业务场景（如用户管理、订单创建、商品新增）

- 传播机制：REQUIRED（默认），保证多个操作原子性，同时成功或同时失败；

- 隔离级别：DEFAULT（默认），沿用数据库默认级别（MySQL为REPEATABLE READ，Oracle为READ COMMITTED）；

- 示例：

// 通用场景：新增订单+扣减库存，原子操作@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT)public void createOrderAndDeductStock(Order order, Long stockId) {    orderMapper.insertOrder(order);    stockMapper.deductStock(stockId, 1);}

2. 日志、消息发送等独立操作场景

- 传播机制：REQUIRES_NEW，保证日志/消息独立提交，不受外层事务回滚影响；

- 隔离级别：DEFAULT，无需额外提高隔离级别；

- 示例：

// 日志记录：独立事务，即使外层事务回滚，日志也提交@Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.DEFAULT)public void recordOperateLog(Long userId, String operate) {    logMapper.insertLog(new Log(userId, operate, LocalDateTime.now()));}

3. 金融、支付、库存等核心场景（数据一致性要求高）

- 传播机制：REQUIRED，保证核心操作原子性；

- 隔离级别：REPEATABLE READ（MySQL），解决脏读、不可重复读，兼顾并发；若要求极高，可使用SERIALIZABLE（谨慎使用，避免死锁）；

- 示例：

// 支付场景：扣款+到账，高一致性要求@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.REPEATABLE_READ)public void pay(Long fromUserId, Long toUserId, BigDecimal amount) {    // 扣减付款方余额    userMapper.deductBalance(fromUserId, amount);    // 增加收款方余额    userMapper.addBalance(toUserId, amount);}

4. 查询、数据导出等无修改操作场景

- 传播机制：SUPPORTS，有事务则加入，无事务则非事务执行；

- 隔离级别：READ_COMMITTED，避免脏读，提升并发性能；

- 示例：

// 查询场景：非核心查询，无需强制事务@Transactional(propagation = Propagation.SUPPORTS, isolation = Isolation.READ_COMMITTED)public List queryUserList(String keyword) {    return userMapper.selectByKeyword(keyword);}

5. 实战避坑指南

很多开发者配置了事务，但出现“事务失效”，以下是5个常见坑及解决方案：

① 坑1：@Transactional标注在非public方法上 → 解决方案：必须标注在public方法上（Spring事务底层基于AOP，非public方法无法被代理）；

② 坑2：异常被try-catch捕获，未抛出 → 解决方案：捕获异常后，手动抛出异常（throw new RuntimeException()），或设置rollbackFor属性（指定需要回滚的异常）；

③ 坑3：数据源未配置事务管理器 → 解决方案：配置DataSourceTransactionManager，Spring Boot自动配置（需引入spring-boot-starter-jdbc）；

④ 坑4：传播机制选择错误（如用REQUIRES_NEW导致事务独立，无法回滚） → 解决方案：根据业务场景选择传播机制，核心操作优先用REQUIRED；

⑤ 坑5：隔离级别过高（如用SERIALIZABLE导致并发低、死锁） → 解决方案：非核心场景不用最高隔离级别，优先用DEFAULT或REPEATABLE READ。

面试高频考点：相关关键问题

以下问题是面试中最常考的Spring事务相关追问，结合底层原理和实战场景给出标准答题思路，直接套用即可，避免答题流于表面。

1. Spring事务的ACID特性是什么？

核心答案：① 原子性：事务操作要么全成，要么全败；② 一致性：事务执行前后数据完整性不变；③ 隔离性：并发事务相互不干扰；④ 持久性：事务提交后数据永久保存。

2. Spring事务传播机制有哪些？最常用的是哪几种？

核心答案：共7种，定义在Propagation枚举中。最常用的3种：① REQUIRED（默认）：内外层共用事务；② REQUIRES_NEW：内外层独立事务；③ SUPPORTS：依赖外层事务，无事务则非事务执行。

3. REQUIRED和REQUIRES_NEW的区别是什么？

核心答案：① 事务关系：REQUIRED内外层共用一个事务，REQUIRES_NEW内外层是两个独立事务；② 回滚影响：REQUIRED外层回滚内层也回滚，内层回滚外层也回滚；REQUIRES_NEW外层回滚不影响内层，内层回滚不影响外层；③ 适用场景：REQUIRED用于原子操作，REQUIRES_NEW用于日志、消息等独立操作。

4. 并发事务的三大问题是什么？各自的定义是什么？

核心答案：① 脏读：读取未提交的数据，数据可能无效；② 不可重复读：同一事务内多次读取同一数据，结果不一致；③ 幻读：同一事务内多次查询，符合条件的记录数量不一致。

5. Spring事务隔离级别有哪些？MySQL默认是什么？

核心答案：Spring有5种隔离级别：DEFAULT（默认）、READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE READ、SERIALIZABLE。MySQL默认隔离级别是REPEATABLE READ（可重复读），通过MVCC解决幻读。

6. 为什么会出现事务失效？常见原因有哪些？

核心答案：常见5种原因：① @Transactional标注在非public方法上；② 异常被try-catch捕获未抛出；③ 数据源未配置事务管理器；④ 传播机制选择错误；⑤ 隔离级别配置不当（如过高导致死锁，过低导致数据不一致）。

7. 实战中，传播机制和隔离级别如何选型？

核心答案：遵循“兼顾一致性和并发”原则：① 通用场景：REQUIRED+DEFAULT；② 独立操作（日志、消息）：REQUIRES_NEW+DEFAULT；③ 核心场景（金融、支付）：REQUIRED+REPEATABLE READ；④ 查询场景：SUPPORTS+READ_COMMITTED；⑤ 避免过度配置（如不用SERIALIZABLE，避免并发过低）。

8. Spring事务是基于什么实现的？

核心答案：Spring事务底层基于AOP（面向切面编程）和动态代理实现。通过@Transactional注解触发AOP切面，在方法执行前开启事务，执行后提交事务，出现异常时回滚事务；动态代理采用JDK Proxy（目标类实现接口）或CGLIB（目标类无接口）。

总结

本文围绕Spring事务传播机制和隔离级别展开，核心要点可归纳为三点，贴合面试答题逻辑和实战需求，方便记忆和表述：

1. 传播机制：核心解决“内外层事务如何协同”，7种机制中重点掌握REQUIRED（默认）、REQUIRES_NEW、SUPPORTS，根据业务是否需要独立事务选型。

2. 隔离级别：核心解决“并发事务的干扰问题”，5种级别中重点掌握DEFAULT、READ_COMMITTED、REPEATABLE READ，兼顾数据一致性和并发性能，避免过度配置。

3. 实战关键：优先使用声明式事务（@Transactional），避开事务失效的5个常见坑；选型时不盲目追求高隔离、高传播，结合业务场景（通用、核心、独立操作）灵活选择，既保证数据一致性，又不影响系统并发。

面试中，该考点常结合Spring AOP、动态代理、数据库事务提问，比如“事务传播机制的区别”“隔离级别解决的并发问题”“事务失效的原因”，掌握本文核心内容，可轻松应对各类追问，体现自身的实战能力和底层思维，提升面试通过率。