切换语言为:繁体

声明式事务的基本原理以及事务中如果存在多线程的解决方案?

  • 爱糖宝
  • 2024-06-12
  • 2066
  • 0
  • 0

在 Spring 框架中,@Transactional 注解作为一种声明式事务管理的关键机制,其背后的工作原理远比简单的 AOP(面向切面编程)和 ThreadLocal 存储更为细腻。该注解的实现核心在于 SpringTransactionInterceptor(事务拦截器)以及它如何与 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 拦截与执行流程

  1. 方法调用前:

    • 事务属性解析: TransactionInterceptor 首先通过TransactionAttributeSource(通常是AnnotationTransactionAttributeSource)获取目标方法的事务属性。

    • 事务开始: 根据解析出的事务属性,决定是否创建新的事务或者加入到当前事务中。如果需要新事务,它会通过事务管理器(如 PlatformTransactionManager 的实现类)来开始事务。

  2. 方法执行:

    • 在事务上下文中执行实际的目标方法。此时,如果目标方法内部抛出了异常,这个异常会被暂存以供后续处理。

  3. 方法调用后:

    • 异常处理: 如果方法执行过程中抛出了异常,TransactionInterceptor 会捕获到这个异常,并根据异常类型及事务属性决定是否需要回滚事务。通常,非检查型异常(继承自 RuntimeException 的异常)会导致事务回滚,而检查型异常则不会,除非事务属性特别指定了回滚规则。

    • 事务提交或回滚: 如果方法正常结束,或者按事务属性应该提交事务的情况下,事务管理器会提交事务。相反,如果需要回滚,则执行回滚操作。

  4. 资源清理: 在事务结束后,确保所有资源被正确释放,比如关闭数据库连接等。

2.3 动态代理的作用

整个过程中,动态代理扮演着关键角色。无论是 JDK 动态代理还是 CGLIB 代理,它们都是在调用真正业务方法之前插入事务拦截逻辑的桥梁。当客户端代码调用代理对象上的方法时,实际上是调用了由 TransactionInterceptor 所控制的代理逻辑,从而透明地在业务逻辑执行前后管理事务。

通过这种方式,开发者无需在每个需要事务管理的方法中手动编写开启、提交或回滚事务的代码,极大地简化了开发复杂度,提高了代码的可维护性和可读性。

三 多线程环境下的挑战

当 @Transactional 标记的方法内部启动新的线程时,问题就显现了。前面提到,事务拦截使用了 TransactionInterceptor,而 TransactionInterceptor 内部用到了  TransactionSynchronizationManager,TransactionSynchronizationManager 使用 ThreadLocal 来存储事务相关的资源信息,如数据库连接、JMS 会话等。这意味着每个线程都有其独立的事务上下文,确保了事务信息在线程间的隔离。

换句话说,Spring 管理的事务上下文是基于调用线程的,新线程并没有继承原线程的 TransactionSynchronizationManager 中的事务上下文。因此,新线程执行的数据库操作实际上是在无事务管理的环境下进行的,这就导致事务失效。

那如果非要用多线程怎么办呢?这个时候可以使用编程式事务,首先设置一个全局变量 Boolean,默认是可以提交的 true,在子线程,通过编程式事务的方式去开启事务,然后插入数据,插入完成后,事务先不提交,同时通知主线程,我准备好了,进入等待状态。如果子线程出现异常,那就通知主线程,我这边发生异常,然后自己回滚。

最后主线程收集各个子线程的状态,如果有一个线程出现问题,那么全局变量就设置为不可提交false,然后唤醒所有子线程,进行回滚。

这里涉及到线程同步可以利用闭锁去实现;当主线程通知各个子线程提交事务的时候,子线程可能在提交的时候出错了,最终导致数据不一致,那么这种时候可能就需要引入重试机制,有了重试机制后,又要去保证幂等性等等。

这一套方案下来大伙有没有觉得眼熟,是不是就是分布式事务的处理思路了?

所以说,非要在事务中开启多线程也没问题,但是不建议这么做。

0条评论

您的电子邮件等信息不会被公开,以下所有项均必填

OK! You can skip this field.