在 Spring 框架中，@Transactional 注解作为一种声明式事务管理的关键机制，其背后的工作原理远比简单的 AOP（面向切面编程）和 ThreadLocal 存储更为细腻。该注解的实现核心在于 Spring 的 TransactionInterceptor（事务拦截器）以及它如何与 Spring 的代理机制、TransactionManager（事务管理器）协同工作，来确保事务的开启、提交或回滚等操作得以正确执行。 一 注解解析与代理生成当 Spring 容器初始化时，会通过 AnnotationTransactionAttributeSource 扫描并识别出所有标有 @Transactional 的方法。这些方法在被调用前，Spring 会根据配置（如基于接口或类的代理）为它们创建动态代理对象。如果是基于接口的代理，则使用 JDK Dynamic Proxy；如果是基于类的，则采用 CGLIB。这个代理对象会在目标方法调用前后插入事务处理逻辑。 1.1 Spring Bean的后处理器一切始于 Spring 容器的 Bean 创建和初始化过程。Spring 通过一系列的 BeanPostProcessor 接口实现类来增强 Bean 的功能，其中与事务管理密切相关的便是 AbstractAutoProxyCreator的子类，如 AnnotationAwareAspectJAutoProxyCreator。这个类负责扫描并创建代理对象，以便于在运行时织入诸如事务管理这样的切面逻辑。 1.2 识别 @Transactional 注解ClassPathScanningCandidateComponentProvider：Spring 首先会使用此类扫描指定包路径下带有特定注解（如@Transactional）的类或方法。AnnotationTransactionAttributeSource：一旦找到带有 @Transactional 注解的类或方法，Spring 会使用 AnnotationTransactionAttributeSource 来解析这些注解，将其转换为事务属性（TransactionAttribute），比如事务的隔离级别、传播行为、超时时间等。1.3 创建代理对象对于基于接口的代理，Spring 使用 JDK 的动态代理技术，通过JdkDynamicAopProxy创建代理对象。该代理会检查调用链，并在调用目标方法前插入事务管理的前置逻辑，调用后插入后置逻辑（如提交或回滚事务）。对于没有实现接口的类，Spring 则利用 CGLIB 库生成目标类的子类作为代理，通过CglibAopProxy 来完成。CGLIB 代理同样能够在目标方法调用的前后插入事务管理代码。1.4 TransactionInterceptor在代理对象中，事务管理的具体逻辑是由 TransactionInterceptor（事务拦截器）来执行的。它实现了 MethodInterceptor 接口，因此当代理对象的方法被调用时，会进入invoke(MethodInvocation invocation) 方法。在这个方法内，TransactionInterceptor 根据解析出的事务属性来决定是否开启事务、使用何种传播行为，并最终调用目标方法。 总结下就是，Spring 通过 Bean 的后置处理器在容器初始化阶段自动检测带有 @Transactional 注解的类和方法，并通过动态代理机制为这些组件创建代理对象。代理对象在方法调用时，通过 TransactionInterceptor 这一核心组件，根据注解配置的事务属性来管理事务生命周期，确保事务逻辑的无缝集成。 二 事务拦截与执行2.1 TransactionInterceptor 的作用TransactionInterceptor 实现了 Spring 的 MethodInterceptor 接口，这意味着它能够拦截方法调用，并在调用前后执行额外的逻辑，即事务管理逻辑。其核心职责包括： 识别是否需要事务: 根据目标方法上的 @Transactional 注解（如果有的话）及其属性（如传播行为、隔离级别、超时时间等），决定是否需要启动一个新的事务或加入到现有的事务中。需要注意的是，事务上下文（包括连接信息等）被存储在由 Spring 管理的一个特定的 TransactionSynchronizationManager 中，TransactionSynchronizationManager 内部使用了 ThreadLocal。事务管理: 在方法调用之前开启事务，调用之后根据方法执行结果提交或回滚事务。这包括异常处理逻辑，即在遇到未被捕获的异常时，确保事务被正确回滚。2.2 拦截与执行流程方法调用前:事务属性解析: TransactionInterceptor 首先通过TransactionAttributeSource（通常是AnnotationTransactionAttributeSource）获取目标方法的事务属性。事务开始: 根据解析出的事务属性，决定是否创建新的事务或者加入到当前事务中。如果需要新事务，它会通过事务管理器（如 PlatformTransactionManager 的实现类）来开始事务。方法执行:在事务上下文中执行实际的目标方法。此时，如果目标方法内部抛出了异常，这个异常会被暂存以供后续处理。方法调用后:异常处理: 如果方法执行过程中抛出了异常，TransactionInterceptor 会捕获到这个异常，并根据异常类型及事务属性决定是否需要回滚事务。通常，非检查型异常（继承自 RuntimeException 的异常）会导致事务回滚，而检查型异常则不会，除非事务属性特别指定了回滚规则。事务提交或回滚: 如果方法正常结束，或者按事务属性应该提交事务的情况下，事务管理器会提交事务。相反，如果需要回滚，则执行回滚操作。资源清理: 在事务结束后，确保所有资源被正确释放，比如关闭数据库连接等。2.3 动态代理的作用整个过程中，动态代理扮演着关键角色。无论是 JDK 动态代理还是 CGLIB 代理，它们都是在调用真正业务方法之前插入事务拦截逻辑的桥梁。当客户端代码调用代理对象上的方法时，实际上是调用了由 TransactionInterceptor 所控制的代理逻辑，从而透明地在业务逻辑执行前后管理事务。 通过这种方式，开发者无需在每个需要事务管理的方法中手动编写开启、提交或回滚事务的代码，极大地简化了开发复杂度，提高了代码的可维护性和可读性。 三 多线程环境下的挑战当 @Transactional 标记的方法内部启动新的线程时，问题就显现了。前面提到，事务拦截使用了 TransactionInterceptor，而 TransactionInterceptor 内部用到了 TransactionSynchronizationManager，TransactionSynchronizationManager 使用 ThreadLocal 来存储事务相关的资源信息，如数据库连接、JMS 会话等。这意味着每个线程都有其独立的事务上下文，确保了事务信息在线程间的隔离。 换句话说，Spring 管理的事务上下文是基于调用线程的，新线程并没有继承原线程的 TransactionSynchronizationManager 中的事务上下文。因此，新线程执行的数据库操作实际上是在无事务管理的环境下进行的，这就导致事务失效。 那如果非要用多线程怎么办呢？这个时候可以使用编程式事务，首先设置一个全局变量 Boolean，默认是可以提交的 true，在子线程，通过编程式事务的方式去开启事务，然后插入数据，插入完成后，事务先不提交，同时通知主线程，我准备好了，进入等待状态。如果子线程出现异常，那就通知主线程，我这边发生异常，然后自己回滚。 最后主线程收集各个子线程的状态，如果有一个线程出现问题，那么全局变量就设置为不可提交false，然后唤醒所有子线程，进行回滚。 这里涉及到线程同步可以利用闭锁去实现；当主线程通知各个子线程提交事务的时候，子线程可能在提交的时候出错了，最终导致数据不一致，那么这种时候可能就需要引入重试机制，有了重试机制后，又要去保证幂等性等等。 这一套方案下来大伙有没有觉得眼熟，是不是就是分布式事务的处理思路了？ 所以说，非要在事务中开启多线程也没问题，但是不建议这么做。