详情请查看：Spring 事务
事务就是一系列的操作原子执行。Spring事务机制主要包括声明式事务和编程式事务。
@Transactional 注解开启声明式事务。@Transactional相关属性如下：
| 属性 | 类型 | 描述 |
|---|---|---|
| value | String | 可选的限定描述符，指定使用的事务管理器 |
| propagation | enum: Propagation | 可选的事务传播行为设置 |
| isolation | enum: Isolation | 可选的事务隔离级别设置 |
| readOnly | boolean | 读写或只读事务，默认读写 |
| timeout | int (in seconds granularity) | 事务超时时间设置 |
| rollbackFor | Class对象数组，必须继承自Throwable | 导致事务回滚的异常类数组 |
| rollbackForClassName | 类名数组，必须继承自Throwable | 导致事务回滚的异常类名字数组 |
| noRollbackFor | Class对象数组，必须继承自Throwable | 不会导致事务回滚的异常类数组 |
| noRollbackForClassName | 类名数组，必须继承自Throwable | 不会导致事务回滚的异常类名字数组 |
Spring的事务隔离级别是指在并发环境下，事务之间相互隔离的程度。Spring框架支持多种事务隔离级别，可以根据具体的业务需求来选择适合的隔离级别。以下是常见的事务隔离级别：
通过@Transactional注解的isolation属性来指定事务隔离级别。
在TransactionDefinition接口中定义了七个事务传播行为：
PROPAGATION_REQUIRED如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。如果嵌套调用的两个方法都加了事务注解，并且运行在相同线程中，则这两个方法使用相同的事务中。如果运行在不同线程中，则会开启新的事务。PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果不存在事务，则抛出异常IllegalTransactionStateException。PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。需要使用JtaTransactionManager作为事务管理器。PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。需要使用JtaTransactionManager作为事务管理器。PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常。PROPAGATION_NESTED 如果一个活动的事务存在，则运行在一个嵌套的事务中。如果没有活动事务, 则按PROPAGATION_REQUIRED 属性执行。PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别:
使用PROPAGATION_REQUIRES_NEW时，内层事务与外层事务是两个独立的事务。一旦内层事务进行了提交后，外层事务不能对其进行回滚。两个事务互不影响。
使用PROPAGATION_NESTED时，外层事务的回滚可以引起内层事务的回滚。而内层事务的异常并不会导致外层事务的回滚，它是一个真正的嵌套事务。
主要作用是定义和管理事务边界，尤其是一个事务方法调用另一个事务方法时，事务如何传播的问题。它解决了多个事务方法嵌套执行时，是否要开启新事务、复用现有事务或者挂起事务等复杂情况。
总结用途：
Spring的声明式事务其实也是通过AOP的这一套底层实现原理实现的，都是通过同一个bean的后置处理器来完成的动态代理创建的，只是：
在执行事务的bean的时候会先执行动态代理的增强类， 在执行目标方法前进行异常捕捉，出现异常回滚事务， 无异常提交事务。
之所以会失效是因为@Transactional 注解依赖于Spring AOP切面来增强事务行为，这个 AOP 是通过代理来实现的
而无论是JDK动态代理还是CGLIB代理，Spring AOP的默认行为都是只代理public方法。
和上边的原因类似，被用 final 、static 修饰的方法上加 @Transactional 也不会生效。
比如有一个类Test，它的一个方法A，A再调用本类的方法B（不论方法B是用public还是private修饰），但方法A没有声明注解事务，而B方法有。则外部调用方法A之后，方法B的事务是不会起作用的。
那为啥会出现这种情况？其实这还是由于使用Spring AOP代理造成的，因为只有当事务方法被当前类以外的代码调用时，才会由Spring生成的代理对象来管理。
但是如果是A声明了事务，A的事务是会生效的。
上边我们知道 @Transactional 注解通过 AOP 来管理事务，而 AOP 依赖于代理机制。因此，Bean 必须由Spring管理实例！ 要确保为类加上如 @Controller、@Service 或 @Component注解，让其被Spring所管理，这很容易忽视。
如果我们在 testMerge() 方法中使用异步线程执行事务操作，通常也是无法成功回滚的，来个具体的例子。
假设testMerge() 方法在事务中调用了 testA()，testA() 方法中开启了事务。接着，在 testMerge() 方法中，我们通过一个新线程调用了 testB()，testB() 中也开启了事务，并且在 testB() 中抛出了异常。此时，testA() 不会回滚 和 testB() 回滚。
testA() 无法回滚是因为没有捕获到新线程中 testB()抛出的异常；testB()方法正常回滚。
在多线程环境下，Spring 的事务管理器不会跨线程传播事务，事务的状态（如事务是否已开启）是存储在线程本地的 ThreadLocal 来存储和管理事务上下文信息。这意味着每个线程都有一个独立的事务上下文，事务信息在不同线程之间不会共享。
事务能否生效数据库引擎是否支持事务是关键。常用的MySQL数据库默认使用支持事务的innodb引擎。一旦数据库引擎切换成不支持事务的myisam，那事务就从根本上失效了。
在多线程环境下，Spring事务管理默认情况下无法保证全局事务的一致性。这是因为Spring的本地事务管理是基于线程的，每个线程都有自己的独立事务。
总之，在多线程环境中，Spring的本地事务管理需要额外的协调和管理才能实现事务一致性。这可以通过编程式事务、分布式事务管理器或二阶段提交等方式来实现，具体取决于您的应用程序需求和复杂性。
但在 Seata 框架中，事务一致性是通过分布式事务协调器（TC）来保证的。TC 负责协调分布式事务的各个参与者（RM），确保它们按照相同的顺序执行事务操作，从而保证事务的一致性。 具体来说，当一个事务开始时，TC 会生成一个全局事务 ID（XID），并将其传播给所有的 RM。每个 RM 在执行事务操作时，都会将自己的操作记录到本地事务日志中，并将 XID 和操作记录发送给 TC。TC 会根据 XID 和操作记录，协调各个 RM 的执行顺序，确保它们按照相同的顺序执行事务操作。如果在执行过程中出现异常，TC 会根据事务回滚策略，决定是否回滚事务。 通过这种方式，Seata 框架可以保证分布式事务的一致性，即使在多个节点之间进行事务操作，也可以确保数据的一致性和可靠性。（了解）
Exception 分为运行时异常 RuntimeException 和非运行时异常。事务管理对于企业应用来说是至关重要的，即使出现异常情况，它也可以保证数据的一致性。
当 @Transactional 注解作用于类上时，该类的所有 public 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。
@Transactional 注解默认回滚策略是只有在遇到RuntimeException(运行时异常) 或者 Error 时才会回滚事务，而不会回滚 Checked Exception（受检查异常）。这是因为 Spring 认为RuntimeException和 Error 是不可预期的错误，而受检异常是可预期的错误，可以通过业务逻辑来处理。
循环依赖(Circular Dependency)是指两个或多个模块，组件之间相互依赖形成一个闭环。简而言之，
模块A依赖模块B，而模块B又依赖于模块A。这会导依赖链的循环，无法确定加载或初始化的顺序。
解决步骤：
详细内容如下：
首先，有两种Bean注入的方式。
构造器注入和属性注入。
BeanCurrentlylnCreationException异常。而非单例对象的循环依赖，则无法处理。
下面分析单例模式下属性注入的循环依赖是怎么处理的：
首先，Spring单例对象的初始化大略分为三步：
createBeanInstance：实例化bean，使用构造方法创建对象，为对象分配内存。populateBean：进行依赖注入。initializeBean：初始化bean。Spring为了解决单例的循环依赖问题，使用了三级缓存：
singletonObjects：完成了初始化的单例对象map，bean name --> bean instance，存完整单例bean。earlySingletonObjects ：完成实例化未初始化的单例对象map，bean name --> bean instance，存放的是早期的bean，即半成品，此时还无法使用（只用于循环依赖提供的临时bean对象）。singletonFactories (循环依赖的出口，解决了循环依赖)： 单例对象工厂map，bean name --> ObjectFactory，单例对象实例化完成之后会加入singletonFactories。它存的是一个对象工厂，用于创建对象并放入二级缓存中。同时，如果对象有Aop代理，则对象工厂返回代理对象。这三个 map 是如何配合的呢?
从上面的步骤我们可以得知，如果查询发现 Bean 还未创建，到第二步就直接返回 null，不会继续查二级和三级缓存。返回 null 之后，说明这个Bean 还未创建，这个时候会标记这个 Bean 正在创建中，然后再调用 createBean 来创建 Bean，而实际创建是调用方法 doCreateBean。
在调用createBeanInstance进行实例化之后，会调用addSingletonFactory，将单例对象放到singletonFactories中。
protected void addSingletonFactory(String beanName, ObjectFactory> singletonFactory) {
Assert.notNull(singletonFactory, "Singleton factory must not be null");
synchronized (this.singletonObjects) {
if (!this.singletonObjects.containsKey(beanName)) {
this.singletonFactories.put(beanName, singletonFactory);
this.earlySingletonObjects.remove(beanName);
this.registeredSingletons.add(beanName);
}
}
}
假如A依赖了B的实例对象，同时B也依赖A的实例对象。
由此看出，属性注入的循环依赖主要是通过将实例化完成的bean添加到singletonFactories来实现的。而使用构造器依赖注入的bean在实例化的时候会进行依赖注入，不会被添加到singletonFactories中。比如A和B都是通过构造器依赖注入，A在调用构造器进行实例化的时候，发现自己依赖B，B没有被实例化，就会对B进行实例化，此时A未实例化完成，不会被添加到singtonFactories。而B依赖于A，B会去三级缓存寻找A对象，发现不存在，于是又会实例化A，A实例化了两次，从而导致抛异常。
总结：1、利用缓存识别已经遍历过的节点； 2、利用Java引用，先提前设置对象地址，后完善对象。
如果从源码来看的话，循环依赖的 Bean 是原型模式，会直接抛错：
所以 Spring 只支持单例的循环依赖，但是为什么呢?
按照理解，如果两个Bean都是原型模式的话，那么创建A1需要创建一个B1，创建B1的时候要创建一个A2，创建 A2又要创建一个B2，创建 B2又要创建一个A3，创建 A3 又要创建一个 B3.就又卡 BUG 了，是吧，因为原型模式都需要创建新的对象，不能跟用以前的对象。
如果是单例的话，创建 A 需要创建 B，而创建的 B 需要的是之前的个 A，不然就不叫单例了，对吧?
也是基于这点， Spring 就能操作操作了。
具体做法就是：先创建A，此时的A是不完整的(没有注入B)，用个 map 保存这个不完整的A，再创建B，B需要A，所以从那个map 得到“不完整”的A，此时的B就完整了，然后A就可以注入B，然后A就完整了，B也完整了，且它们是相互依赖的。
为什么不能全是构造器注入？
在 Spring 中创建 Bean 分三步：
明确了上面这三点，再结合上面说的“不完整的”，我们来理一下。
如果全是构造器注入，比如A(B b)，那表明在 new的时候，就需要得到B，此时需要 new B，但是B也是要在构造的时候注入A，即B(A a)，这时候B需要在一个 map 中找到不完整的A，发现找不到。
为什么找不到?因为A 还没 new 完呢，所以找不到完整的 A，因此如果全是构造器注入的话，那么 Spring 无法处理循环依赖。
一个set注入，一个构造器注入一定能成功?
假设我们 A 是通过 set 注入 B，B 通过构造函数注入 A，此时是成功的。
我们来分析下：实例化A之后，此时可以在 map中存入A，开始为A进行属性注入，发现需要B，此时 new B，发现构造器需要A，此时从 map中得到A，B构造完毕，B进行属性注入，初始化，然后A注入B完成属性注入，然后初始化 A。
整个过程很顺利，没毛病。
假设 A 是通过构造器注入 B，B 通过 set 注入 A，此时是失败的。
我们来分析下：实例化A，发现构造函数需要B，此时去实例化B，然后进行B 的属性注入，从 map 里面找不到A，因为 A 还没 new 成功，所以B也卡住了，然后就 循环了。
看到这里，仔细思考的小伙伴可能会说，可以先实例化 B，往 map 里面塞入不完整的 B，这样就能成功实例化 A 了。确实，思路没错但是 Spring 容器是按照字母序创建 Bean 的，A 的创建永远排在 B 前面。
现在我们总结一下:
Spring 之所以需要三级缓存而不是简单的二级缓存，主要原因在于AOP代理和Bean的早期引用问题。
没有关系！
本文来自在线网站：seven的菜鸟成长之路，作者：seven，转载请注明原文链接：www.seven97.top
登录查看全部
参与评论
手机查看
返回顶部