声明式事务 @Transactional 的解析与失效场景大全

概述

衔接前文

在前文《Spring 事务管理抽象：PlatformTransactionManager 与 TransactionSynchronizationManager》中，我们深度剖析了 Spring 事务管理的核心骨架。PlatformTransactionManager 通过策略模式屏蔽了不同数据访问技术的事务控制差异，而 TransactionSynchronizationManager 则利用 ThreadLocal 机制，在当前线程内维系了事务资源与会话状态，为编程式事务管理提供了强大且灵活的基础设施。

然而，在现代 Spring 应用开发中，我们很少直接调用 transactionManager.commit() 或 transactionManager.rollback()。取而代之的是，我们在业务方法上轻轻标注一个 @Transactional 注解，事务便“魔法般”地生效了。这种声明式事务管理将事务逻辑从业务代码中剥离，极大地提升了开发效率与代码整洁性。但魔法的背后并非无迹可寻，它本质上是 Spring AOP 的一个经典且复杂的应用：通过 TransactionInterceptor 在目标方法的前后，织入由 PlatformTransactionManager 驱动的事务获取与提交/回滚逻辑。

正是因为它高度依赖 AOP 代理机制，@Transactional 也完美地“继承”了代理模式的所有优点与限制。许多让开发者困惑不已的线上事故——诸如“事务为什么没回滚？”——答案往往就隐藏在代理对象的调用链、异常传播路径，或是看似不起眼的传播行为配置中。本文将正面解开 @Transactional 的神秘面纱，从 @EnableTransactionManagement 的内部机制开始，系统性地拆解其工作原理，并最终构建一份包含 15 个典型失效场景的全景分析地图，为专家级读者提供一套可靠的事务诊断框架。

核心要点

• 开启机制：@EnableTransactionManagement 如何通过 @Import 机制，驱动 TransactionInterceptor、TransactionAttributeSource、BeanFactoryTransactionAttributeSourceAdvisor 等核心基础设施的注册与装配。
• 拦截器内部流程：TransactionAspectSupport.invokeWithinTransaction 作为事务逻辑的核心调度者，如何协同 PlatformTransactionManager 完成获取事务、执行目标方法、提交/回滚的完整生命周期。
• 失效全景：深度剖析自调用、非 public 方法、异常类型不匹配、传播行为、多线程环境等15大失效场景，每个场景都追溯至核心源码依据。
• 诊断手段：结合 TRACE 级别日志、DataSource 代理、TransactionSynchronizationManager 编程式诊断等工具，构建系统化的问题排查思路。
• 与 AOP 的耦合：揭示 AOP 代理类型（JDK 动态代理 vs. CGLIB）、exposeProxy 等配置如何决定事务的生效与否，这是理解声明式事务强大与脆弱并存的关键。

文章组织架构图

flowchart TD
    subgraph S1 ["第一部分：核心原理篇"]
        n1["1. 声明式事务的启动过程：<br/>@EnableTransactionManagement 源码解析"]
        n2["2. @Transactional 注解元数据的提取与存储"]
        n3["3. 事务拦截器 TransactionInterceptor 源码拆解"]
        n4["4. 与 AOP 的整合：<br/>代理创建、拦截链与事务 Advisor"]
    end

    subgraph S2 ["第二部分：实践与问题篇"]
        n5["5. 失效案例全景分析<br/>(15个典型场景)"]
        n6["6. 事务事件与<br/>@TransactionalEventListener 的原理"]
        n7["7. 调试与诊断工具"]
    end

    subgraph S3 ["第三部分：高级与总结篇"]
        n8["8. 生产事故排查专题<br/>(3个案例)"]
        n9["9. 面试高频专题<br/>(15题含设计题)"]
        C["总结：@Transactional<br>失效场景速查表"]
    end

    %% 核心依赖关系
    n1 --> n2 --> n3 --> n4
    n4 --> n5
    n3 --> n5
    n2 --> n5

    %% 模块间关联
    n5 --> n6
    n4 --> n7
    n3 --> n7

    n5 --> n8
    n2 --> n8
    n4 --> n8

    n5 --> n9
    n1 --> n9
    n3 --> n9

    n8 --> C
    n9 --> C

    classDef topic fill:#f8f9fa,stroke:#333,stroke-width:2px,rx:5,color:#333;
    class S1,S2,S3 topic;

架构图说明

• 总览说明：本文严格遵循“原理 → 实践 → 诊断 → 升华”的认知路径。全文 9 个模块从声明式事务的底层启动机制（模块1）开始，逐步深入元数据解析（模块2）、拦截器源码（模块3）及 AOP 整合（模块4），这四部分构成了理解所有问题的理论基石。在此基础上，我们集中火力剖析 15 个失效场景（模块5），并引入事务事件机制（模块6）和调试工具（模块7）以完善知识体系。最后，通过生产事故排查（模块8）和面试高频题（模块9）将理论能力转化为实战与表达能力，并以一份全景速查表作为全文收官。

• 逐模块说明：

  • 模块 1 是整个声明式事务的“点火器”，解析 @EnableTransactionManagement 如何通过 @Import 机制触发一系列基础设施的创建。
  • 模块 2 是“原材料加工厂”，负责将 @Transactional 注解中的配置信息解析为 Spring 内部可理解的 TransactionAttribute 对象。
  • 模块 3 是“核心引擎”，也是本文的重中之重。它拆解了 TransactionInterceptor 的 invoke 方法，展示了如何将模块 2 的元数据与模块 4 的 AOP 机制、以及前文的 PlatformTransactionManager 精密协作。
  • 模块 4 揭示了 AOP 的“包装魔法”，说明了事务逻辑是如何通过代理对象被织入到目标方法调用链中的。
  • 模块 5 是“避坑指南”，基于前四个模块的原理，系统化地归纳并解释了所有常见的失效场景，是理论的最佳实践验证。
  • 模块 6-7 是“强化武器库”，提供了事务事件和调试诊断工具，用于应对复杂业务和线上问题。
  • 模块 8-9 是“能力校验场”，通过真实的生产事故和面试题，检验并巩固对声明式事务的深度理解。

• 关键结论：@Transactional 的失效极少源于 Spring 自身的 BUG，其根源几乎总是开发者对 AOP 代理限制、异常传播链和事务传播行为的理解存在偏差。掌握这些失效场景，本质上就是掌握了 Spring 核心机制的精妙之处与边界。

1. 声明式事务的启动过程：@EnableTransactionManagement 源码解析

@EnableTransactionManagement 是开启 Spring 声明式事务的开关。它本身并没有做任何事，其魔力全在于 @Import 注解导入的 TransactionManagementConfigurationSelector。

// org.springframework.transaction.annotation.EnableTransactionManagement
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(TransactionManagementConfigurationSelector.class)
public @interface EnableTransactionManagement {

	// 默认使用代理模式
	boolean proxyTargetClass() default false;

	// 切面模式，默认 PROXY，可切换为 ASPECTJ 实现编译期或类加载期织入
	AdviceMode mode() default AdviceMode.PROXY;

	// ...其他属性
}

源码解读：@Import 是 Spring 上下文启动时，ConfigurationClassParser 会处理的注解。TransactionManagementConfigurationSelector 会根据 mode() 属性的值，向 Spring 容器注册不同的配置类。对于默认的 AdviceMode.PROXY，它最终会向容器注册 ProxyTransactionManagementConfiguration 类。这标志着整个声明式事务基础设施装配的开始。

接下来，我们将通过一张序列图来直观地展示从 @EnableTransactionManagement 到事务拦截器就绪的完整装配流程。

sequenceDiagram
    participant User as 开发者应用
    participant ConfigParser as ConfigurationClassParser
    participant Selector as TransactionManagement<br/>ConfigurationSelector
    participant ProxyConfig as ProxyTransactionManagement<br/>Configuration
    participant Container as Spring IoC容器

    User->>ConfigParser: 解析启动配置类
    ConfigParser->>ConfigParser: 扫描注册类上的@Import
    ConfigParser->>Selector: 处理@Import引入的Selector
    Selector->>Selector: 根据mode=PROXY选择配置类
    Selector->>ConfigParser: 返回 ProxyTransactionManagementConfiguration
    ConfigParser->>Container: 注册ProxyTransactionManagementConfiguration
    
    Note over Container: 开始执行 ProxyTransactionManagementConfiguration 内的@Bean方法
    Container->>ProxyConfig: 调用 transactionAttributeSource()
    ProxyConfig-->>Container: 创建 AnnotationTransactionAttributeSource Bean
    Container->>ProxyConfig: 调用 transactionInterceptor()
    ProxyConfig->>Container: 获取TransactionAttributeSource
    ProxyConfig-->>Container: 创建 TransactionInterceptor Bean
    Container->>ProxyConfig: 调用 beanFactoryTransactionAttributeSourceAdvisor()
    ProxyConfig->>Container: 获取TransactionAttributeSource
    ProxyConfig-->>Container: 创建 BeanFactoryTransactionAttributeSourceAdvisor Bean
    
    Note over Container: 基础设施Bean (TransactionAttributeSource, TransactionInterceptor, Advisor) 装配完毕

序列图 1.1：@EnableTransactionManagement 启动与核心基础设施装配序列图

• 参与者说明：

  • 开发者应用：包含 @EnableTransactionManagement 注解的 Spring 应用，触发整个流程。
  • ConfigurationClassParser：Spring 内部的配置类解析器，负责处理 @Import、@Bean 等注解。
  • TransactionManagementConfigurationSelector：根据 mode 属性，决定注册哪个具体的配置类。
  • ProxyTransactionManagementConfiguration：mode 为 PROXY 时选中的代理模式配置类，内部通过 @Bean 方法定义了三员大将。
  • Spring IoC容器：所有 Bean 的归宿，负责生命周期的管理。

• 交互流程：流程严格遵循 Spring 容器的初始化过程。首先由 ConfigurationClassParser 发现并处理 @EnableTransactionManagement 上的 @Import 注解。它委托给 TransactionManagementConfigurationSelector 来决策。该 Selector 根据注解的 mode 属性（此处为默认的 PROXY）返回 ProxyTransactionManagementConfiguration 并将其作为一个配置类注册。随后，Spring 容器执行该配置类中所有的 @Bean 工厂方法，依次创建并注册 AnnotationTransactionAttributeSource、TransactionInterceptor 和 BeanFactoryTransactionAttributeSourceAdvisor 这三个核心 Bean。

• 关键决策点：流程图中唯一的决策点在于 TransactionManagementConfigurationSelector 对 mode 的判断。AdviceMode.PROXY 引入 ProxyTransactionManagementConfiguration，这会创建基于 JDK 动态代理或 CGLIB 的 AOP 基础设施。而 AdviceMode.ASPECTJ 则会引入 AspectJTransactionManagementConfiguration，它依赖于 AspectJ 编译期或类加载期织入技术，完全绕过 Spring AOP 的代理模型。这个选择从根本上决定了事务拦截的实现方式与限制。

• 设计意图：@Import + ImportSelector 的组合是 Spring 模块化装配的典范。它将“启用某个功能”这一逻辑与“如何装配该功能所需的 Bean”的解耦，使得 @EnableTransactionManagement 异常简洁。用户只需知道这个注解是开关，而无需关心背后复杂的 @Bean 定义。同时，mode 属性提供了代理模式与 AspectJ 模式的切换能力，在易用性与性能/灵活性之间提供了选择空间，尽管绝大多数场景使用的是默认的代理模式。

ProxyTransactionManagementConfiguration 是这一系列装配的核心，它是一个标准的 @Configuration 类，内部定义了三个关键的 Bean。

// org.springframework.transaction.annotation.ProxyTransactionManagementConfiguration
@Configuration(proxyBeanMethods = false)
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class ProxyTransactionManagementConfiguration extends AbstractTransactionManagementConfiguration {

	// 1. 注册 TransactionAttributeSource，负责解析 @Transactional 注解
	@Bean(name = TransactionManagementConfigUtils.TRANSACTION_ATTRIBUTE_SOURCE_BEAN_NAME)
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	public TransactionAttributeSource transactionAttributeSource() {
		return new AnnotationTransactionAttributeSource();
	}

	// 2. 注册 TransactionInterceptor，事务的核心拦截器
	@Bean(name = TransactionManagementConfigUtils.TRANSACTION_INTERCEPTOR_BEAN_NAME)
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	public TransactionInterceptor transactionInterceptor(
			TransactionAttributeSource transactionAttributeSource) {
		TransactionInterceptor interceptor = new TransactionInterceptor();
		interceptor.setTransactionAttributeSource(transactionAttributeSource);
		// 如果容器中有自定义的TransactionManager，则设置，否则后续按类型获取
		if (this.txManager != null) {
			interceptor.setTransactionManager(this.txManager);
		}
		return interceptor;
	}

	// 3. 注册 Advisor，将拦截逻辑应用于匹配的Bean
	@Bean(name = TransactionManagementConfigUtils.TRANSACTION_ADVISOR_BEAN_NAME)
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	public BeanFactoryTransactionAttributeSourceAdvisor transactionAdvisor(
			TransactionAttributeSource transactionAttributeSource,
			TransactionInterceptor transactionInterceptor) {
		BeanFactoryTransactionAttributeSourceAdvisor advisor = new BeanFactoryTransactionAttributeSourceAdvisor();
		advisor.setTransactionAttributeSource(transactionAttributeSource);
		advisor.setAdvice(transactionInterceptor);
		if (this.enableTx != null) {
			advisor.setOrder(this.enableTx.<Integer>getNumber("order"));
		}
		return advisor;
	}
}

源码解读：

1. AnnotationTransactionAttributeSource：这是 TransactionAttributeSource 的一个关键实现。它内部组合了多个 TransactionAnnotationParser，用于解析不同类型的注解。其中最重要的就是 SpringTransactionAnnotationParser，专门用于处理 @Transactional 注解。这个 Bean 在第 2 节会详细展开。
2. TransactionInterceptor：这是事务增强（Advice）的具体实现，它实现了 MethodInterceptor 接口。它持有一个 TransactionAttributeSource 引用，用于获取方法上的事务属性；并持有一个可选的 PlatformTransactionManager 引用，如果未指定，则在运行时按类型从容器中查找。其核心 invoke 方法，是第 3 节剖析的重点。
3. BeanFactoryTransactionAttributeSourceAdvisor：这是一个 Advisor，用于将 Advice（TransactionInterceptor）和 Pointcut（由 TransactionAttributeSource 提供）结合起来。它的 Pointcut 是一个 TransactionAttributeSourcePointcut，内部判断一个方法是否匹配，就是通过 TransactionAttributeSource.getTransactionAttribute(method, targetClass) 是否返回非 null。这意味着，任何被 @Transactional 注解标记的类或方法，其方法调用都会被这个 Advisor 捕获。

至此，声明式事务的所有基础设施 Bean 都已注册到 IoC 容器中，它们静静地等待着在 Bean 的创建过程中，通过 AOP 机制发挥作用（见第 4 节）。

2. @Transactional 注解元数据的提取与存储

当 AOP 框架判断一个方法需要被事务拦截时，它需要知道具体的事务配置——传播行为、隔离级别、超时等等。这些信息都来源于 @Transactional 注解，而 AnnotationTransactionAttributeSource 及其内部的 SpringTransactionAnnotationParser 就是完成注解到 TransactionAttribute 对象转换的核心。

// org.springframework.transaction.annotation.SpringTransactionAnnotationParser
@Override
public TransactionAttribute parseTransactionAnnotation(AnnotatedElement element) {
	// 1. 查找 @Transactional 注解
	AnnotationAttributes attributes = AnnotatedElementUtils.findMergedAnnotationAttributes(
			element, Transactional.class, false, false);
	if (attributes != null) {
		return parseTransactionAnnotation(attributes);
	}
	return null;
}

protected TransactionAttribute parseTransactionAnnotation(AnnotationAttributes attributes) {
	// 2. 创建一个 RuleBasedTransactionAttribute 实例
	RuleBasedTransactionAttribute rbta = new RuleBasedTransactionAttribute();

	// 3. 解析并设置传播行为
	Propagation propagation = attributes.getEnum("propagation");
	rbta.setPropagationBehavior(propagation.value());
    // 4. 解析并设置隔离级别
	Isolation isolation = attributes.getEnum("isolation");
	rbta.setIsolationLevel(isolation.value());
    // 5. 解析并设置超时
	rbta.setTimeout(attributes.getNumber("timeout").intValue());
	// 6. 解析并设置只读
	rbta.setReadOnly(attributes.getBoolean("readOnly"));
	// 7. 解析并设置限定的事务管理器
	rbta.setQualifier(attributes.getString("value"));
	rbta.setQualifier(attributes.getString("transactionManager"));

	// 8. 解析 rollbackFor 和 noRollbackFor，并构建回滚规则
	List<RollbackRuleAttribute> rollbackRules = new ArrayList<>();
	for (Class<?> rbRule : attributes.getClassArray("rollbackFor")) {
		rollbackRules.add(new RollbackRuleAttribute(rbRule));
	}
	for (String rbRule : attributes.getStringArray("rollbackForClassName")) {
		rollbackRules.add(new RollbackRuleAttribute(rbRule));
	}
	for (Class<?> rbRule : attributes.getClassArray("noRollbackFor")) {
		rollbackRules.add(new NoRollbackRuleAttribute(rbRule));
	}
	for (String rbRule : attributes.getStringArray("noRollbackForClassName")) {
		rollbackRules.add(new NoRollbackRuleAttribute(rbRule));
	}
	rbta.setRollbackRules(rollbackRules);

	return rbta;
}

源码解读：

• AnnotatedElementUtils.findMergedAnnotationAttributes：Spring 注解编程的利器，它不仅能在当前元素（类或方法）上查找 @Transactional，还能处理组合注解（被 @Transactional 标记的注解）和父类/接口方法上的注解。这意味着如果方法上没有注解，它会向上查找类上的，甚至层层递归到父类的方法上。这是理解后续失效场景中“注解继承”问题的基础。
• RuleBasedTransactionAttribute：它是 TransactionAttribute 的默认实现，继承自 DefaultTransactionAttribute，并额外增加了 rollbackRules 属性。这个规则列表决定了哪些异常应该导致回滚。
• 解析过程：解析器将注解中的每一个属性，原封不动地映射为 RuleBasedTransactionAttribute 对象的属性。rollbackFor 和 noRollbackFor 被解析为一组 RollbackRuleAttribute 对象，这些对象内部通过完全类名匹配来判断一个异常是否命中规则。这是发生“异常类型不匹配导致不回滚”问题的核心根源。

解析出的 TransactionAttribute 对象并不是每次调用方法都重新解析。AnnotationTransactionAttributeSource 内部维护了一个基于 Class<?> 和 Method 的缓存 Map，避免了重复反射解析的开销。

3. 事务拦截器 TransactionInterceptor 源码拆解

TransactionInterceptor 是整个声明式事务的执行引擎。它实现了 MethodInterceptor 接口，是 AOP 环绕通知（Around Advice）的经典实现。其所有事务逻辑都封装在 invoke(MethodInvocation invocation) 方法中，该方法转调了父类 TransactionAspectSupport 的 invokeWithinTransaction 方法。

我们将通过一个序列图，直观地展示一次被 @Transactional 标记的方法调用，是如何在 TransactionInterceptor 的调度下，与 PlatformTransactionManager 协同工作的。

sequenceDiagram
    participant Caller as 调用者(代理对象)
    participant TI as TransactionInterceptor
    participant TAS as TransactionAspectSupport
    participant TASource as TransactionAttributeSource
    participant TM as PlatformTransactionManager
    participant TS as TransactionStatus
    participant Target as 目标对象
    participant TSM as TransactionSynchronizationManager

    Caller->>TI: invoke(MethodInvocation)
    TI->>TAS: invokeWithinTransaction(..)
    
    Note over TAS: 1. 获取事务元数据
    TAS->>TASource: getTransactionAttribute(method, targetClass)
    TASource-->>TAS: 返回 TransactionAttribute

    Note over TAS: 2. 确定事务管理器
    TAS->>TAS: determineTransactionManager(attribute)
    
    Note over TAS: 3. 创建事务 (如果需要)
    alt 传播行为是 REQUIRED, REQUIRES_NEW 等
        TAS->>TM: getTransaction(attribute)
        TM->>TSM: 将资源(Connection)绑定到ThreadLocal
        TM-->>TAS: 返回 TransactionStatus (newTransaction=true)
    else 传播行为是 SUPPORTS, NOT_SUPPORTED 等
        TAS-->>TAS: 无事务或使用空事务
    end

    Note over TAS: 4. 执行目标方法
    TAS->>Target: invocation.proceed()
    
    Target-->>TAS: 正常返回 或 抛出 Throwable
    
    alt 方法执行正常返回
        Note over TAS: 5. 提交事务
        TAS->>TM: commit(transactionStatus)
    else 方法抛出异常
        Note over TAS: 5. 回滚或提交事务
        TAS->>TAS: ruleBasedAttribute.rollbackOn(exception)
        TAS->>TM: rollback(transactionStatus)
        TAS->>TAS: 重新抛出原始异常
    end
    TAS-->>TI: 返回方法执行结果或异常

序列图 3.1：TransactionInterceptor 执行与事务生命周期序列图

• 参与者说明：

  • 调用者(代理对象)：持有目标对象代理的调用方，其调用首先被 AOP 代理拦截。
  • TransactionInterceptor/TAS：事务拦截器和它的父类 TransactionAspectSupport，是事务逻辑的核心载体。
  • TransactionAttributeSource：提供方法所需事务属性的元数据中心。
  • PlatformTransactionManager：事务管理器的抽象，真正执行事务的创建、提交、回滚操作。
  • TransactionStatus：代表当前事务的状态，由 getTransaction() 创建。
  • 目标对象：被拦截的真正执行业务逻辑的对象。
  • TransactionSynchronizationManager：线程绑定的事务资源管理器（详见前文）。

• 交互流程：整个流程是一场精密编排的协奏。调用开始于代理对象对 TransactionInterceptor 的 invoke 方法调用。拦截器首先从 TransactionAttributeSource 获取该方法的 TransactionAttribute 元数据。接着，它根据此元数据确定要使用的 PlatformTransactionManager。之后是关键的 getTransaction() 调用，它根据事务属性中的传播行为，决定是创建一个新事务、加入现有事务还是无事务执行。方法执行后，根据执行结果（成功或抛出的异常类型），TransactionInterceptor 调用 commit() 或 rollback() 来完结事务。最后，它会将异常或返回值原样传递给调用者。

• 关键决策点：流程图中有两个核心决策点。

  1. 事务获取 (getTransaction)：这个步骤并非总是创建新事务。它实际上是调用 AbstractPlatformTransactionManager.getTransaction()，其内部会根据 TransactionDefinition 的传播行为（REQUIRED, REQUIRES_NEW, NESTED 等）进行复杂的状态判断，逻辑已在第 3 篇详述。
  2. 异常回滚判断 (rollbackOn)：这是最易被误解的决策点。方法执行后如果抛出异常，拦截器不会无条件回滚。它会调用 RuleBasedTransactionAttribute.rollbackOn(Throwable ex) 方法，将抛出的异常与配置的回滚规则进行匹配。只有匹配成功，才会触发 rollback()。这是 15 个失效场景中多个场景的根本原因。

• 设计意图：TransactionAspectSupport.invokeWithinTransaction 采用了模板方法模式（Template Method Pattern）。它将“获取事务 -> 执行方法 -> 完成事务”这个固定骨架定义好，而将具体的“获取/提交/回滚事务”的细节委托给 PlatformTransactionManager 接口。TransactionInterceptor 只是这个骨架的一个具体调用者。这种设计使得事务框架与具体的事务管理器实现（JDBC, Hibernate, JTA）完全解耦，是 Spring 事务管理灵活性的基石。

下面是其源代码骨架，我们剔除部分细节，聚焦核心流程。

// org.springframework.transaction.interceptor.TransactionAspectSupport
@Nullable
protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
		final InvocationCallback invocation) throws Throwable {

	// 1. 获取事务属性源，并尝试获取当前方法的事务属性
	TransactionAttributeSource tas = getTransactionAttributeSource();
	final TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);

	// 2. 确定要使用的事务管理器
	final TransactionManager tm = determineTransactionManager(txAttr);
    
    // ... 处理响应式事务管理器部分忽略 ...

    // 3. 将 PlatformTransactionManager 转为具体类型
	PlatformTransactionManager ptm = asPlatformTransactionManager(tm);
	final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);

    // 4. 核心事务执行路径（区分声明式事务与编程式事务）
	if (txAttr == null || !(ptm instanceof CallbackPreferringPlatformTransactionManager)) {
		// 4.1 标准声明式事务路径
		TransactionInfo txInfo = createTransactionIfNecessary(ptm, txAttr, joinpointIdentification);

		Object retVal;
		try {
			// 4.2 执行目标方法，这里是真正的业务逻辑
			retVal = invocation.proceedWithInvocation();
		}
		catch (Throwable ex) {
			// 4.3 异常处理：根据事务属性判断是否需要回滚
			completeTransactionAfterThrowing(txInfo, ex);
			throw ex; // 重新抛出原始异常
		}
		finally {
			// 4.4 清理线程绑定的当前事务信息
			cleanupTransactionInfo(txInfo);
		}
        // ... 处理其他情况 ...
        
		// 4.5 一切正常，提交事务
		commitTransactionAfterReturning(txInfo);
		return retVal;
	}
    // ... 处理 CallbackPreferringPlatformTransactionManager 等编程式事务路径 ...
}

源码解读：

• createTransactionIfNecessary：这是第3篇中详细讲解过的逻辑，它会调用 ptm.getTransaction(txAttr)，根据传播行为创建或加入事务，并返回一个 TransactionInfo 对象，该对象封装了 TransactionStatus 和旧的事务信息（用于恢复）。
• invocation.proceedWithInvocation()：这行代码是整个机制的点睛之笔。它是调用目标业务方法的入口。在此之前，事务已经开启（或加入）；在此之后，是提交或回滚的逻辑。这种环绕式的设计，完美地实现了事务管理逻辑与业务逻辑的分离。
• completeTransactionAfterThrowing：当业务方法抛出异常时，此方法被调用。其内部核心是调用 txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus())，但在调用之前，有一个关键的判断逻辑：

  // TransactionAspectSupport
  protected void completeTransactionAfterThrowing(@Nullable TransactionInfo txInfo, Throwable ex) {
       if (txInfo != null && txInfo.getTransactionStatus() != null) {
           // ...
           // 检查 TransactionAttribute.rollbackOn(ex)
           if (txInfo.transactionAttribute != null && txInfo.transactionAttribute.rollbackOn(ex)) {
               try {
                   txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
               } catch (TransactionSystemException ex2) { /*...*/ }
           } else {
               // 我们不想回滚这个异常，但在异常抛出前，我们可能仍想让事务继续并提交
               try {
                   txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
               } catch (TransactionSystemException ex2) { /*...*/ }
           }
       }
   }
  

  这段代码清晰地表明，事务是否回滚，完全由 txAttr.rollbackOn(ex) 的返回值决定，也就是由我们在第 2 节中解析出的回滚规则决定。

4. 与 AOP 的整合：代理创建、拦截链与事务 Advisor

TransactionInterceptor 作为增强（Advice），最终需要通过 AOP 机制被应用到目标 Bean 上。这个整合过程的核心是 BeanFactoryTransactionAttributeSourceAdvisor。

当 Spring 容器创建 Bean 时，AbstractAutoProxyCreator （具体实现如 InfrastructureAdvisorAutoProxyCreator）会检查所有注册的 Advisor。BeanFactoryTransactionAttributeSourceAdvisor 作为基础设施 Advisor 也在被检查之列。

它的 Pointcut 是 TransactionAttributeSourcePointcut，其核心方法是：

// org.springframework.transaction.interceptor.TransactionAttributeSourcePointcut
@Override
public boolean matches(Method method, Class<?> targetClass) {
    // ...
    TransactionAttributeSource tas = getTransactionAttributeSource();
    // 关键：如果 TransactionAttributeSource 能从方法或类上找到 TransactionAttribute
    // 则说明该方法或类被 @Transactional 标记，因此匹配成功。
    return (tas == null || tas.getTransactionAttribute(method, targetClass) != null);
}

源码解读：这个 matches 逻辑极为简洁和关键。它复用了第 2 节中介绍的 TransactionAttributeSource。如果一个方法或它所在的类被 @Transactional 标记，getTransactionAttribute 就会返回一个非 null 的 TransactionAttribute 对象，从而使得该 Pointcut 匹配成功。匹配成功后，TransactionInterceptor（Advisor 中的 Advice）就会被加入到该 Bean 的拦截器链中。

代理类型的影响：

• JDK 动态代理：当目标对象实现了至少一个接口，并且 proxyTargetClass 为 false（默认值），Spring 会使用 JDK 动态代理。代理对象是一个实现了相同接口的新对象。如果调用方通过接口引用目标对象，事务会生效。但如果通过 @Autowired 注入的是实现类本身，并且在类内部发生“自调用”，事务将失效。
• CGLIB 代理：当目标对象没有实现接口，或 proxyTargetClass 被显式设置为 true 时，Spring 会使用 CGLIB 创建目标类的子类作为代理。此时，代理对象是目标类的子类。@Autowired 注入实现类引用时，得到的是 CGLIB 代理对象。但“自调用”问题依然存在，因为 this 引用仍然指向原始目标对象，而不是其 CGLIB 代理子类。

这种整合方式也带来一个副作用：如果 Bean 上存在多个 Advisor，如 @Transactional 和 @Cacheable，它们会被组织成一个拦截器链，按顺序执行。事务 Advisor 的顺序可以通过 @EnableTransactionManagement 的 order 属性来控制。

5. 失效案例全景分析（15个场景详细剖析）

@Transactional 的强大与脆弱并存。强大的地方在于它将复杂的事务管理隐藏在了一个简单的注解之后；脆弱的地方在于，一旦开发者对这个注解背后的 AOP、Spring 容器和数据库机制理解不足，就极易“踩坑”。以下我们将对 15 个典型失效场景进行源码级剖析。

5.1 自调用失效（this 调用绕过代理）

• 失效原理（结合源码）：Spring 事务管理基于 AOP 代理。当我们从外部调用类的一个公共方法时，调用的是 Spring 创建的代理对象。但如果在类内部，方法 A 通过 this.methodB() 调用方法 B，这里的 this 指的是原始的目标对象，而不是包装了 TransactionInterceptor 的代理对象。因此，方法 B 上的 @Transactional 注解根本不会被代理逻辑看到，事务也就无从开启。

flowchart TD
    subgraph CallerGroup ["调用者"]
        Caller["外部调用者"]
    end

    subgraph SpringContainer ["Spring容器"]
        Proxy["代理对象<br/>(JDK/CGLIB)"]
        Target["原始目标对象"]
        NoteNode["methodB()上的@Transactional失效！"]
    end

    Caller -->|"1. 调用 methodA()"| Proxy
    Proxy -->|"2. 事务拦截器处理"| Proxy
    Proxy -->|"3. 调用目标对象.methodA()"| Target
    Target -->|"4. this.methodB()<br/>直接调用，绕过代理"| Target
    
    NoteNode -.- Target

    classDef default fill:#f8f9fa,stroke:#333,stroke-width:1px,color:#333;
    classDef note fill:#ffebee,stroke:#b71c1c,stroke-width:2px,color:#333;
    class NoteNode note;

流程图 5.1：自调用绕过AOP代理示意图

• 图表说明：

  • 节点定义：外部调用者是Spring容器之外的代码，代理对象是Spring AOP创建的包裹器，原始目标对象是包含业务逻辑的Bean实例自身。
  • 调用路径：关键路径在于步骤4。当目标对象的methodA内部使用this.methodB()时，这个调用是一个Java语言级别的直接方法调用，它完全在原始目标对象内部完成，不会经过代理对象。因此，代理对象上所有为methodB准备的TransactionInterceptor等增强逻辑都不会被执行。
  • 根本差异：代理对象和原始对象是两个不同的实例。代理对象持有对原始对象的引用，并能在其方法调用前后插入增强逻辑。而this引用始终指向当前对象实例，在方法内部它就是原始对象，与代理对象毫无关系。
  • 问题本质：@Transactional并非方法级别的字节码增强，而是通过AOP代理在对象级别进行拦截。自调用这种“内部通信”天然地逃逸了代理的拦截范围。

• 错误示例：

  @Service
  public class OrderService {
      @Transactional
      public void placeOrder() {
          // ... 一些逻辑
          this.updateInventory(); // 自调用，事务失效！
      }
  
      @Transactional(propagation = Propagation.REQUIRES_NEW)
      public void updateInventory() {
          // ... 扣减库存逻辑
      }
  }
  

• 现象：updateInventory() 方法上的 @Transactional(propagation = Propagation.REQUIRES_NEW) 失效，它不会挂起外部事务并开启新事务，而是直接参与到 placeOrder() 的事务中。

• 正确示例：核心思想是获取代理对象进行调用。

  @Service
  public class OrderService {
      @Transactional
      public void placeOrder() {
          // ... 一些逻辑
          // 方案一：通过 AopContext.currentProxy() 获取当前代理对象
          ((OrderService) AopContext.currentProxy()).updateInventory();
      }
  
      @Transactional(propagation = Propagation.REQUIRES_NEW)
      public void updateInventory() {
          // ... 扣减库存逻辑
      }
  }
  // 需要在配置类上开启暴露代理，如 @EnableAspectJAutoProxy(exposeProxy = true)
  

• 最佳实践：

  • 优先考虑重构：将 updateInventory() 拆分到另一个 Service 中，通过依赖注入的方式调用。这是最自然、耦合度最低的解决方案。
  • 开启 exposeProxy：在配置类上加上 @EnableAspectJAutoProxy(exposeProxy = true)（Spring Boot 中也可通过 spring.aop.proxy-target-class=true 和 spring.aop.expose-proxy=true 配置）。然后通过 AopContext.currentProxy() 获取代理对象。此方法会轻微增加性能开销，并引入了代码对 Spring 框架 API 的显式依赖。

5.2 非 public 方法失效

• 失效原理（结合源码）：AbstractFallbackTransactionAttributeSource 在对一个方法进行解析以提取 TransactionAttribute 时，有一个 allowPublicMethodsOnly() 的判断逻辑。

  // org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource
  protected TransactionAttribute computeTransactionAttribute(Method method, @Nullable Class<?> targetClass) {
       // allowPublicMethodsOnly 方法默认返回 true
       if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
           return null;
       }
       // ... 其他逻辑
   }
  

  在 AnnotationTransactionAttributeSource 中，allowPublicMethodsOnly() 方法的默认实现是返回 true。这意味着，如果一个方法是包级别可见、protected 或 private，框架将直接返回 null，即视为没有事务属性。

• 错误示例：

  @Service
  public class MyService {
      @Transactional
      private void internalTransfer() { // 错误：private方法，事务不生效
          // ...
      }
  }
  

• 现象：方法在调用时不会创建事务，就像 @Transactional 注解不存在一样。

• 正确示例：

  @Service
  public class MyService {
      @Transactional
      public void publicTransfer() { // 正确：改为public方法
          // ...
      }
  }
  

• 最佳实践：牢记 Spring 声明式事务的默认约定——它只会应用于 public 方法。如果确实需要在非 public 方法中进行事务控制，要么将其改为 public，要么切换到 AspectJ 模式，AspectJ 织入是基于字节码的，没有此限制。

5.3 默认回滚异常不匹配（checked 异常不回滚）

• 失效原理（结合源码）：这是最常见的问题之一。在第 3 节中，我们看到回滚决策取决于 RuleBasedTransactionAttribute.rollbackOn(Throwable ex)。

  // org.springframework.transaction.interceptor.RuleBasedTransactionAttribute
  @Override
  public boolean rollbackOn(Throwable ex) {
      // ...
      RollbackRuleAttribute winner = null;
      int deepest = Integer.MAX_VALUE;
  
      if (this.rollbackRules != null) {
          for (RollbackRuleAttribute rule : this.rollbackRules) {
              int depth = rule.getDepth(ex);
              if (depth >= 0 && depth < deepest) {
                  deepest = depth;
                  winner = rule;
              }
          }
      }
      // 如果没有找到任何回滚规则，或者找到了最匹配的规则
      if (winner == null) {
           // 无匹配规则时，走父类的默认逻辑
           return super.rollbackOn(ex);
       }
       return !(winner instanceof NoRollbackRuleAttribute);
  }
  
  // org.springframework.transaction.interceptor.DefaultTransactionAttribute
  @Override
  public boolean rollbackOn(Throwable ex) {
      // 父类默认逻辑：只有 RuntimeException 及其子类，或者 Error 才回滚
      return (ex instanceof RuntimeException || ex instanceof Error);
  }
  

  源码解读：如果 @Transactional 没有配置 rollbackFor，那么 rollbackRules 为空，最终会执行父类 DefaultTransactionAttribute 的默认逻辑：只对运行时异常（RuntimeException）和 Error 进行回滚。如果业务方法抛出了受检异常（如 IOException、自定义业务异常），即使它被抛出到代理逻辑，事务仍会正常提交。

sequenceDiagram
    participant Target as 目标方法
    participant TI as TransactionInterceptor
    participant RTA as RuleBasedTransactionAttribute
    participant DTA as DefaultTransactionAttribute
    participant TM as PlatformTransactionManager

    Target->>TI: 抛出SQLException (受检异常)
    TI->>RTA: rollbackOn(SQLException)
    RTA->>RTA: 遍历rollbackRules，无匹配
    RTA->>DTA: 无规则，委托给 super.rollbackOn()
    DTA->>DTA: 判断ex instanceof RuntimeException?<br/>SQLException 不是RuntimeException
    DTA-->>RTA: 返回 false
    RTA-->>TI: 返回 false，不回滚
    TI->>TM: commit(transactionStatus)
    Note over TM,Target: 业务预期应该回滚的事务被提交了！

序列图 5.3：受检异常默认不回滚的决策流程

• 参与者说明：目标方法是抛出异常的源头；TransactionInterceptor拦截到异常并启动决策；RuleBasedTransactionAttribute和DefaultTransactionAttribute组成决策链；PlatformTransactionManager是最终的事务执行者。

• 交互流程：当业务抛出受检异常（如SQLException），TransactionInterceptor开始异常处理流程。它首先调用RuleBasedTransactionAttribute的rollbackOn方法。由于没有配置rollbackFor，内部的rollbackRules列表为空，寻找匹配规则的尝试失败，于是该方法将决策权委托给父类DefaultTransactionAttribute。父类通过instanceof进行简单判断，发现该异常既非RuntimeException也非Error，便返回false。TransactionInterceptor基于这个false决策，执行了commit操作，导致异常被抛出但事务却未回滚的严重后果。

• 关键决策点：核心在于DefaultTransactionAttribute.rollbackOn()方法中那行简单的instanceof判断。它是Spring框架层的一个约定，而非从技术上试图分析所有可能的异常类型。这种“保守”的设计，将所有非RuntimeException的异常（主要是受检异常）的回滚决定权显式地交还给了开发者。

• 设计意图：这种设计有其历史渊源和哲学考量。受检异常在Java语义中常被用于表示一种“可预见并可恢复”的情况，例如文件未找到、网络连接超时等。框架设计者认为这类异常不必然意味着业务逻辑的整体失败，因此不应默认强制回滚事务。但这往往与开发者的直觉（“抛异常就意味着失败，就该回滚”）相悖，因此导致大量使用事故。

• 错误示例：

  @Service
  public class OrderService {
      @Transactional
      public void placeOrder() throws Exception {
          // ... 数据库操作
          throw new Exception("订单创建失败"); // 抛出普通Exception
      }
  }
  

• 现象：抛出异常，但数据库中数据未被回滚。

• 正确示例：

  @Service
  public class OrderService {
      @Transactional(rollbackFor = Exception.class) // 或定义具体的业务异常类
      public void placeOrder() throws Exception {
          // ... 数据库操作
          throw new Exception("订单创建失败");
      }
  }
  

• 最佳实践：永远明确指定 rollbackFor。即使是自定义的运行时异常，显式指定也能增强代码的可读性和明确性。实践中，最稳妥的方式是使用 @Transactional(rollbackFor = Throwable.class)，但需注意这可能导致某些不必回滚的 Error（如 NoSuchMethodError）也触发回滚，所以更精细地控制异常类型是更好的选择。

5.4 try-catch 吞异常失效

• 失效原理：这是第 5.3 节的延伸。如果我们在业务方法内部使用 try-catch 捕获了异常，并且没有在 catch 块里重新抛出，那么对于 TransactionInterceptor 来说，该方法是正常返回的。它不会感知到异常的发生，自然会执行事务提交。

• 错误示例：

  @Service
  public class OrderService {
      @Transactional
      public void placeOrder() {
          try {
              // ... 可能抛出异常的数据库操作
              riskyOperation();
          } catch (Exception e) {
              log.error("An error occurred", e);
              // 吞掉了异常，没有重新抛出！
          }
      }
  }
  

• 现象：riskyOperation() 抛出异常，但由于 try-catch，placeOrder() 方法正常结束，事务提交，数据不一致。

• 正确示例：

  @Service
  public class OrderService {
      @Transactional(rollbackFor = Exception.class)
      public void placeOrder() {
          // 方案1: 不在外围捕获，让异常传播
          riskyOperation();
          
          // 方案2: 捕获后，记录日志并重新抛出（或转换为运行时异常）
          try {
              riskyOperation();
          } catch (Exception e) {
              log.error("Operation failed, triggering rollback.", e);
              throw e; // 或者 throw new RuntimeException(e);
          }
          
          // 方案3: 编程式回滚（不推荐）
          try {
              riskyOperation();
          } catch (Exception e) {
              log.error("Operation failed, manually setting rollback.", e);
              TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
          }
      }
  }
  

• 最佳实践：绝不轻易吞噬异常。如果必须捕获，在 catch 块中必须明确是否要回滚事务。若要回滚，必须重新抛出异常（哪怕是包装成运行时异常）或通过编程式方式设置 setRollbackOnly。

5.5 传播行为 REQUIRES_NEW 在内嵌调用中的事务独立性问题

这并非严格意义上的“失效”，而是开发者对REQUIRES_NEW行为的误解导致的“预期不符”。

• 失效原理：REQUIRES_NEW 的语义是：始终创建一个新的事务，并且如果当前已存在事务，则将其挂起。在 5.1 节中，我们通过 this.updateInventory() 调用时，因为自调用绕过了代理，REQUIRES_NEW 根本就没有机会被执行。即使解决了自调用问题，两个事务也是完全独立的。如果 placeOrder() 方法随后失败回滚，updateInventory() 所开启的新事务已经提交，无法回滚。这可能导致数据不一致。它的生命周期是完全独立的，不会受到外部事务回滚的影响。

sequenceDiagram
    participant OP as placeOrder()事务
    participant UI as updateInventory()事务
    participant DB as 数据库

    Note over OP: 事务开始
    OP->>DB: INSERT INTO orders ...

    Note over UI: 挂起 placeOrder 事务，<br/>开启 REQUIRES_NEW 事务
    UI->>DB: UPDATE inventory SET count = count - 1 ...
    Note over UI: 事务提交，数据持久化
    Note over OP: 恢复 placeOrder 事务

    OP->>OP: 发生错误，抛出异常！
    OP->>DB: ROLLBACK orders 表的INSERT...
    Note over OP: placeOrder 事务回滚
    
    Note over DB: 最终结果：订单回滚，但库存已扣减<br>（库存的 REQUIRES_NEW 事务已独立提交）

序列图 5.5：REQUIRES_NEW 引发的数据不一致问题

• 参与者说明：placeOrder()和updateInventory()分别代表两个独立的事务边界。

• 交互流程：placeOrder()首先开启事务执行。当执行到updateInventory()时，由于配置了REQUIRES_NEW，placeOrder()的事务被暂时挂起。updateInventory()开启了一个全新的、独立的事务，完成操作后立即提交，数据被持久化。随后，控制权交还给被恢复的placeOrder()事务。如果placeOrder()后续因故失败并回滚，已提交的updateInventory()的操作不会受到任何影响。

• 关键决策点：getTransaction()方法（见第3篇）识别出REQUIRES_NEW传播行为后，会决定挂起当前事务并创建新事务。这个“挂起”动作是关键，它切断了两个事务间的物理联系，使得它们各自拥有独立的JDBC连接和生命周期。

• 设计意图：REQUIRES_NEW适用于完全不相关的业务操作，比如在核心业务流程中记录审计日志。日志的写入成功与否不应影响核心业务，反之亦然。如果将其用于强一致性的业务场景（如示例中的订单与库存），就会引入严重的数据不一致风险。这并非Spring的Bug，而是对分布式事务原理理解不足导致的架构设计失误。

• 正确示例与最佳实践：在需要保证数据一致性的强相关操作中（如订单与库存），应使用 REQUIRED 传播行为，将它们绑定在同一个事务中。对于确实需要独立事务的审计日志等场景，才使用 REQUIRES_NEW，并需在架构层面接受其最终一致性或数据不一致的风险。

5.6 多线程环境下事务失效

• 失效原理（结合源码）：Spring 事务管理通过 TransactionSynchronizationManager 将事务资源（如数据库连接）绑定到当前线程的 ThreadLocal 中，以实现事务的传播与隔离。这意味着一个 Spring 事务天然是单线程的。如果在 @Transactional 方法内部启动新线程去执行数据库操作，新线程将无法从原始线程的 ThreadLocal 中获取到事务资源，因此会创建一个全新的、独立的事务（如果新线程的方法上也标记了 @Transactional）。

sequenceDiagram
    participant Main as 主线程
    participant Worker as 新工作线程
    participant TSM_Main as ThreadLocal (Main)
    participant TSM_Worker as ThreadLocal (Worker)    
    participant DB as 数据库

    Main->>TSM_Main: getTransaction() <br/> 绑定Connection-1
    Note over Main: 主线程事务开始

    Main->>Worker: 启动新线程执行DB操作
    Worker->>TSM_Worker: getTransaction() <br/> 获取新事务 <br/> 绑定Connection-2
    Note over Worker: 工作线程独立事务开始
    Worker->>DB: SQL操作 (使用Connection-2)
    Worker->>Worker: 成功/失败，提交/回滚 <br/> (使用Connection-2)
    
    Worker-->>Main: 线程执行完毕

    Main->>Main: 发生异常！
    Main->>DB: ROLLBACK (使用Connection-1)
    Note over DB: 最终结果：主线程事务回滚，<br/>但工作线程操作已独立提交/回滚

序列图 5.6：多线程环境下的事务隔离示意图

• 参与者说明：主线程和新工作线程是两个独立的执行单元。TSM_Main和TSM_Worker分别代表它们独有的ThreadLocal变量副本。

• 交互流程：主线程通过TransactionSynchronizationManager将Connection-1绑定到自己的ThreadLocal中。当它启动一个新线程去执行数据库操作时，新线程拥有自己独立的ThreadLocal（TSM_Worker），其中没有任何事务资源。如果新线程内的方法也声明了事务，它将通过getTransaction()获取到一个全新的数据库连接Connection-2，并开始一个完全独立的新事务。这个新事务与主线程中的事务在生命周期、提交/回滚上是彻底分离的。

• 关键决策点：TransactionSynchronizationManager本身不进行任何线程间的数据同步。其内部使用的ThreadLocal机制天然地将数据隔离在各自线程内。因此，没有任何JDBC连接会在线程间共享。

• 设计意图：ThreadLocal的设计初衷就是为了在单线程内共享数据，避免方法间的参数传递污染。Spring事务框架基于此设计，完美地实现了在单线程方法栈中“事务上下文”的自动传播。但这种设计也明确划定了边界：一个事务就是一个线程。跨线程就意味着跨事务。

• 错误示例：

  @Service
  public class OrderService {
      @Transactional
      public void processOrder() {
          // ... 主线程中的订单处理
          new Thread(() -> {
              // 这是另一个线程，这个updateLog方法上的@Transactional是独立的事务
              auditService.updateLog(); 
          }).start();
          // ... 如果这里主线程失败，日志线程的事务已独立提交，不受影响
          throw new RuntimeException("主线程失败");
      }
  }
  

• 最佳实践：

  • 默认禁止：在 @Transactional 方法内部，原则上不应启动新的线程进行数据库写操作。
  • 异步+补偿：如果确实需要异步处理，应接受事务的最终一致性。可以使用 @Async + @Transactional 的组合，但必须明确这个异步操作的事务是独立的。主线程失败后，需要通过消息队列、补偿任务等机制来保证最终的数据一致性。
  • 事务管理器扩展：可以使用支持跨线程事务传播的特殊事务管理器（如 JTA），但这会极大地增加系统复杂度，仅在必要的分布式场景下考虑。

5.7 数据库引擎不支持事务（MyISAM）

• 失效原理：这不是 Spring 的问题，而是数据库本身的限制。
• 现象：MySQL 的 MyISAM 引擎不支持事务。在这样的表上执行操作，即使 Spring 代码层层包裹了事务，数据和操作也是非原子的。commit 和 rollback 命令不会报错，但不会生效。
• 最佳实践：确保业务表使用支持事务的引擎，如 InnoDB。

5.8 同类方法调用代理选择不当

• 失效原理：此场景是 5.1（自调用）和代理机制的结合。假设一个类实现了接口，方法 A 有 @Transactional，方法 B 没有。但在方法 A 内部通过 this.methodB() 调用。此时：
  • 默认情况下，Spring 使用 JDK 动态代理。代理对象只持有对目标对象实现的接口的引用。this 调用是 目标对象 -> 目标对象 的直接调用。
  • 如果我们强制开启 CGLIB 代理（proxyTargetClass = true），代理对象是目标类的子类。但自调用问题依然存在，因为 this 仍然指向原始的目标对象实例，而不是 CGLIB 代理子类对象。
• 最佳实践：再次明确，自调用是 AOP 代理的天敌，与代理类型无关。解决之道仍是重构或使用 AopContext.currentProxy()。

5.9 @Transactional 注解放在 Controller 或非 Spring Bean 上

• 失效原理：
  • Controller 层：@Transactional 通常应放在 Service 层。Spring MVC 的控制器是请求的入口，其方法映射和处理在 Spring 容器内部也是通过代理完成。理论上放在 Controller 上事务能生效。但这违反了分层架构原则——控制器层负责请求解析与视图渲染，事务管理是业务逻辑层（Service）的职责。如果在控制器层开启事务，可能导致 HTTP 请求解析、视图渲染等非业务操作被错误地包裹在事务内，延长事务时间，增加锁争用。
  • 非 Spring Bean：如果类本身没有被 Spring 管理（例如 new 出来的对象），那么它的所有方法调用都不会被 AOP 代理拦截，@Transactional 就是一个普通的 Java 注解，毫无意义。
• 最佳实践：严格遵循分层架构，将 @Transactional 放在 Service 层。确保类被 Spring 管理（典型的是通过 @Service、@Component 等）。

5.10 事务超时未生效的场景

• 失效原理：@Transactional(timeout = 5) 设置的超时时间，最终会传递给 java.sql.Statement.setQueryTimeout(int seconds)。这依赖于 JDBC 驱动的实现。但是，有些场景下超时可能不生效：

  1. 数据库驱动不支持：部分过时或特殊的 JDBC 驱动可能忽略 setQueryTimeout 的设置。
  2. 耗时操作不在 DB 调用上：如果事务超时后，耗时主要发生在 Java 业务逻辑计算上，而非等待数据库响应，那么 setQueryTimeout 是无能为力的。它只控制数据库端的执行时间。
  3. 嵌套事务：在 NESTED 传播行为中，Savepoint 的回滚可以通过超时触发，但这仍然受限于驱动和数据库对 Savepoint 超时的支持。

• 最佳实践：超时控制最好是数据库和 Spring 双重保障。对于纯 Java 代码的耗时，需要另一套监控体系。

5.11 手动管理 JDBC 连接绕过了 Spring 事务

• 失效原理：Spring 事务管理的基石是通过 DataSourceUtils.getConnection(ds) 来获取并绑定连接到当前线程。如果你自行通过 DataSource.getConnection() 获取连接，这个连接是全新的、不受 Spring 管理的连接，其事务行为（commit/rollback）自然也脱离了 Spring 的控制。

• 错误示例：

  @Service
  public class MyService {
      @Autowired private DataSource dataSource;
      
      @Transactional
      public void doSomething() {
          try (Connection conn = dataSource.getConnection()) { // 绕过Spring!
              // ... 执行SQL
              conn.commit(); // 完全自控，不受外部事务影响
          }
      }
  }
  

• 最佳实践：在使用 JdbcTemplate 或 TransactionAwareDataSourceProxy 时，连接管理是透明的，无需手动获取。如果实在需要手动获取连接进行操作，应使用 DataSourceUtils.getConnection(dataSource)，它会返回当前线程绑定的事务连接。

5.12 TransactionTemplate 与 @Transactional 混用边界模糊

• 失效原理：两者都是对 PlatformTransactionManager 的使用抽象。TransactionTemplate 是编程式事务，而 @Transactional 是声明式事务。当它们嵌套使用时，其行为取决于各自的传播属性和 PlatformTransactionManager 的实现。如果在一个 @Transactional(REQUIRED) 的方法内部，使用 TransactionTemplate 并指定 REQUIRES_NEW，它们实际上会共用同一个 PlatformTransactionManager，并会根据规则挂起和恢复事务。一般不会“失效”，但会让代码逻辑变得混乱，难以调试。
• 最佳实践：在整个项目中，要么统一使用编程式事务模板，要么统一使用声明式事务。必须混用时，团队需要有非常清晰的规范，并对它们的交互逻辑有透彻的理解。

5.13 嵌套事务的 savepoint 与回滚

• 失效原理：当传播行为设置为 NESTED 时，内层事务会创建一个 Savepoint。如果内层事务失败回滚，理论上应该只回滚到 Savepoint，而不影响外层事务。但是：
  1. JDBC 驱动/数据库不支持 Savepoint：如某些版本的 MySQL 对 Savepoint 的支持不完善。
  2. 内层方法吞异常：如果内层方法捕获了异常没有抛出，外层事务只会执行到 Savepoint 的提交，而内层方法对数据库的修改可能在逻辑上是错误的。
  3. 外层事务无故回滚：这是一个危险的陷阱。一旦内层事务回滚到 Savepoint，整个事务已经被标记为 rollback-only。即使外层 try-catch 捕获了内层方法的异常，并试图在外层正常提交，最终 AbstractPlatformTransactionManager 的 commit 方法会发现事务状态是 rollback-only，从而抛出一个 UnexpectedRollbackException，外层事务被迫回滚。

5.14 异步方法（@Async）内的事务失效

• 失效原理：这是 5.6（多线程）的一个具体体现。@Async 本质上是将方法执行委托给一个 TaskExecutor，在一个新的线程中运行。如同任何多线程场景，新线程拥有独立的 ThreadLocal，因此无法继承调用者线程中的事务上下文。@Async 方法上的 @Transactional 是完全独立的。
• 最佳实践：在使用 @Async 时，必须清醒地意识到它是异步且独立事务的。不要期望调用者的回滚能影响到异步任务。正确做法是在异步任务中加入自己的失败重试和补偿机制。

5.15 异常抛出类型与 rollbackFor 精确匹配问题

• 失效原理（结合源码）：在第 5.3 节中，我们分析了 RollbackRuleAttribute，它内部的 getDepth 方法是基于 Class.isAssignableFrom() 进行类型匹配的。这意味着它支持多态。rollbackFor = RuntimeException.class 也能匹配 NullPointerException。但失败往往发生在设置了不匹配的异常时，例如：

  @Transactional(rollbackFor = MyBusinessException.class)
  

  而实际上代码抛出的却是 SomeOtherException。这会导致匹配失败，事务提交。
• 最佳实践：在使用 rollbackFor 时，确保其覆盖了你关心的方法所可能抛出的所有需要回滚的异常类型，或者使用更宽泛的异常类型，如 Exception.class 或 Throwable.class，并在团队规范中明确约定。

6. 事务事件与 @TransactionalEventListener 的原理

Spring 的 ApplicationEvent 机制与事务管理可以优雅地结合。@TransactionalEventListener 允许我们在事务的不同阶段（如提交后）执行事件处理逻辑，这对于解耦核心业务与非核心周边逻辑（如发送通知、记录审计日志）有奇效。

其原理基于 TransactionSynchronizationManager 的事务同步回调（见第 3 篇）。TransactionalEventListener 背后注册一个 ApplicationListenerMethodTransactionalAdapter，它实现了 TransactionSynchronization 接口。当事务提交/回滚时，AbstractPlatformTransactionManager 会触发已注册的同步回调，此时事件监听逻辑被执行。

// 发布事件
@Service
public class OrderService {
    @Autowired
    private ApplicationEventPublisher publisher;

    @Transactional
    public void placeOrder(Order order) {
        // ... 保存订单
        publisher.publishEvent(new OrderCreatedEvent(order));
        // 如果此方法成功返回并提交事务，则监听器会执行
    }
}

// 监听事件
@Component
public class NotificationListener {
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handleOrderCreated(OrderCreatedEvent event) {
        // 在这里发送订单创建成功的通知。
        // 此方法执行时，业务事务已经提交，数据已持久化。
    }
}

在失效场景下的行为：

1. 事务回滚：如果 placeOrder() 事务回滚，@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 的监听器不会被触发。这是正确的行为，因为业务已经失败。
2. 操作在事务外：如果没有成立事务（例如传播行为为 NOT_SUPPORTED），并且事件是在 @Transactional 方法外发布的，那么 AFTER_COMMIT 监听器可能永远不会执行，因为它依赖于事务同步机制。此时，事件会默认在当前阶段（AFTER_COMPLETION）执行，但这需要留意。
3. 异步事件与事务：如果事件监听器方法是 @Async 的，它会在新线程中执行，脱离原事务上下文。监听器本身的事务行为由它自己的 @Transactional 注解和异步配置决定。
4. Publisher 在事务外：如果 applicationEventPublisher.publishEvent(...) 被放在事务方法之外，那么 @TransactionalEventListener 就会像一个普通的 @EventListener，因为它无法感知到任何事务的边界。

7. 调试与诊断工具

当出现事务“不工作”的情况时，切勿盲目修改代码，应遵循一套系统化的排查流程。

1. 开启日志：这是第一步也是最有效的一步。将以下日志级别设置为 TRACE：

   # Spring事务管理器决策日志
   logging.level.org.springframework.transaction=TRACE
   # Spring JDBC操作日志，能看到SQL执行和连接获取
   logging.level.org.springframework.jdbc=TRACE
   # 如果使用HikariCP等连接池，开启其trace也能获得连接借用/归还信息
   # logging.level.com.zaxxer.hikari=TRACE
   

   分析：TRACE 级别的 org.springframework.transaction 日志会详细记录 getTransaction、commit、rollback 的每一次调用，以及传播行为的处理、Savepoint 的创建等所有细节。当看到 “Rolling back JDBC transaction on Connection...” 或 “Committing JDBC transaction on Connection...” 时，可以清晰判断事务的最终走向。

2. 检查代理对象：在调试器中，观察你的 Service Bean 到底是什么。它不是 com.example.OrderService 的实例，而是一个 com.example.OrderService$$EnhancerBySpringCGLIB... 或 com.sun.proxy.$Proxy... 的实例。如果不是，说明代理创建失败，@Transactional 基础不成立。

3. 编程式诊断：可以在方法内部使用 TransactionAspectSupport.currentTransactionStatus() 获取当前事务状态，检查其是否为 null、是否是新事务 isNewTransaction()、是否已标记为 isRollbackOnly()。

4. 数据库连接日志：通过 DataSource 代理（如 log4jdbc 或 P6Spy）可以监听到所有 JDBC 调用，包括 setAutoCommit(false)、commit() 和 rollback()。这能帮助我们从数据库驱动层面确认事务指令是否被真正发送。

8. 生产事故排查专题

8.1 事故一：批量订单支付后部分库存未扣减

• 现象：在一个订单支付系统中，payOrder 方法内部循环调用 updateInventory 方法进行库存扣减。偶尔出现支付成功但部分商品库存未扣减的严重数据不一致。
• 排查：
  1. 查看日志，发现支付主事务成功提交，无异常。
  2. 查看 OrderService 代码，发现 payOrder 标记了 @Transactional，updateInventory 也标记了 @Transactional(propagation = Propagation.REQUIRES_NEW)。
  3. 根因：payOrder 方法是通过 this.updateInventory() 调用的，这是典型的自调用。REQUIRES_NEW 根本没有生效，所有扣库存操作和支付操作都运行在同一个大事务中。那么为什么还会“部分扣减”呢？进一步排查库存扣减代码，发现它在循环中做了 try-catch，部分商品的扣减因逻辑校验失败而抛出异常，但被捕获了，没有导致整个大事务回滚，导致支付成功，但失败的库存未扣减。
• 结合源码：此事故同时命中了场景 5.1（自调用） 和场景 5.4（try-catch 吞异常）。
• 解决：重构代码，将 updateInventory 逻辑拆分到独立的 InventoryService 中并通过 @Autowired 注入调用，同时去除不必要的 try-catch 或者捕获后明确重新抛出异常。
• 最佳实践：避免循环中的 REQUIRES_NEW 自调用。对于此类批量操作，应考虑使用批量处理或异步化，但要设计好补偿机制。

8.2 事故二：定时任务数据库操作全部失败却不报错

• 现象：一个基于 Spring @Scheduled 的定时任务，负责定期清理过期数据。某天发现任务执行后，数据并未被清理，日志显示任务执行耗时正常，无异常抛出。
• 排查：
  1. 检查 CleanupService.cleanup() 方法，发现其访问权限是 protected。
  2. 方法上标记了 @Transactional。
  3. 根因：场景 5.2（非 public 方法失效）。因为方法是 protected，AnnotationTransactionAttributeSource 返回了 null，事务没有被开启。由于 JDBC 驱动的某些行为或 JdbcTemplate 的 update 方法默认在 autoCommit=true 下执行，每个 SQL 语句都被独立提交了。但由于存储层的操作没有抛出异常，定时任务没有感知到数据未被清理。
• 解决：将 cleanup 方法改为 public。
• 最佳实践：在代码审查中，必须严格检查 @Transactional 注解所在方法的访问修饰符，必须是 public。

8.3 事故三：文件上传后，数据库记录未保存

• 现象：一个文件管理服务，在上传文件到云存储后，需要将文件元信息保存到数据库。用户反馈文件上传成功但系统中找不到记录。
• 排查：
  1. 查看 FileService，uploadFile() 方法标记了 @Transactional。
  2. 逻辑是：先保存元数据到库，成功后再上传文件到云。
  3. 检查日志，没有数据库异常。
  4. 根因：场景 5.4（try-catch 吞异常） 与 场景 5.3（异常类型不匹配） 的结合。uploadFile() 方法内部调用 cloudSdk.upload()，该方法抛出了一个自定义的 CloudStorageException（非运行时异常）。开发者在调用处做了 try-catch，捕获了 Exception，记录了日志，但并未重新抛出。对于 @Transactional 方法而言，它正常返回了，所以提交了事务。但在此之前，cloudSdk.upload() 调用失败前，saveMetadata() 已经执行了 INSERT 并在 finally 块里被提交了。
• 解决：重构 uploadFile，将文件上传放到数据库操作之前，并在上传失败时直接抛出异常，阻止事务提交。或者，将文件上传操作放在事务提交后的 @TransactionalEventListener 中执行，以保证先有数据库记录，再补偿上传。
• 最佳实践：事务方法中不应包含会改变外部世界状态且耗时长的操作（如调用云服务、发消息）。这种操作应尽可能移到事务外。

好的，我们来将面试题部分的回答大幅深化，使其与全文的源码级深度相匹配。

---

9. 面试高频专题

9.1 @EnableTransactionManagement 的工作原理是什么？它的 mode 属性是如何影响基础设施装配的？

这道题考察的是对 Spring 模块化装配机制的理解。

深度回答：

@EnableTransactionManagement 本身只是一个标记注解，其核心作用是作为一个“开关”，通过 @Import(TransactionManagementConfigurationSelector.class) 驱动 Spring 的配置类解析机制。

1. TransactionManagementConfigurationSelector 的角色： 这个类实现了 ImportSelector 接口。当 Spring 的 ConfigurationClassParser 在解析被 @EnableTransactionManagement 标注的配置类时，会回调该 Selector 的 selectImports 方法。此方法会检查 @EnableTransactionManagement 注解上的 mode 属性。

2. mode 属性的决策逻辑：

   • AdviceMode.PROXY（默认）：这是最常见的选择。Selector 会向容器注册 ProxyTransactionManagementConfiguration 配置类。该配置类通过 @Bean 方法，定义了运行声明式事务所必需的三个核心基础设施 Bean：
     • TransactionAttributeSource（实现为 AnnotationTransactionAttributeSource）：负责从 @Transactional 注解中解析元数据。
     • TransactionInterceptor：核心的事务 Advice，实现了 MethodInterceptor 接口。
     • BeanFactoryTransactionAttributeSourceAdvisor：一个 PointcutAdvisor，它将上述的 Advice 和基于 TransactionAttributeSource 的 Pointcut 绑定在一起。
   • AdviceMode.ASPECTJ：当选择此模式时，Selector 会注册 AspectJTransactionManagementConfiguration。这会完全绕过 Spring AOP 的代理模型，转而依赖 AspectJ 的编译器（ajc）或类加载期织入（Load-Time Weaving, LTW）技术。这使得 @Transactional 可以应用于非 public 方法、自调用等方法，解除代理模式的限制，但代价是引入了额外的构建或运行时代理。

3. 装配的最终结果：无论哪种模式，最终目的都是让 IoC 容器中存在一个能够识别 @Transactional 注解的 Advisor。在 Bean 的初始化阶段，InfrastructureAdvisorAutoProxyCreator 会检测到这个 Advisor，并将其应用于所有匹配的 Bean，为它们创建 AOP 代理。

9.2 TransactionInterceptor 的 invoke 方法是如何协同 PlatformTransactionManager 完成事务生命周期的？请用伪代码梳理核心骨架。

这道题考察的是对拦截器内部源码的熟悉程度。

深度回答：

TransactionInterceptor 本身只是一个薄层，它实现了 MethodInterceptor 接口，其 invoke 方法直接调用了父类 TransactionAspectSupport 的 invokeWithinTransaction 方法。这个方法的逻辑是声明式事务执行的绝对核心，其可以概括为以下骨架：

// 位置：TransactionAspectSupport.invokeWithinTransaction (简化骨架)
protected Object invokeWithinTransaction(Method method, Class<?> targetClass, InvocationCallback invocation) throws Throwable {

    // 步骤 1：获取事务属性
    // 尝试从 TransactionAttributeSource 中获取当前方法的 TransactionAttribute
    TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);

    // 步骤 2：确定事务管理器
    // 根据 txAttr 中的 qualifier 或默认规则，确定一个 PlatformTransactionManager 实例
    PlatformTransactionManager tm = determineTransactionManager(txAttr);

    // 步骤 3：创建事务（如果需要）
    // 调用事务管理器的 getTransaction()。这是前文深入分析过的模板方法。
    // 它会根据传播行为决定是创建新事务、参与已有事务，还是非事务运行。
    TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, methodIdentification);

    Object retVal = null;
    try {
        // 步骤 4：执行目标方法
        // 这里是真正调用业务逻辑的点，也是整个链路的“下一个”环节。
        retVal = invocation.proceedWithInvocation();
    }
    catch (Throwable ex) {
        // 步骤 5：异常处理（决策点）
        // 调用 completeTransactionAfterThrowing，其内部会用 txAttr.rollbackOn(ex) 判断是否回滚。
        // 如果匹配，执行 tm.rollback(txInfo.getTransactionStatus())；
        // 如果不匹配，则执行 tm.commit(txInfo.getTransactionStatus())。
        completeTransactionAfterThrowing(txInfo, ex);
        throw ex; // 始终重新抛出，保持异常传播
    }
    finally {
        // 步骤 6：清理线程状态
        // 恢复 TransactionSynchronizationManager 中的事务信息为进入方法前的状态。
        cleanupTransactionInfo(txInfo);
    }

    // 步骤 7：提交事务
    // 如果一切正常，到达此处时执行提交。
    commitTransactionAfterReturning(txInfo);
    return retVal;
}

面试中需要强调的深度点：

• createTransactionIfNecessary 不是简单地创建，它背后是 AbstractPlatformTransactionManager.getTransaction() 的传播行为判断。
• completeTransactionAfterThrowing 是失效问题的“高发区”，它揭示了事务提交与否并非取决于是否有异常，而是异常类型是否匹配配置的回滚规则。
• cleanupTransactionInfo 保证了在当前方法退出时，无论成功与否，都会将线程的 TransactionSynchronizationManager 恢复到外部调用者的状态，这是事务正确传播的关键。

9.3 请从源码层面解释，为什么 @Transactional 注解的方法内部，通过 this.method() 调用另一个 @Transactional 方法会导致事务失效？

这道题是经典的“Spring 代理”理解测试。

深度回答：

这个问题的根源在于对 Spring AOP 代理模型的误解。要从源码层面解释，需要分三个层次：

1. 代理对象的本质：当 Spring 为一个 Bean 创建 AOP 代理时，如果目标类实现了接口，默认会创建一个 JDK 动态代理对象（java.lang.reflect.Proxy）；如果没有实现接口，则会创建一个 CGLIB 子类对象。无论哪种，这个代理对象和原始的 Bean 实例（目标对象）是两个不同的对象。

2. 调用如何被拦截：当我们通过 Spring 注入的引用去调用方法时，例如在 Controller 中 @Autowired private MyService myService，这个 myService 实际上就是代理对象。因此，调用 myService.publicMethod() 会被代理对象捕获，从而按顺序执行 TransactionInterceptor 等一系列 Advice。

3. 自调用的真相：在 MyService 内部，this 关键字是 Java 语法层面的引用，它始终指向当前正在执行的对象实例。由于业务逻辑运行在原始目标对象内，这里的 this 就是目标对象本身，而不是包裹它的代理对象。当代码执行 this.anotherTransactionalMethod() 时，它是一次普通的 Java 方法调用，完全绕过了代理。TransactionInterceptor 的 invoke 方法根本没有被触发，TransactionAttributeSource 也不会去尝试查找方法上的注解。

源码佐证：在 TransactionAspectSupport.invokeWithinTransaction 的执行逻辑中，invocation.proceedWithInvocation() 才会调用到目标方法。自调用发生在目标方法内部，是在 proceedWithInvocation() 这个调用之后发生的，完全在拦截链之外。

解决方案对比：

• 重构（推荐）：将内部方法拆分到另一个 Bean 中，通过 @Autowired 注入。这样从外部调用时，Spring 容器必然会注入代理对象，事务就能正常工作。
• AopContext.currentProxy()：这是一个权宜之计。它要求配置 @EnableAspectJAutoProxy(exposeProxy = true)，这样 Spring 会将当前代理对象暴露在 ThreadLocal 中。通过 ((MyService) AopContext.currentProxy()).anotherTransactionalMethod() 可以获取到代理对象并调用。但这会让业务代码侵入框架细节。
• AspectJ 织入：通过编译时或类加载时织入，AspectJ 可以在字节码层面将 TransactionInterceptor 的逻辑直接织入到 this.method() 调用的位置。这是从根源上解决问题，但需要改变项目构建方式。

9.4 为什么 Spring 声明式事务默认只对 RuntimeException 和 Error 进行回滚？想回滚 Checked Exception 底层机制是什么？

这道题考察对 DefaultTransactionAttribute 和 RuleBasedTransactionAttribute 源码的理解。

深度回答：

1. 默认行为的设计哲学：@Transactional 默认回滚行为定义在 DefaultTransactionAttribute.rollbackOn(Throwable ex) 方法中，其实现很简单：return (ex instanceof RuntimeException || ex instanceof Error);。这种设计源于 EJB 时代的习惯和 Java 异常体系的设计思想。RuntimeException 通常代表不可恢复的程序逻辑错误（如 NPE、数组越界），事务回滚是必然选择。而 Checked Exception 代表一种“可预见”且“可恢复”的情况（如 IOException），框架将是否回滚的决定权交给了开发者。

2. 覆盖默认行为的机制：通过 @Transactional(rollbackFor = Exception.class) 可以覆盖默认行为。这个属性的解析发生在 SpringTransactionAnnotationParser.parseTransactionAnnotation 方法中。它会将 rollbackFor 的值（一个 Class 数组）解析为 RuleBasedTransactionAttribute 对象中的一系列 RollbackRuleAttribute。

3. 匹配决策源码：当方法抛出异常时，TransactionAspectSupport.completeTransactionAfterThrowing 会调用 txAttr.rollbackOn(ex)。在 RuleBasedTransactionAttribute 的重写实现中，它会遍历所有配置的 RollbackRuleAttribute，并调用 rule.getDepth(ex)。这个方法内部使用的是 Class.isAssignableFrom()，因此支持多态。如果抛出的异常与某个 RollbackRuleAttribute 成功匹配，且该规则不是 NoRollbackRuleAttribute，则返回 true（回滚）；否则返回 false（提交）。

面试关键点：必须明确指出，最终的回滚决策不是简单的“有异常就回滚”，而是经过 rollbackOn 方法的“审判”，并且 Spring 支持通过 rollbackFor 和 noRollbackFor 进行精细化的异常匹配。

9.5 REQUIRES_NEW 和 NESTED 在源码执行链路和数据库行为上有何本质区别？

这道题考察对 AbstractPlatformTransactionManager 中传播行为处理逻辑的深入理解。

深度回答：

两者的核心区别在于“物理”与“逻辑”的独立性。

1. PROPAGATION_REQUIRES_NEW：物理独立事务

   • 源码执行路径：在 AbstractPlatformTransactionManager.getTransaction() 的 handleExistingTransaction 方法中，遇到 PROPAGATION_REQUIRES_NEW 时会：
     1. 调用 suspend(transaction)，将当前正在运行的事务挂起。挂起的本质是从 TransactionSynchronizationManager 中解绑所有当前线程的资源（如 JDBC Connection），并将其保存在一个 SuspendedResourcesHolder 对象中。
     2. 调用 doBegin() 开启一个全新的物理事务。doBegin() 会从 DataSource 获取一个新的 Connection，设置 autoCommit=false，并将其绑定到 TransactionSynchronizationManager。
   • 数据库行为：数据库层会看到一个全新的、独立的数据库事务。内层事务拥有自己独立的连接、隔离级别和锁。内层事务的提交和回滚完全不影响被挂起的外层事务。当内层事务完成（提交或回滚）后，之前的挂起的事务会被 resume，重新绑定其原始连接到线程。

2. PROPAGATION_NESTED：逻辑 Savepoint

   • 源码执行路径：在同样处理已存在事务的场景下，PROPAGATION_NESTED 的源码路径是：
     1. 检查当前 PlatformTransactionManager 是否实现了 NestedTransaction 接口。如果没实现，则可能降级处理。
     2. 如果支持嵌套，它不会挂起当前事务。而是通过 JDBC 3.0 的 Savepoint 机制，调用 connection.setSavepoint() 创建一个保存点。
   • 数据库行为：整个操作仍然在同一个数据库连接和同一个顶层事务中。内层方法的回滚是通过 connection.rollback(savepoint) 实现的，只撤销到保存点。但是！内层事务的回滚会导致整个顶层事务被标记为“不可提交”。这意味着，即使外层方法捕获了内层抛出的异常并试图提交，AbstractPlatformTransactionManager.commit() 方法在检查到 rollbackOnly 标识后，会抛出 UnexpectedRollbackException，强制整个事务回滚。这是线上一个非常隐蔽的坑。

总结：REQUIRES_NEW 是独立的连接和事务，而 NESTED 是共享连接的同一事务，仅靠 Savepoint 实现逻辑上的子事务。前者内层提交/回滚不影响外层；后者内层回滚会污染整个事务。

9.6 如何在 Spring 事务中开启 TRACE 日志进行问题诊断？你会重点观察哪些日志输出？

这道题考察的是实战问题排查能力。

深度回答：

1. 开启的配置：Spring 事务最核心的日志来自 org.springframework.transaction 和 org.springframework.jdbc.datasource 两个包。在 Spring Boot 的 application.properties 中最关键的配置是：

   logging.level.org.springframework.transaction=TRACE
   logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=TRACE
   

   第二条是针对特定事务管理器的精细化控制，可能输出更详细的连接获取/释放信息。

2. 重点观察的日志输出：

   • TRACE 级别：
     • Getting transaction for [xxx]：这是 getTransaction() 的入口，会完整打印出目标方法和事务属性（传播、隔离级别等）。
     • Participating in existing transaction vs Creating new transaction with name [xxx]：这是判断传播行为是否生效的最直接证据。如果预期是新事务却输出了“Participating...”则说明出问题了。
     • Suspending current transaction... 和 Resuming suspended transaction...：专用于诊断 REQUIRES_NEW 是否如预期般工作。
     • Initiating transaction commit 和 Initiating transaction rollback：事务最终命运的判决书。结合异常的堆栈可以判断为何提交或回滚。
     • Creating named savepoint：诊断 NESTED 传播行为。
   • DEBUG 级别：
     • Acquired Connection [xxx] for JDBC transaction：能看到实际使用的数据库连接对象，有助于排查连接池或手动连接管理问题。
     • Releasing JDBC Connection [xxx] after transaction：同上。

一张清晰的 TRACE 日志，就是一份详细的事务执行报告，是诊断一切“事务Magic”问题的起点。

---

9.7 系统设计题：如何为你的团队设计一套代码规范与审查清单，以系统性规避 @Transactional 的常见“坑”？

这道题考察的是技术领导力和工程化思维。

深度回答：

一套完善的规范体系应包含编码规范、架构约束、自动化检查和代码审查四个层面。

1. 编码规范（显式化原则）：

   • 位置与可见性：@Transactional 只能标记在 public 方法上，且必须在 Service 层。Controller 和 DAO 层严禁使用。
   • 回滚异常策略：永远必须显式指定 rollbackFor。禁止依赖默认行为。更严格的是，推进统一使用 @Transactional(rollbackFor = Throwable.class) 并在团队内部达成一致，明确任何异常都应导致回滚。
   • 传播行为：如果方法使用了 REQUIRES_NEW 或 NESTED，必须在方法注释中明确写明理由和设计意图，因为这通常意味着特殊的业务考量。
   • 禁止事项：
     • 严禁在事务方法内部 try-catch 后不重新抛出相关异常，或抛出一个新的、不匹配 rollbackFor 的异常（除非是故意的补偿逻辑，必须加注释说明）。
     • 严禁在事务方法内启动新线程执行任何依赖于本事务数据的写操作。
     • 严禁在事务方法中进行长耗时、非事务强相关的操作（如文件I/O、RPC调用）。“事务是用来包裹数据库操作的，不是用来包裹整个业务流程的”。

2. 架构约束（解耦与补偿）：

   • 杜绝自调用：通过模块化设计，确保 @Transactional 方法之间的调用一定是跨 Bean 的注入调用。这是规避代理陷阱最彻底的方法。
   • 异步与事务分离：明确 @Transactional 和 @Async 连用是在创建一个独立的、异步的事务。任何需要保证最终一致性的场景，必须使用事务消息表（Outbox Pattern）或本地消息表等非紧密耦合方案，而不是试图在 @Transactional 方法内直接发送 MQ 消息。
   • 事件驱动解耦：利用 @TransactionalEventListener 处理事务成功提交后的非核心逻辑（发通知、记日志），确保这些操作不污染核心业务事务，并天然保证了“只有核心业务成功，周边逻辑才执行”。

3. 自动化检查（静态分析）：

   • 引入 ArchUnit 等架构测试框架，编写测试用例来强制检查上述架构约束。例如：
     • 检查 @Transactional 是否只出现在被 @Service 注解的类中。
     • 检查 @Async 和 @Transactional 是否出现在同一个方法上。
   • 使用 IDE 的代码检查（如 IntelliJ IDEA 的 Structural Search）或 SonarQube 自定义规则，去扫描“在 @Transactional 方法内调用 MQ 发送”、“在 catch 块中未重新抛出异常”等模式。

4. 代码审查（CR Checklist）： 在 Code Review 时，任何一个包含 @Transactional 注解的 PR，审查者必须检查以下清单：

   • 方法是否为 public？
   • 是否指定了 rollbackFor？
   • 是否有自调用（this.xxx()）？
   • 是否有 try-catch？若捕获异常，是否已在最后重新抛出？
   • 是否有 new Thread() 或调用 @Async？
   • 是否有处理 @TransactionalEventListener，并理解其在事务回滚时不被调用的行为？

9.8 系统设计题：在一个需要同时操作数据库和发送消息的业务中，如何利用或配合 @Transactional 保证两者的最终一致性？

这道题考察的是分布式系统下的数据一致性方案设计。

深度回答：

核心原则是：确定以数据库还是消息队列为“最终一致性”的锚点。业界最成熟的模式有两种：

1. 方案一：以数据库为锚点——事务消息表（Outbox Pattern）

   • 核心思想：让消息的发送依赖于数据库事务的提交。
   • 实现步骤：
     1. 在业务数据库中，创建一个本地消息表（outbox）。
     2. 在包含 @Transactional 的业务逻辑中，在同一个事务里，执行业务数据变更，并将待发送的消息（聚合根ID、事件类型、payload等）插入到 outbox 表中。
     3. 事务提交后，业务数据和消息记录一起被持久化，确保了原子性。
     4. 一个独立的、轮询的消息重发器（Relay），会定期从 outbox 表中拉取状态为“待发送”的消息，投递给 MQ。
     5. 投递成功后，Relay 更新该消息记录为“已发送”。
   • 优点：实现简单，依赖少，原子性由本地数据库事务强保证。
   • 适用性：对任何数据库和消息队列都适用。

2. 方案二：以 MQ 为锚点——RocketMQ 事务消息

   • 核心思想：利用 MQ 自身的事务能力进行反向协调。
   • 实现步骤：
     1. 发送方先向 RocketMQ 发送一条半消息（Half Message），此时消息对消费者不可见。
     2. 半消息发送成功后，RocketMQ 回调发送方定义的一个本地事务执行逻辑（RocketMQLocalTransactionListener.executeLocalTransaction()）。
     3. 这个回调方法内部，就是我们通常用 @Transactional 包裹的业务逻辑。如果业务成功，返回 COMMIT_MESSAGE；失败则返回 ROLLBACK_MESSAGE。
     4. RocketMQ 根据回调结果决定是让半消息变为可见（COMMIT）还是丢弃（ROLLBACK）。它还提供事务状态回查机制，用于处理回调执行超时等不确定状态。
   • 优点：不依赖额外的本地消息表和轮询程序，由 MQ 服务器端保证最终一致性。
   • 适用性：强依赖 RocketMQ，技术选型受限。

关键结论：不要在 @Transactional 方法内部同步调用 MQ 的 send 方法然后期望回滚。 这（在非事务消息MQ下）必然失败，因为消息一旦发送成功，无论后续数据库事务是否回滚，都无法撤回。最终一致性方案的精髓就在于利用“本地事务”去担保“消息投递”的发起动作，而不是结果本身。

总结：@Transactional 失效场景速查表

序号	失效场景	核心原因	解决方案/最佳实践
1	自调用	this.method() 绕过了 AOP 代理对象，直接调用目标对象方法	重构拆分为不同Service并注入调用；或通过 AopContext.currentProxy()
2	非public方法	AbstractFallbackTransactionAttributeSource 限定仅 public 方法生效	将方法改为 public 或切换到 AspectJ 织入模式
3	异常类型不匹配	Checked异常默认不回滚，仅 RuntimeException/Error 回滚	明确设置 @Transactional(rollbackFor = Exception.class)
4	异常被吞没	try-catch 后异常未重新抛出，框架感知不到异常，提交事务	catch 后记录日志，并重新抛出或使用 setRollbackOnly()
5	传播行为误用	REQUIRES_NEW 内层事务提交后外层失败回滚，导致数据不一致	强一致性场景使用 REQUIRED；独立场景再使用 REQUIRES_NEW
6	非事务数据库	数据库引擎（如MyISAM）不支持事务	将表引擎更换为 InnoDB 等支持事务的引擎
7	多线程失效	TransactionSynchronizationManager 基于 ThreadLocal，事务不跨线程	禁止在事务方法内启新线程写库；异步场景须设计补偿机制
8	代理类型不当	本质上仍是自调用问题，无论JDK代理还是CGLIB代理都无法解决	同场景1，重构或 AopContext.currentProxy()
9	放在Controller/非Bean	Controller层职责不符，非Spring Bean则无法被代理	严格将注解放在 Service 层，确保类是Spring管理的Bean
10	事务超时未生效	JDBC驱动不支持或耗时操作非SQL执行	双重保障，业务逻辑也需有超时控制
11	绕过 Spring 获取连接	手动 ds.getConnection() 拿到非托管连接，脱离事务管理	使用 DataSourceUtils.getConnection(ds) 或在JdbcTemplate之上构建
12	TransactionTemplate 混用	两者逻辑边界不清，增加调试和代码阅读难度	团队统一约定，同一项目或模块中避免混用
13	嵌套事务陷阱	SavePoint受限或误会导致外层事务被标记为 rollback-only	理解 NESTED 原理，处理内层异常时避免影响外层
14	@Async 连用	异步是新线程，自动脱离原线程的事务上下文	同上多线程，异步事务需独立设计补偿
15	异常精准匹配失败	抛出的异常并未在 rollbackFor 列表中	精确匹配或使用宽异常类型（如 Exception.class），并建立明确规范

延伸阅读

1. Spring Framework 官方文档：Transactions 章节，是理解所有底层设计的源点。
2. 《Spring 揭秘》：王福强著，对事务管理与 AOP 的配合有深入浅出的讲解。
3. 源码分析博客：推荐 baeldung.com 上关于 Spring Transaction 的系列文章，以及国内技术博客中对 AbstractPlatformTransactionManager 的深度源码解读。