声明式事务的传播机制是解决多个事务方法嵌套调用时，事务如何创建、复用、挂起或隔离的核心逻辑。它的实现依赖于事务管理器、事务状态管理、线程上下文绑定等组件的协同，本质是通过一套 “规则判断 + 状态维护” 的逻辑，在方法调用时动态决定事务的行为。
一、传播机制的核心目标
当一个带有@Transactional的方法 A 调用另一个带有@Transactional的方法 B 时，需要解决：
- 方法 B 是否复用方法 A 的事务？
- 方法 B 是否需要新建事务，同时挂起方法 A 的事务？
- 如果方法 A 没有事务，方法 B 是否必须报错（如 MANDATORY）？
传播机制就是通过预定义的规则（如 REQUIRED、REQUIRES_NEW 等），自动处理这些场景，避免手动控制事务的繁琐。
二、实现的核心组件
传播机制的实现依赖于 Spring 事务体系中的几个核心组件，它们的协作是关键：
TransactionDefinition
定义了事务的 “元信息”，包括：- 传播行为（propagationBehavior）：如 REQUIRED、REQUIRES_NEW 等；
- 隔离级别、超时时间、是否只读等。
每个@Transactional注解的方法都会被解析为一个TransactionDefinition对象，作为传播机制的判断依据。
PlatformTransactionManager
事务管理器的顶层接口，其中getTransaction(TransactionDefinition definition)方法是传播机制的 “决策核心”—— 它根据当前线程的事务状态和TransactionDefinition中的传播行为，决定如何处理事务（创建、复用、挂起等）。TransactionStatus
维护事务的实时状态，包括：- 是否是新创建的事务（isNewTransaction ()）；
- 是否挂起了外层事务（如果有）；
- 事务是否被标记为回滚（isRollbackOnly ()）。
它是事务管理器和后续操作（提交 / 回滚）的 “状态凭证”。
TransactionSynchronizationManager
通过ThreadLocal存储当前线程的事务上下文（如当前事务的连接、挂起的事务等），让事务管理器能感知到 “当前线程是否已有事务”。TransactionInterceptor（AOP 拦截器）
作为 AOP 的环绕通知，在目标方法执行前触发事务管理器的getTransaction()方法（决策传播行为），在方法执行后根据结果触发commit()或rollback()。
三、传播机制的实现流程
以 “方法 A 调用方法 B” 为例，拆解传播机制的核心步骤：
步骤 1：AOP 拦截与元信息解析
当方法 B 被调用时，TransactionInterceptor先拦截调用，解析方法 B 上@Transactional注解的属性（如传播行为、隔离级别），生成TransactionDefinition对象。
步骤 2：判断当前线程是否已有事务
事务管理器通过TransactionSynchronizationManager的hasResource(...)方法，检查当前线程的ThreadLocal中是否绑定了事务资源（如数据库连接）。
- 如果有资源，说明当前线程已有事务（可能是方法 A 创建的）；
- 如果没有，说明当前线程无事务。
步骤 3：根据传播行为决策事务操作
事务管理器的getTransaction()方法根据 “当前是否有事务” 和 “传播行为”，执行不同逻辑：
| 传播行为 | 决策逻辑（核心） |
|---|---|
| REQUIRED | 若当前有事务，复用当前事务（返回已有的 TransactionStatus）；若没有，新建事务。 |
| REQUIRES_NEW | 无论当前是否有事务，都新建一个事务；若有当前事务，先挂起（存入 ThreadLocal）。 |
| SUPPORTS | 若当前有事务，复用；若没有，以非事务方式执行（不创建事务）。 |
| MANDATORY | 若当前有事务，复用；若没有，直接抛出异常（要求必须在事务中执行）。 |
步骤 4：维护事务状态（TransactionStatus）
- 对于新建的事务：
TransactionStatus会标记isNewTransaction()=true，并将事务资源（如数据库连接）通过TransactionSynchronizationManager绑定到当前线程。 - 对于复用的事务：
TransactionStatus会关联到外层事务的状态，同时记录 “嵌套层级”（方便后续提交 / 回滚时判断是否是最外层事务）。 - 对于挂起的事务（如 REQUIRES_NEW）：会将当前事务的状态存入
ThreadLocal的 “挂起队列”，待新事务完成后恢复。
步骤 5：事务执行与后续处理
方法 B 执行完成后，TransactionInterceptor会根据执行结果（正常 / 异常）和TransactionStatus决定提交或回滚：
- 若方法 B 是新建事务（如 REQUIRES_NEW 或 REQUIRED 且无外层事务）：直接提交或回滚，并解绑线程资源；
- 若方法 B 是复用外层事务（如 REQUIRED 且有外层事务）：仅标记事务状态（如异常时标记
rollbackOnly），最终由最外层事务统一提交 / 回滚； - 若方法 B挂起了外层事务（如 REQUIRES_NEW）：提交 / 回滚新事务后，从
ThreadLocal中恢复被挂起的外层事务，继续执行外层逻辑。
四、关键细节：嵌套事务的状态管理
传播机制的核心难点是 “嵌套事务的状态同步”，例如：
- 当内层方法（REQUIRED）抛出异常时，会将外层事务的
TransactionStatus标记为rollbackOnly，外层方法执行到最后会发现这个标记，从而触发整体回滚； - 当内层方法使用 REQUIRES_NEW 时，它的事务独立于外层，内层提交 / 回滚不会影响外层（但外层可以捕获内层异常后继续执行）。
这一切都依赖TransactionStatus对状态的精准记录，以及TransactionSynchronizationManager对线程上下文的维护 —— 确保事务状态在嵌套调用中不混乱。
总结
声明式事务传播机制的实现，本质是：
通过 AOP 拦截事务方法，解析传播规则，结合线程本地存储（ThreadLocal）感知当前事务状态，由事务管理器动态决策事务的创建、复用或挂起，并通过事务状态（TransactionStatus）维护嵌套关系，最终实现多个事务方法嵌套时的自动化事务管理。
理解传播机制的关键，在于把握 “当前线程事务状态” 与 “传播行为规则” 的对应关系，以及TransactionStatus如何串联起整个事务的生命周期。
如果这篇文章对大家有帮助可以点赞关注，你的支持就是我的动力😊！
