Spring事务传播机制七种类型解析

**Spring事务传播机制详解：七种行为深度解析与应用场景** Spring事务传播机制是声明式事务中不可或缺的核心概念，它定义了方法调用时事务的处理方式。本文将深入解析Spring提供的七种事务传播行为：`PROPAGATION_REQUIRED`、`PROPAGATION_REQUIRES_NEW`、`PROPAGATION_SUPPORTS`、`PROPAGATION_NOT_SUPPORTED`、`PROPAGATION_NEVER`、`PROPAGATION_MANDATORY`以及`PROPAGATION_NESTED`。每种行为都有其独特的适用场景，从默认的加入或新建事务，到强制开启新事务、支持或拒绝事务，再到嵌套子事务的灵活运用，选择合适的传播行为能有效避免事务失效问题，提升系统的稳定性和一致性。本文旨在帮助开发者透彻理解事务传播机制，并在实际开发中根据业务需求合理选择，清晰地控制事务边界。

Spring事务传播机制定义了方法调用时事务的处理方式，共7种行为。1.PROPAGATION_REQUIRED默认行为，有事务则加入，无则新建；适用于多数需原子性的操作。2.PROPAGATION_REQUIRES_NEW强制新建事务，挂起当前事务；用于独立事务控制如日志记录。3.PROPAGATION_SUPPORTS支持当前事务或非事务执行；适合查询操作。4.PROPAGATION_NOT_SUPPORTED以非事务执行并挂起当前事务；用于不依赖事务的操作。5.PROPAGATION_NEVER拒绝事务，否则抛异常；用于明确不能运行在事务中的操作。6.PROPAGATION_MANDATORY必须存在事务，否则报错；用于强制要求事务上下文的操作。7.PROPAGATION_NESTED嵌套子事务，可独立提交或回滚；用于局部回滚场景，依赖数据库支持。

Spring事务传播机制是我们在使用声明式事务时绕不开的一个核心概念。很多人在开发过程中遇到事务失效的问题，往往是因为没有正确理解事务传播行为的含义和适用场景。

什么是事务传播机制？

简单来说，事务传播机制决定了当一个方法被另一个方法调用时，事务应该如何处理。比如：当前有事务，就继续用；没有事务，就新建一个；或者不管怎样都运行在非事务环境下等等。

Spring一共定义了7种事务传播行为，适用于不同的业务场景。

PROPAGATION_REQUIRED：最常用的默认行为

这是 Spring 的默认事务传播行为，意思是：

如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。

这个行为非常实用，也是大多数业务逻辑中首选的方式。例如，你在 service 层的方法 A 上加了 @Transactional，它调用了另一个也加了 @Transactional 的方法 B，默认情况下它们会运行在同一个事务中。

@Transactional
public void methodA() {
    // do something
    methodB();
}

@Transactional
public void methodB() {
    // 同一个事务上下文
}

适用场景：

• 多个操作需要保证原子性，要么全成功，要么全失败。
• 不关心调用链中是否已有事务。

PROPAGATION_REQUIRES_NEW：强制开启新事务

顾名思义，这个行为会 挂起当前事务（如果有），并开启一个新的事务。也就是说，无论调用方有没有事务，当前方法都会运行在一个全新的事务中。

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void methodC() {
    // 总是在新事务中执行
}

适用场景：

• 需要独立事务控制，比如日志记录、审计等不想受外层事务回滚影响的操作。
• 希望某些关键操作即使其他部分失败也不受影响。

注意点：

• 因为每次都要新开事务，性能上会有一定开销。
• 要确保方法是 public，并且走代理，否则事务不会生效。

PROPAGATION_SUPPORTS：支持当前事务，无则不启用

这种行为比较“随缘”：

• 如果当前有事务，就在事务中执行；
• 如果没有事务，就以非事务方式执行。

常用于查询类操作，因为查询通常不需要事务，但如果在事务中调用也没问题。

@Transactional(propagation = Propagation.SUPPORTS)
public User getUserById(Long id) {
    return userRepository.findById(id);
}

适用场景：

• 查询操作或只读操作，希望不影响整体事务流程。
• 方法可能被事务方法调用，也可能被非事务方法调用。

PROPAGATION_NOT_SUPPORTED：不支持事务，挂起已有事务

与 SUPPORTS 相反，它总是以非事务方式执行，如果当前有事务，就先挂起。

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void logSomething() {
    // 即使被事务方法调用，也不会参与事务
}

适用场景：

• 日志、统计等对事务无依赖的操作，避免事务带来的资源占用。
• 某些外部系统调用，不想受事务管理器控制。

PROPAGATION_NEVER：坚决不接受事务

这个行为表示：当前方法不能在事务中执行，否则抛异常。

@Transactional(propagation = Propagation.NEVER)
public void nonTransactionalMethod() {
    // 只能在非事务环境下运行
}

适用场景：

• 明确要求某些操作不能运行在事务中，比如异步通知、回调等。
• 开发调试阶段用来检测是否有意外的事务传播进来。

PROPAGATION_MANDATORY：必须存在事务，否则报错

这个行为刚好相反：当前必须有事务，否则抛出异常。

@Transactional(propagation = Propagation.MANDATORY)
public void mustInTransaction() {
    // 必须由事务方法调用
}

适用场景：

• 强制某些操作只能在事务上下文中执行，比如数据变更前的校验。
• 确保调用链中事务的完整性。

PROPAGATION_NESTED：嵌套事务

这是一个稍微复杂的行为：在当前事务中嵌套一个子事务。这个子事务可以独立提交或回滚，但主事务回滚会影响子事务。

@Transactional(propagation = Propagation.NESTED)
public void nestedOperation() {
    // 嵌套事务内可单独回滚
}

适用场景：

• 某些操作可以局部回滚而不影响整个事务。
• 数据库支持保存点（Savepoint）的情况下使用。

注意：

• 是否真正支持嵌套事务取决于底层数据库和驱动是否支持 Savepoint。
• 在 MySQL 中默认是不支持的，除非你手动配置。

基本上就这些，Spring 提供的七种事务传播行为各有用途，选择合适的行为能有效避免事务失效问题。在实际开发中，推荐根据业务需求合理使用，而不是一味追求“全部加 @Transactional”。

掌握这几种传播行为后，在设计服务层接口时就能更清晰地控制事务边界，提升系统的稳定性和一致性。

本篇关于《Spring事务传播机制七种类型解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！