手写spring框架篇四spring三级缓存解决循环依赖问题-CFANZ编程社区

spring三级缓存解决循环依赖问题

一.什么是循环依赖

循环依赖–>循环引用。—>即2个或以上bean 互相持有对方，最终形成闭环。 eg：A依赖B，B依赖C，C又依赖A。【注意：这里不是函数的循环调用【是个死循环，除非有终结条件】，是对象相互依赖关系。

public class Main {
    public static void main(String[] args) throws Exception {
        System.out.println(new A());
    }
}
class A {
    public A() {
        new B();
    }
}
class B {
    public B() {
        new A();
    }
}

二.SPRING三级缓存

	// 从上至下 分表代表这“三级缓存”
	private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); //一级缓存
	private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); // 二级缓存
	private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); // 三级缓存
// singletonObjects：用于存放完全初始化好的 bean，从该缓存中取出的 bean 可以直接使用
// earlySingletonObjects：提前曝光的单例对象的cache，存放原始的 bean 对象（尚未填充属性），用于解决循环依赖
// singletonFactories：单例对象工厂的cache，存放 bean 工厂对象，用于解决循环依赖

先从一级缓存singletonObjects中去获取。（如果获取到就直接return）
如果获取不到或者对象正在创建中（isSingletonCurrentlyInCreation()），那就再从二级缓存earlySingletonObjects中获取。（如果获取到就直接return）
如果还是获取不到，且允许singletonFactories（allowEarlyReference=true）通过getObject()获取。就从三级缓存singletonFactory.getObject()获取。（如果获取到了就从singletonFactories中移除，并且放进earlySingletonObjects。其实也就是从三级缓存移动（是剪切、不是复制哦~）到了二级缓存）

Bean时依赖注入过程:

getBean方法肯定不陌生，必经之路，然后调用doGetBean，进来以后首先会执行transformedBeanName找别名，看你的Bean上面是否起了别名。然后进行很重要的一步，getSingleton，这段代码就是从你的单例缓存池中获取Bean的实例。那么你第一次进来肯定是没有的，缓存里肯定是拿不到的。也就是一级缓存里是没有的。那么它怎么办呢？他会尝试去二级缓存中去拿，但是去二级缓存中拿并不是无条件的，首先要判断isSingletonCurrentlyInCreation(beanName)他要看你这个对象是否正在创建当中，如果不是直接就退出该方法，如果是的话，他就会去二级缓存earlySingletonObjects里面取，如果没拿到，它还接着判断allowEarlyReference这个东西是否为true。它的意思是说，是否允许让你从单例工厂对象缓存中去拿对象。默认为true。好了，此时如果进来那么就会通过singletonFactory.getObject()去单例工厂缓存中去拿。然后将缓存级别提升至二级缓存也就早期暴露的缓存。
getSingleton执行完以后会走dependsOn方法，判断是否有dependsOn标记的循环引用，有的话直接卡死，抛出异常。比如说A依赖于B，B依赖于A 通过dependsOn注解去指定。此时执行到这里就会抛出异常。这里所指并非是构造函数的循环依赖。
beforeSingletonCreation在这里方法里，就把你的对象标记为了早期暴露的对象，提前暴露对象用于创建Bean的实例。
紧接着就走创建Bean的流程开始。在创建Bean之前执行了一下resolveBeforeInstantiation。它的意思是说，代理AOPBean定义注册信息但是这里并不是实际去代理你的对象，因为对象还没有被创建。只是代理了Bean定义信息，还没有被实例化。把Bean定义信息放进缓存，以便我想代理真正的目标对象的时候，直接去缓存里去拿。
接下来就真正的走创建Bean流程，首先走进真正做事儿的方法doCreateBean然后找到createBeanInstance这个方法，在这里面它将为你创建你的Bean实例信息（Bean的实例）。如果说创建成功了，那么就把你的对象放入缓存中去（将创建好的提前曝光的对象放入singletonFactories三级缓存中）将对象从二级缓存中移除因为它已经不是提前暴露的对象了。但是。如果说在createBeanInstance这个方法中在创建Bean的时候它会去检测你的依赖关系，会去检测你的构造器。然后，如果说它在创建A对象的时候，发现了构造器里依赖了B，然后它又会重新走getBean的这个流程，当在走到这里的时候，又发现依赖了A此时就会抛出异常。为什么会抛出异常，因为，走getBean的时候他会去从你的单例缓存池中去拿，因为你这里的Bean还没有被创建好。自然不会被放进缓存中，所以它是在缓存中拿不到B对象的。反过来也是拿不到A对象的。造成了死循环故此直接抛异常。这就是为什么Spring IOC不能解决构造器循环依赖的原因。因为你还没来的急放入缓存你的对象是不存在的。所以不能创建。同理@Bean标注的循环依赖方法也是不能解决的，跟这个同理。那么多例就更不能解决了。为什么？因为在走createBeanInstance的时候，会判断是否是单例的Bean定义信息mbd.isSingleton()；如果是才会进来。所以多例的Bean压根就不会走进来，而是走了另一段逻辑，这里不做介绍。至此，构造器循环依赖和@Bean的循环依赖还有多例Bean的循环依赖为什么不能解决已经解释清楚。然后如果说，Bean创建成功了。那么会走后面的逻辑。
将创建好的Bean放入缓存，addSingletonFactory方法就是将你创建好的Bean放入三级缓存中，并且移除早期暴露的对象。
通过populateBean给属性赋值，我们知道，创建好的对象，并不是一个完整的对象，里面的属性还没有被赋值。所以这个方法就是为创建好的Bean为它的属性赋值。并且调用了我们实现的的XXXAware接口进行回调初始化，然后调用我们实现的Bean的后置处理器，给我们最后一次机会去修改Bean的属性。