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