1.Springboot之分布式事务框架Seata实现原理源码分析
2.76 张图，事务事务剖析 Spring AOP 源码，源码源码小白居然也能看懂，分析分析大神，事务事务请收下我的源码源码膝盖！
3.Spring事务（Transaction）管理高级篇一栈式解决开发中遇到的分析分析区块链金融源码搭建事务问题
4.spring—AOP与事务
5.Spring事务方法嵌套引发的异常与问题分析

Springboot之分布式事务框架Seata实现原理源码分析

       在SpringBoot环境下的分布式事务框架Seata实现原理涉及到了代理数据源、注册代理Bean以及全局事务拦截器等关键环节。事务事务下面我们将逐步解析其核心逻辑。源码源码

       首先，分析分析Seata通过GlobalTransactionScanner来注册项目中所有带有@GlobalTransactional注解的事务事务方法类。该扫描器是源码源码一个实现了BeanPostProcessor接口的类，它能够在Spring容器初始化时进行后置处理，分析分析从而实现全局事务的事务事务管理。

       GlobalTransactionScanner实际上是源码源码一个InstantiationAwareBeanPostProcessor，它在实例化Bean前执行postProcessBeforeInstantiation方法，分析分析在实例化后执行postProcessAfterInstantiation方法，并在属性填充时执行postProcessProperties方法。尽管GlobalTransactionScanner类本身并未覆盖这3个方法，但在父类的实现中，这些方法用于处理Bean的实例化和属性设置过程。

       关键在于postProcessAfterInitialization方法中实现的wrapIfNecessary方法，该方法在GlobalTransactionScanner类中被重写。当方法执行到existsAnnotation方法判断类方法是否带有@GlobalTransactional注解时，如果存在则创建一个GlobalTransactionalInterceptor作为拦截器处理全局事务。

       在创建代理数据源时，Seata通过DataSourceProxy对系统默认数据源进行代理处理。通过shouldSkip方法判断当前bean是否需要被代理，如果bean是SeataProxy的子类且不是DataSource的子类且不在excludes集合中，则进行代理，从而代理当前系统的默认数据源对象。

       全局事务拦截器主要负责全局事务的发起、执行和回滚。在执行全局事务的方法被代理时，具体的灭绝师太指标源码执行拦截器是GlobalTransactionalInterceptor。该拦截器处理全局事务的逻辑，包括获取全局事务、开始全局事务、执行本地业务、提交本地事务、记录undo log、提交数据更新等步骤。其中，提交本地事务时会向TC（Transaction Coordinator）注册分支并提交本地事务，整个过程确保了分布式事务的一致性。

       当全局事务中任何一个分支发生异常时，事务将被回滚。参与全局事务的组件在异常发生时执行特定的回滚逻辑，确保事务一致性。在Seata的实现中，异常处理机制确保了事务的回滚能够正确执行。

       Seata还提供了XID（Transaction Identifier）的传递机制，通过RestTemplate和Feign客户端进行服务间的调用，确保分布式系统中各个服务能够共享和处理全局事务。RestTemplate在请求头中放置TX_XID头信息，而Feign客户端通过从调用链中获取Feign.Builder，最终通过SeataHystrixFeignBuilder.builder方法实现XID的传递。

       在被调用端（通过Feign调用服务），Seata自动配置会创建数据源代理，使得事务方法执行时能够获取到连接对象，而这些连接对象已经被代理成DataSourceProxy。SeataHandlerInterceptor拦截器对所有请求进行拦截，从Header中获取TX_XID，参与者的XID绑定到上下文中，通过ConnectionProxy获取代理连接对象。在数据库操作中，XID绑定到ConnectionContext，执行SQL语句时通过StatementProxy或PreparedStatementProxy代理连接，vs的hook补丁源码从而完成全局事务的处理。

       综上所述，Seata通过一系列复杂的逻辑和机制，实现了SpringBoot环境下的分布式事务管理，确保了分布式系统中数据的一致性和可靠性。

张图，剖析 Spring AOP 源码，小白居然也能看懂，大神，请收下我的膝盖！

       本文将简要介绍AOP（面向切面编程）的基础知识与使用方法，并深入剖析Spring AOP源码。首先，我们需要理解AOP的基本概念。

       1. **基础知识

**

       1.1 **什么是AOP？

**

       AOP全称为Aspect Oriented Programming，即面向切面编程。AOP的思想中，周边功能（如性能统计、日志记录、事务管理等）被定义为切面，核心功能与切面功能独立开发，然后将两者“编织”在一起，这就是AOP的核心。

       AOP能够将与业务无关、却为业务模块共同调用的逻辑封装，减少系统重复代码，降低模块间的耦合度，有利于系统的可扩展性和可维护性。

       1.2 **AOP基础概念

**

       解释较为官方，以下用“方言”解释：AOP包括五种通知分类。

       1.3 **AOP简单示例

**

       创建`Louzai`类，添加`LouzaiAspect`切面，并在`applicationContext.xml`中配置。社区论坛源码购买程序入口处添加`"睡觉"`方法并添加前置和后置通知。接下来，我们将探讨Spring内部如何实现这一过程。

       1.4 **Spring AOP工作流程

**

       为了便于理解后面的源码，我们将整体介绍源码执行流程。整个Spring AOP源码分为三块，结合示例进行讲解。

       第一块是前置处理，创建`Louzai`Bean前，遍历所有切面信息并存储在缓存中。第二块是后置处理，创建`Louzai`Bean时，主要处理两件事。第三块是执行切面，通过“责任链+递归”执行切面。

       2. **源码解读

**

       注意：Spring版本为5.2..RELEASE，否则代码可能不同！这里，我们将从原理部分开始，逐步深入源码。

       2.1 **代码入口

**

       从`getBean()`函数开始，进入创建Bean的逻辑。

       2.2 **前置处理

**

       主要任务是遍历切面信息并存储。

       这是重点！请务必注意！获取切面信息流程结束，后续操作都从缓存`advisorsCache`获取。

       2.2.1 **判断是否为切面

**

       执行逻辑为：判断是否包含切面信息。

       2.2.2 **获取切面列表

**

       进入`getAdvice()`，生成切面信息。

       2.3 **后置处理

**

       主要从缓存拿切面，与`Louzai`方法匹配，创建AOP代理对象。商品溯源码显示不清

       进入`doCreateBean()`，执行后续逻辑。

       2.3.1 **获取切面

**

       首先，查看如何获取`Louzai`的切面列表。

       进入`buildAspectJAdvisors()`，方法用于存储切面信息至缓存`advisorsCache`。随后回到`findEligibleAdvisors()`，从缓存获取所有切面信息。

       2.3.2 **创建代理对象

**

       有了`Louzai`的切面列表，开始创建AOP代理对象。

       这是重点！请仔细阅读！这里有两种创建AOP代理对象方式，我们选择使用Cglib。

       2.4 **切面执行

**

       通过“责任链+递归”执行切面与方法。

       这部分逻辑非常复杂！接下来是“执行切面”最核心的逻辑，简述设计思路。

       2.4.1 **第一次递归

**

       数组第一个对象执行`invoke()`，参数为`CglibMethodInvocation`。

       执行完毕后，继续执行`CglibMethodInvocation`的`process()`。

       2.4.2 **第二次递归

**

       数组第二个对象执行`invoke()`。

       2.4.3 **第三次递归

**

       数组第三个对象执行`invoke()`。

       执行完毕，退出递归，查看`invokeJoinpoint()`执行逻辑，即执行主方法。回到第三次递归入口，继续执行后续切面。

       切面执行逻辑已演示，直接查看执行方法。

       流程结束时，依次退出递归。

       2.4.4 **设计思路

**

       这部分代码研究了大半天，因为这里不是纯粹的责任链模式。

       纯粹的责任链模式中，对象内部有一个自身的`next`对象，执行当前对象方法后，启动`next`对象执行，直至最后一个`next`对象执行完毕，或中途因条件中断执行，责任链退出。

       这里`CglibMethodInvocation`对象内部无`next`对象，通过`interceptorsAndDynamicMethodMatchers`数组控制执行顺序，依次执行数组中的对象，直至最后一个对象执行完毕，责任链退出。

       这属于责任链，实现方式不同，后续会详细剖析。下面讨论类之间的关系。

       主对象为`CglibMethodInvocation`，继承于`ReflectiveMethodInvocation`，`process()`的核心逻辑在`ReflectiveMethodInvocation`中。

       `ReflectiveMethodInvocation`的`process()`控制整个责任链的执行。

       `ReflectiveMethodInvocation`的`process()`方法中，包含一个长度为3的数组`interceptorsAndDynamicMethodMatchers`，存储了3个对象，分别为`ExposeInvocationInterceptor`、`MethodBeforeAdviceInterceptor`、`AfterReturningAdviceInterceptor`。

       注意！这3个对象都继承了`MethodInterceptor`接口。

       每次`invoke()`调用时，都会执行`CglibMethodInvocation`的`process()`。

       是否有些困惑？别着急，我将再次帮你梳理。

       对象与方法的关系：

       可能有同学疑惑，`invoke()`的参数为`MethodInvocation`，没错！但`CglibMethodInvocation`也继承了`MethodInvocation`，可自行查看。

       执行逻辑：

       设计巧妙之处在于，纯粹的责任链模式中，`next`对象需要保证类型一致。但这里3个对象内部没有`next`成员，不能直接使用责任链模式。怎么办呢？就单独设计了`CglibMethodInvocation.process()`，通过无限递归`process()`实现责任链逻辑。

       这就是我们为什么要研究源码，学习优秀的设计思路！

       3. **总结

**

       本文首先介绍了AOP的基本概念与原理，通过示例展示了AOP的应用。之后深入剖析了Spring AOP源码，分为三部分。

       本文是Spring源码解析的第三篇，感觉是难度较大的一篇。图解代码花费了6个小时，整个过程都沉浸在代码的解析中。

       难度不在于抠图，而是“切面执行”的设计思路，即使流程能走通，将设计思想总结并清晰表达给读者，需要极大的耐心与理解能力。

       今天的源码解析到此结束，有关Spring源码的学习，大家还想了解哪些内容，欢迎留言给楼仔。

Spring事务（Transaction）管理高级篇一栈式解决开发中遇到的事务问题

       深入理解Spring事务管理

       Spring，作为Java开发中广受欢迎的框架，其事务管理功能在日常开发中起到了举足轻重的作用。然而，许多开发者对事务的原理理解不够深入，导致在遇到事务相关问题时，解决过程往往冗长且复杂。本文将带你逐步探索Spring事务管理的高级特性，揭示其原理，并针对开发中常见的事务问题提供解决方案。

       在纯Spring框架下使用事务管理，首先需要添加`@EnableTransactionManagement`注解，这实际上导入了`ProxyTransactionManagementConfiguration`配置类，该类负责注入事务管理所需的增强器、属性资源以及拦截器。

       当方法上使用了事务注解（如`@Transactional`），Spring将创建一个代理对象，并将其注入到Spring容器中，而非原始对象。这个代理对象是基于AOP（面向切面编程）技术生成的，主要用于在方法调用前后执行事务管理操作。

       以UserService为例，假设其包含一个简单的业务方法。在Spring的事务管理下，该方法的调用流程会经过一系列的注入和配置，最终在执行业务逻辑后提交或回滚事务。

       在深入源码分析中，会发现事务管理的核心在于调用特定的代理方法来开启、执行、提交或回滚事务。例如，在特定的代理方法中调用`tm.getTransaction(txAttr)`开启事务，并在执行完业务逻辑后返回，使得整个方法的执行过程被封装在事务管理的上下文中。

       值得注意的是，事务的传播行为决定了在方法嵌套调用时，如何管理事务。例如，使用`Propagation.REQUIRED`或`Propagation.REQUIRES_NEW`传播属性，可以控制事务的生命周期。正确理解和运用这些传播属性，有助于避免在多层调用中导致的事务回滚问题。

       在开发实践中，常见的事务问题包括未正确使用代理对象、忽略特定异常处理、不当的事务嵌套等。解决这些问题的关键在于理解Spring事务管理的原理、正确配置事务注解、以及合理设计业务逻辑，避免在多层调用中出现事务不一致或回滚的情况。

       总结事务管理的实践经验，有助于快速定位和解决开发中遇到的事务相关问题。深入研究Spring事务管理的细节，结合实际案例分析，能够提升开发者对事务管理的驾驭能力，从而在项目开发中更加游刃有余。

spring—AOP与事务

        title: spring——AOP与事务.md

        date: -- ::

        categories: [Spring]

        tags: [AOP,事务]

        toc: true

        先列出源码中比较重点的几个类：

        1、<aop:before method="before" pointcut-ref="myMethods"/>包装成一个advisor

        2、AspectJAwareAdvisorAutoProxyCreator，当实例化所有bean都会执行到AspectJAwareAdvisorAutoProxyCreatorç±»

        它会检测bean是否advisor以及advice存在，如果有就说明这个bean有切面，有切面那么就会生成代理

        3、jdk的代理，bean里面的所有advisor加入到proxyFactory。

        4、jdkDynamicProxy invoke，拿到bean里面的所有Interceptor，会循环proxyFactory里面的所有advisor

        里面有advice，里面的advice有两种类型，要么是advice，要么是MethodInterceptor类型的

        5、当代理对象调用方式，是一个MethodInterceptor类型的类的链式调用过程，直到容器的大小和索引一致的时候调用JoinPoint目标方法

        before：this.advice.before(),invocation.processd();

        装配参数，切面里面before方法的method对象，method.getParamterTypes()[0]

        最终会把advice封装成MethodInterceptor类型的对象

        程序执行的某个特定位置：如类开始初始化前、类初始化后、类某个方法调用前、调用后、方法抛出异常后。一个类或一段程序代码拥有一些具有边界性质的特定点，这些点中的特定点就称为“连接点”。Spring仅支持方法的连接点，即仅能在方法调用前、方法调用后、方法抛出异常时以及方法调用前后这些程序执行点织入增强。连接点由两个信息确定：第一是用方法表示的程序执行点；第二是用相对点表示的方位。

        每个程序类都拥有多个连接点，如一个拥有两个方法的类，这两个方法都是连接点，即连接点是程序类中客观存在的事物。AOP通过“切点”定位特定的连接点。连接点相当于数据库中的记录，而切点相当于查询条件。切点和连接点不是一对一的关系，一个切点可以匹配多个连接点。在Spring中，切点通过org.springframework.aop.Pointcut接口进行描述，它使用类和方法作为连接点的查询条件，Spring AOP的规则解析引擎负责切点所设定的查询条件，找到对应的连接点。其实确切地说，不能称之为查询连接点，因为连接点是方法执行前、执行后等包括方位信息的具体程序执行点，而切点只定位到某个方法上，所以如果希望定位到具体连接点上，还需要提供方位信息。

        增强是织入到目标类连接点上的一段程序代码，在Spring中，增强除用于描述一段程序代码外，还拥有另一个和连接点相关的信息，这便是执行点的方位。结合执行点方位信息和切点信息，我们就可以找到特定的连接点。

        增强逻辑的织入目标类。如果没有AOP，目标业务类需要自己实现所有逻辑，而在AOP的帮助下，目标业务类只实现那些非横切逻辑的程序逻辑，而性能监视和事务管理等这些横切逻辑则可以使用AOP动态织入到特定的连接点上。

        引介是一种特殊的增强，它为类添加一些属性和方法。这样，即使一个业务类原本没有实现某个接口，通过AOP的引介功能，我们可以动态地为该业务类添加接口的实现逻辑，让业务类成为这个接口的实现类。

        织入是将增强添加对目标类具体连接点上的过程。AOP像一台织布机，将目标类、增强或引介通过AOP这台织布机天衣无缝地编织到一起。根据不同的实现技术，AOP有三种织入的方式：

        a、编译期织入，这要求使用特殊的Java编译器。

        b、类装载期织入，这要求使用特殊的类装载器。

        c、动态代理织入，在运行期为目标类添加增强生成子类的方式。

        Spring采用动态代理织入，而AspectJ采用编译期织入和类装载期织入。

        一个类被AOP织入增强后，就产出了一个结果类，它是融合了原类和增强逻辑的代理类。根据不同的代理方式，代理类既可能是和原类具有相同接口的类，也可能就是原类的子类，所以我们可以采用调用原类相同的方式调用代理类。

        切面由切点和增强（引介）组成，它既包括了横切逻辑的定义，也包括了连接点的定义，Spring AOP就是负责实施切面的框架，它将切面所定义的横切逻辑织入到切面所指定的连接点中。

        advisor： pointCut advice

        一类功能的增强

        around方法里面代码切面

        事务切面

        缓存切面

        日志切面

        事务（Transaction），一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；事务是一组不可再分割的操作集合（工作逻辑单元）。

        大致流程形如

        数据库事务拥有几大特性：

        事务的四大特性：

        事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做

        事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。

        一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

        也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

        个人理解，事务在Spring中是借助AOP技术来实现的，可以作为AOP中的一个事务切面。spring源码对事务的处理逻辑，自己研究吧！

        ORM框架中以Mybatis为例，事务处理就是用到了一个类Transaction，部分源码如下

        可以看出Transaction管理的就是一个connection，而connection我们很清楚是与用户会话挂钩的。

        那么关系就是Transaction 管理Connection ，而connection与 用户session一对一存在。

        在springBoot中，只需要加入POM就可以了，配合注解使用即可。

        接下来就是事务的控制了。

        首先事务有几大传播属性：

        其中最常见的，用得最多就 PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、 PROPAGATION_NESTED 这三种。事务的传播属性是 spring 特有的，是 spring 用来控制方法事务的一种手段，说直白点就是用来控制方法是否使用同一事务的一种属性，以及按照什么规则回滚的一种手段。

        下面用代码演示这三种属性的机制：

        事务的默认属性就是required，通过Transactional.java中的Propagation propagation() default Propagation.REQUIRED; 可以看出。

        这种情况就是事务1，事务2 都加入到了事务0中。不管是1，2哪个事务抛出异常，事务0都会回滚。数据添加会失败。

        这种情况就是：

        事务0（required） {

        ​ 事务1 （REQUIRES_NEW）

        ​ 事务2

        }

        此时。

        情况a：

        1、如果只是事务2出现了异常，那么事务1会提交，事务2加入到事务0中会回滚。

        2、如果只是事务1出现了异常，那么事务1会回滚，向上层事务0抛异常，事务2会加入到事务0中，这时都会回滚。

        情况b：

        如果事务1，事务2都是REQUIRES_NEW传播属性。那么结果就是：

        1、如果事务1，抛出了异常，那么事务2是不会执行的，那么事务0必然回滚。

        2、如果事务2，抛出异常，那么事务1会提交，表中会有数据。事务2有异常回滚并抛出，事务0回滚。

        NESTED属性其实就是创建了回滚点，有异常时，会回滚到指定的回滚点。

        在这通过代码测试，出现一种情况是，无论事务1，事务2哪个有异常，数据都不会插入成功，原因是，不论是事务1还是事务2都会向事务0抛出异常，事务0捕获到异常后，执行rollback()方法，这就操作成了，事务的全部回滚。

        如果想要事务1和事务2 想要根据自己的回滚点回滚，那么事务0必须自己处理异常，不让spring捕获到这个异常，那么就满足了。把代码改成这种：

        Jack大佬提供了，伪代码分析法。

        按照Spring源码的事务处理逻辑，伪代码大致为：

Spring事务方法嵌套引发的异常与问题分析

       本文案例背景展示了在集成Spring框架的Java项目中遇到的事务异常问题，具体为`Transaction rolled back because it has been marked as rollback-only`。通过对代码逻辑的排查与源码分析，深入理解了rollback-only异常产生的原因，并提供了解决方案。本案例不仅对异常进行了详细分析，还探讨了如何避免类似问题的出现。

       在案例分析部分，我们首先通过一个简化版的测试用例，使用SpringBoot框架与Spring进行事务管理，并在Service层进行AOP事务控制。测试用例包括了事务配置类、测试类及相关的接口定义，展示了一个事务控制流程。执行测试用例时，`rollbackTest()`方法引发异常，最终抛出了rollback-only异常。

       紧接着，我们通过日志打印与源码分析，定位到异常产生的位置与原因。源码分析揭示了异常抛出的逻辑，主要涉及两个关键判断条件与Spring事务提交的逻辑。通过理解这些细节，我们了解到异常抛出是由于事务状态被标记为回滚，同时执行流程到达事务边界时引发的。

       在解决方案部分，提出了三种避免rollback-only异常的策略：修改异常处理逻辑以手动设置事务状态、修改方法名称避免事务控制、或更改事务传播属性。分析了每种方案的优劣，并最终选择了一种可行的解决方案。推荐的编程建议包括了在服务层方法间处理异常时的注意事项，旨在避免异常引发的事务问题。

       总结部分强调了理解Spring框架源码的重要性，以及在事务控制中保持清晰逻辑的必要性。通过深入分析问题，不仅解决了具体的异常问题，还为开发者提供了在服务层事务方法异常处理时的指导原则，从而提高了项目开发与维护的效率和质量。