在 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，然后唤醒所有子线程，进行回滚。
这里涉及到线程同步可以利用闭锁去实现；当主线程通知各个子线程提交事务的时候，子线程可能在提交的时候出错了，最终导致数据不一致，那么这种时候可能就需要引入重试机制，有了重试机制后，又要去保证幂等性等等。
这一套方案下来大伙有没有觉得眼熟，是不是就是分布式事务的处理思路了？
所以说，非要在事务中开启多线程也没问题，但是不建议这么做。
本文链接：http://www.28at.com/showinfo-26-93354-0.html事务中存在多线程，怎么处理？
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
下一篇： Fiddler：一个大名鼎鼎的私藏工具
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
