Spring Bean生命周期之三级缓存循环依赖
文章目录
- 1 三级缓存
-
- 1.1 引言
- 1.2 三级缓存各个存放对象
- 1.3 解决循环依赖条件
-
- 1.3.1 解决循环依赖条件
- 1.3.2 Sprin中Bean的顺序
- 1.3.3 更改加载顺序
-
- 1.3.3.1 构造方法依赖 (推荐)
- 1.3.3.2 参数注入
- 1.3.3.3 @DependsOn(“xxx”)
- 1.3.3.4 BeanDefinitionRegistryPostProcessor接口
- 1.3.4 执行顺序@Order
- 1.3.5 延迟注入@Lazy
- 1.4 循环依赖示例说明
- 1.5 是否可以移除二级缓存
1 三级缓存
在使用 spring框架的日常开发中， bean之间的循环依赖太频繁了， spring已经帮我们去解决循环依赖问题，对我们开发者来说是无感知的，下面具体分析一下 spring是如何解决bean之间循环依赖，为什么要使用到三级缓存，而不是二级缓存？
点击了解 Spring Bean生命周期之概述
1.1 引言
必须先对bean的生命周期做了一个整体的流程分析，对spring如何去解决循环依赖的很有帮助。前面我们分析到填充属性时，如果发现属性还未在spring中生成，则会跑去生成属性对象实例。
我们可以看到填充属性的时候，spring会提前将已经实例化的bean通过ObjectFactory半成品暴露出去，为什么称为半成品是因为这时候的bean对象实例化，但是未进行属性填充，是一个不完整的bean实例对象
在实例化 Bean 之后，会往 singletonFactories 塞入一个工厂，而调用这个工厂的 getObject 方法，就能得到这个 Bean
spring利用singletonObjects, earlySingletonObjects, singletonFactories三级缓存去解决的，所说的缓存其实也就是三个Map
1.2 三级缓存各个存放对象
三级缓存各个存放对象：
一级缓存，singletonObjects，存储所有已创建完毕的单例 Bean （完整的 Bean）二级缓存，earlySingletonObjects，存储所有仅完成实例化，但还未进行属性注入和初始化的 Bean三级缓存，singletonFactories，存储能建立这个 Bean 的一个工厂，通过工厂能获取这个 Bean，延迟化 Bean 的生成，工厂生成的 Bean 会塞入二级缓存
这三个 map 是如何获取配合的：
- 获取单例
Bean的时候会通过BeanName先去singletonObjects（一级缓存） 查找完整的Bean，如果找到则直接返回，否则进行步骤 2。 - 看对应的
Bean是否在创建中，如果不在直接返回找不到，如果是，则会去earlySingletonObjects（二级缓存）查找 Bean，如果找到则返回，否则进行步骤 3 - 去
singletonFactories（三级缓存）通过BeanName查找到对应的工厂，如果存着工厂则通过工厂创建Bean，放置到二级缓存earlySingletonObjects中，并把三级缓存中给移除掉。 - 如果三个缓存都没找到，则返回 null
可以看到三级缓存各自保存的对象，这里重点关注二级缓存earlySingletonObjects和三级缓存singletonFactory，一级缓存可以进行忽略。前面我们讲过先实例化的bean会通过ObjectFactory半成品提前暴露在三级缓存中
singletonFactory是传入的一个匿名内部类，调用ObjectFactory.getObject()最终会调用getEarlyBeanReference方法。再来看看循环依赖中是怎么拿其它半成品的实例对象的。
1.3 解决循环依赖条件
1.3.1 解决循环依赖条件
在 Spring 中，只有同时满足以下两点才能解决循环依赖的问题：
- 必须是单例
依赖的Bean必须都是单例
因为原型模式都需要创建新的对象，不能跟用以前的对象 - 不能全是构造器注入
依赖注入的方式，必须不全是构造器注入，且beanName的字母顺序在前的不能是构造器注入
在 Spring 中创建 Bean 分三步:
实例化，createBeanInstance，就是 new 了个对象
属性注入，populateBean， 就是 set 一些属性值
初始化，initializeBean，执行一些 aware 接口中的方法，initMethod，AOP代理等
明确了上面这三点，再结合我上面说的“不完整的”，我们来理一下。
如果全是构造器注入，比如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 前面
现在我们总结一下：
- 如果循环依赖都是构造器注入，则失败
- 如果循环依赖不完全是构造器注入，则可能成功，可能失败，具体跟
BeanName的字母序有关系
1.3.2 Sprin中Bean的顺序
spring容器载入bean顺序是不确定的，在一定的范围内bean的加载顺序可以控制。
spring容器载入bean虽然顺序不确定，但遵循一定的规则：
- 按照字母顺序加载（同一文件夹下按照字母顺序；不同文件夹下，先按照文件夹命名的字母顺序加载）
- 不同的
bean声明方式不同的加载时机，顺序总结：@ComponentScan > @Import > @Bean
这里的ComponentScan指@ComponentScan及其子注解，Bean指的是@configuration + @bean - 同时需要注意的是：
Component及其子注解申明的bean是按照字母顺序加载的@configuration + @bean是按照定义的顺序依次加载的@import的顺序，就是bean的加载顺序- 在
xml中，通过bean也是按照代码的编写顺序依次加载的 - 同一类中加载顺序：
Constructor >> @Autowired >> @PostConstruct >> @Bean - 同一类中加载顺序：静态变量 / 静态代码块 >> 构造代码块 >> 构造方法（需要特别注意的是静态代码块的执行并不是优先所有的
bean加载，只是在同一个类中，静态代码块优先加载）
1.3.3 更改加载顺序
特别情况下，如果想手动控制部分bean的加载顺序，有如下方法：
1.3.3.1 构造方法依赖 (推荐)
@Component
public class CDemo1 {
private String name = "cdemo 1";
public CDemo1(CDemo2 cDemo2) {
System.out.println(name);
}
}
@Component
public class CDemo2 {
private String name = "cdemo 2";
public CDemo2() {
System.out.println(name);
}
}
CDemo2在CDemo1之前被初始化。
注意：
要有注入关系，如：CDemo2通过构造方法注入到CDemo1中，若需要指定两个没有注入关系的bean之间优先级，则不太合适（比如我希望某个bean在所有其他的Bean初始化之前执行）
循环依赖问题，如过上面的CDemo2的构造方法有一个CDemo1参数，那么循环依赖产生，应用无法启动
另外一个需要注意的点是，在构造方法中，不应有复杂耗时的逻辑，会拖慢应用的启动时间
1.3.3.2 参数注入
在@Bean标注的方法上，如果传入了参数，springboot会自动会为这个参数在spring上下文里寻找这个类型的引用。并先初始化这个类的实例。
利用此特性，我们也可以控制bean的加载顺序。
@Bean
public BeanA beanA(BeanB beanB){
System.out.println("bean A init");
return new BeanA();
}
@Bean
public BeanB beanB(){
System.out.println("bean B init");
return new BeanB();
}
以上结果，beanB先于beanA被初始化加载。
需要注意的是，springboot会按类型去寻找。如果这个类型有多个实例被注册到spring上下文，那就需要加上@Qualifier(“Bean的名称”)来指定
1.3.3.3 @DependsOn(“xxx”)
没有直接的依赖关系的，可以通过@DependsOn注解，我们可以在bean A上使用@DependsOn注解 ，告诉容器bean B应该优先被加载初始化。
不推荐的原因：这种方法是通过bean的名字（字符串）来控制顺序的，如果改了bean的类名，很可能就会忘记来改所有用到它的注解，那就问题大了。
当一个bean需要在另一个bean实例化之后再实例化时，可使用这个注解。
@Component("dependson02")
public class Dependson02 {
Dependson02(){
System.out.println(" dependson02 Success ");
}
}
@Component
@DependsOn("dependson02")
public class Dependson01 {
Dependson01(){
System.out.println("Dependson01 success");
}
}
执行结果：
dependson02 Success
Dependson01 success
1.3.3.4 BeanDefinitionRegistryPostProcessor接口
通过实现BeanDefinitionRegistryPostProcessor接口，在postProcessBeanDefinitionRegistry方法中通过BeanDefinitionRegistry获取到所有bean的注册信息，将bean保存到LinkedHashMap中，并从BeanDefinitionRegistry中删除，然后将保存的bean定义排序后，重新再注册到BeanDefinitionRegistry中，即可实现bean加载顺序的控制。
参考于：https://blog.csdn.net/u014365523/article/details/127101157
1.3.4 执行顺序@Order
注解@Order或者接口Ordered的作用是定义Spring IOC容器中Bean的执行顺序的优先级，而不是定义Bean的加载顺序，Bean的加载顺序不受@Order或Ordered接口的影响，@Order不控制Spring初始化顺序
@Order(1)：order的值越小越是最先执行，但更重要的是最先执行的最后结束
以下内容选自官网：
https://docs.spring.io/spring-framework/docs/5.3.24/reference/html/core.html#spring-core
目标
bean可以实现org.springframework.core.Ordered接口，如果希望数组或列表中的项按特定顺序排序，也可以使用@Order或标准@Priority注释。否则，它们的顺序将遵循容器中相应目标bean定义的注册顺序。
您可以在目标类级别和@Bean方法上声明@Order注释，可能用于单个bean定义(在使用相同bean类的多个定义的情况下)。@Order值可能会影响注入点的优先级，但请注意，它们不会影响单例启动顺序，这是由依赖关系和@DependsOn声明确定的正交关注点。
注意，标准的javax.annotation.Priority注释在@Bean级别上是不可用的，因为它不能在方法上声明。它的语义可以通过在每个类型的单个bean上结合@Order值和@Primary来建模。
@Component
@Order(0)
public class Test01 {
...
}
@Component
@Order(1)
public class Test02 {
...
}
@Component
@Order(2)
public class Test03 {
...
}
如上述代码所示，通过@Order注解定义优先级，3个Bean对象从IOC容器中的执行载顺序为：Test01、Test02、Test03
1.3.5 延迟注入@Lazy
假设有如下情景：
类A依赖于类B，同时类B也依赖于类A。这样就形成了循环依赖。
为了解决这个问题，还以可以使用 @Lazy 注解，将类A或类B中的其中一个延迟加载。
例如，我们可以在类A中使用 @Lazy 注解，将类A延迟加载，这样在启动应用程序时，Spring容器不会立即加载类A，而是在需要使用类A的时候才会进行加载。这样就避免了循环依赖的问题。
示例代码如下：
@Component
public class A {
private final B b;
public A(@Lazy B b) {
this.b = b;
}
//...
}
@Component
public class B {
private final A a;
public B(A a) {
this.a = a;
}
//...
}
在类A中，我们使用了 @Lazy 注解，将类B延迟加载。这样在启动应用程序时，Spring容器不会立即加载类B，而是在需要使用类B的时候才会进行加载。
这样就避免了类A和类B之间的循环依赖问题
1.4 循环依赖示例说明
我们假设现在有这样的场景AService依赖BService，BService依赖AService
AService首先实例化，实例化通过ObjectFactory半成品暴露在三级缓存中- 填充属性
BService，发现BService还未进行过加载，就会先去加载BService - 在加载
BService的过程中，实例化，也通过ObjectFactory半成品暴露在三级缓存 - 填充属性
AService，（从三级缓存通过对象⼯⼚拿到A，发现A虽然不太完善，但是存在，把A放⼊⼆级缓存，同时删除三级缓存中的A，此时，B已经实例化并且初始化完成，把B放入⼀级缓存）这时候能够从三级缓存中拿到半成品的ObjectFactory
拿到ObjectFactory对象后，调用ObjectFactory.getObject()方法最终会调用getEarlyBeanReference()方法，getEarlyBeanReference这个方法主要逻辑大概描述下如果bean被AOP切面代理则返回的是beanProxy对象，如果未被代理则返回的是原bean实例 - 接着A继续属性赋值，顺利从⼀级缓存拿到实例化且初始化完成的B对象，A对象创建也完成，删除⼆级缓存中的A，同时把A放⼊⼀级缓存
- 最后，⼀级缓存中保存着实例化、初始化都完成的A、B对象
注意： B注入的半成品A对象只是一个引用，所以之后A初始化完成后，B这个注入的A就随之变成了完整的A
1.5 是否可以移除二级缓存
我们发现这个二级缓存好像显得有点多余，好像可以去掉，只需要一级和三级缓存也可以做到解决循环依赖的问题
只要两个缓存确实可以做到解决循环依赖的问题，但是有一个前提这个bean没被AOP进行切面代理，如果这个bean被AOP进行了切面代理，那么只使用两个缓存是无法解决问题，下面来看一下bean被AOP进行了切面代理的场景
我们发现AService的testAopProxy被AOP代理了，看看传入的匿名内部类的getEarlyBeanReference返回的是什么对象。
发现singletonFactory.getObject()返回的是一个AService的代理对象，还是被CGLIB代理的。再看一张再执行一遍singletonFactory.getObject()返回的是否是同一个AService的代理对象
我们会发现再执行一遍singleFactory.getObject()方法又是一个新的代理对象，这就会有问题了，因为AService是单例的，每次执行singleFactory.getObject()方法又会产生新的代理对象。
假设这里只有一级和三级缓存的话，每次从三级缓存中拿到singleFactory对象，执行getObject()方法又会产生新的代理对象，这是不行的，因为AService是单例的，所有这里我们要借助二级缓存来解决这个问题，将执行了singleFactory.getObject()产生的对象放到二级缓存中去，后面去二级缓存中拿，没必要再执行一遍singletonFactory.getObject()方法再产生一个新的代理对象，保证始终只有一个代理对象。还有一个注意的点
既然singleFactory.getObject()返回的是代理对象，那么注入的也应该是代理对象，我们可以看到注入的确实是经过CGLIB代理的AService对象。所以如果没有AOP的话确实可以两级缓存就可以解决循环依赖的问题，如果加上AOP，两级缓存是无法解决的，不可能每次执行singleFactory.getObject()方法都给我产生一个新的代理对象，所以还要借助另外一个缓存来保存产生的代理对象