关于springboot:Spring三级缓存和循环依赖

1. 循环依赖

什么是依赖注入？假如有两个类A和B，A在实例化的时候须要B的实例，而B在实例化时又须要A的实例，在类的实例化过程就陷入死循环。这也就是传统逻辑上的，“到底是先有鸡，还是先有蛋”的问题？
上面举一个例子,定义了两个类Type和Org：

// Org.java@Data@Componentpublic class Org {    private final Role role;    public Org(Role role) {        this.role = role;    }}// Role.java@Data@Componentpublic class Role {    private final Org org;    public Role(Org org) {        this.org = org;    }}

这是spring中典型的结构器注入形式，其实也代表了一般非spring bean之间，相互依赖时的实例化过程，但后果在运行的时候间接报循环依赖的谬误：

***************************APPLICATION FAILED TO START***************************Description:The dependencies of some of the beans in the application context form a cycle:   demoController (field private pers.kerry.exercise.springexercise.pojo.Org pers.kerry.exercise.springexercise.controller.DemoController.org)┌─────┐|  org defined in file [/Users/kerry/code/idea/spring-exercise/target/classes/pers/kerry/exercise/springexercise/pojo/Org.class]↑     ↓|  role defined in file [/Users/kerry/code/idea/spring-exercise/target/classes/pers/kerry/exercise/springexercise/pojo/Role.class]└─────┘

而如果咱们改一下代码，把结构器注入形式改成基于属性的注入（@Autowired、@Resouce），奇怪的是不报错了，而且相互依赖的两个bean 都实例化胜利了。阐明spring框架有解决循环依赖的问题，咱们理解spring解决循环依赖的过程，其实有助于进一步理解spring 中 bean的流动过程。

2. 三级缓存

咱们在之前介绍Bean的生命周期时说过，spring 中 bean的实例化过程，并非只是调用构造方法。除去spring框架自身提供的一些钩子或扩大办法，简略分成上面三个外围办法：

Spring在创立Bean的过程中分为三步

1. 实例化，对应办法：AbstractAutowireCapableBeanFactory中的createBeanInstance办法，简略了解就是new了一个对象。
2. 属性注入，对应办法：AbstractAutowireCapableBeanFactory的populateBean办法，为实例化中new进去的对象填充属性和注入依赖。
3. 初始化，对应办法：AbstractAutowireCapableBeanFactory的initializeBean，执行aware接口中的办法，初始化办法，实现AOP代理。

从单例Bean的初始化来看，次要可能产生循环依赖的环节就在第二步populate。值得注意的是，基于构造方法注入的形式，其实是将第一步和第二步同时进行，因而马上就抛出谬误。而spring通过基于属性注入的形式，是否有其余非凡的解决呢，咱们这时候就要提到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);

3. 外围办法：getSingleton

咱们在获取bean实例的时候，其实是先从三级缓存中获取，getBean 办法的逻辑如下：

Object sharedInstance = getSingleton(beanName);public Object getSingleton(String beanName) {    return getSingleton(beanName, true);}protected Object getSingleton(String beanName, boolean allowEarlyReference) {    // 查问缓存中是否有创立好的单例    Object singletonObject = this.singletonObjects.get(beanName);    // 如果缓存不存在，判断是否正在创立中    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {        // 加锁避免并发        synchronized (this.singletonObjects) {            // 从earlySingletonObjects中查问是否有early缓存            singletonObject = this.earlySingletonObjects.get(beanName);            // early缓存也不存在，且容许early援用            if (singletonObject == null && allowEarlyReference) {                // 从单例工厂Map里查问beanName                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);                if (singletonFactory != null) {                    // singletonFactory存在，则调用getObject办法拿到单例对象                    singletonObject = singletonFactory.getObject();                    // 将单例对象增加到early缓存中                    this.earlySingletonObjects.put(beanName, singletonObject);                    // 移除单例工厂中对应的singletonFactory                    this.singletonFactories.remove(beanName);                }            }        }    }    return (singletonObject != NULL_OBJECT ? singletonObject : null);}

1. 只针对单例的bean，多例的前面探讨
2. 默认的singletonObjects缓存不存在要get的beanName时，判断beanName是否正在创立中
3. 从early缓存earlySingletonObjects中再查问，early缓存是用来缓存已实例化但未组装实现的bean
4. 如果early缓存也不存在，从singletonFactories中查找是否有beanName对应的ObjectFactory对象工厂
5. 如果对象工厂存在，则调用getObject办法拿到bean对象
6. 将bean对象退出early缓存，并移除singletonFactories的对象工厂

这是 getBean的逻辑，三级缓存中一级一级地找匹配的Bean，直到最初一级缓存，通过匹配beanName 的 ObjectFactory 来获取Bean。那么singletonFactories何时放入了能够通过getObject取得bean对象的ObjectFactory呢？

4. 外围办法：doCreateBean

Bean的实例化，理论执行的源码是AbstractAutowireCapableBeanFactory类的doCreateBean办法：

 protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) throws BeanCreationException {        // 1、创立一个对bean原始对象的包装对象-BeanWrapper，执行createBeanInstance，即构造方法或工厂办法，给BeanWrapper赋值        BeanWrapper instanceWrapper = null;        if (mbd.isSingleton()) {            instanceWrapper = (BeanWrapper)this.factoryBeanInstanceCache.remove(beanName);        }        if (instanceWrapper == null) {            instanceWrapper = this.createBeanInstance(beanName, mbd, args);        }        Object bean = instanceWrapper.getWrappedInstance();        Class<?> beanType = instanceWrapper.getWrappedClass();        if (beanType != NullBean.class) {            mbd.resolvedTargetType = beanType;        }        // 2、容许其余批改beanDefinition，如应用Annotation加强Bean定义等，这通过类MergedBeanDefinitionPostProcessor来实现        synchronized(mbd.postProcessingLock) {            if (!mbd.postProcessed) {                try {                    this.applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);                } catch (Throwable var17) {                    throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Post-processing of merged bean definition failed", var17);                }                mbd.postProcessed = true;            }        }        // 3、将以后bean 的 ObjetFactory放入singletonFactories中，         boolean earlySingletonExposure = mbd.isSingleton() && this.allowCircularReferences && this.isSingletonCurrentlyInCreation(beanName);        if (earlySingletonExposure) {            if (this.logger.isTraceEnabled()) {                this.logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");            }            this.addSingletonFactory(beanName, () -> {                return this.getEarlyBeanReference(beanName, mbd, bean);            });        }        Object exposedObject = bean;        // 4、执行 populateBean，设置属性值        // 5、执行 initializeBean，调用 Bean的初始化办法        try {            this.populateBean(beanName, mbd, instanceWrapper);            exposedObject = this.initializeBean(beanName, exposedObject, mbd);        } catch (Throwable var18) {            if (var18 instanceof BeanCreationException && beanName.equals(((BeanCreationException)var18).getBeanName())) {                throw (BeanCreationException)var18;            }            throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Initialization of bean failed", var18);        }        // 6、再次解决循环依赖问题        if (earlySingletonExposure) {            Object earlySingletonReference = this.getSingleton(beanName, false);            if (earlySingletonReference != null) {                if (exposedObject == bean) {                    exposedObject = earlySingletonReference;                } else if (!this.allowRawInjectionDespiteWrapping && this.hasDependentBean(beanName)) {                    String[] dependentBeans = this.getDependentBeans(beanName);                    Set<String> actualDependentBeans = new LinkedHashSet(dependentBeans.length);                    String[] var12 = dependentBeans;                    int var13 = dependentBeans.length;                    for(int var14 = 0; var14 < var13; ++var14) {                        String dependentBean = var12[var14];                        if (!this.removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {                            actualDependentBeans.add(dependentBean);                        }                    }                    if (!actualDependentBeans.isEmpty()) {                        throw new BeanCurrentlyInCreationException(beanName, "Bean with name '" + beanName + "' has been injected into other beans [" + StringUtils.collectionToCommaDelimitedString(actualDependentBeans) + "] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");                    }                }            }        }        // 7、注册bean的销毁回调办法，在beanFactory中注册销毁告诉，以便在容器销毁时，可能做一些后续解决工作        try {            this.registerDisposableBeanIfNecessary(beanName, bean, mbd);            return exposedObject;        } catch (BeanDefinitionValidationException var16) {            throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Invalid destruction signature", var16);        }    }

BeanWrapper

BeanWrapper接口，作为spring外部的一个外围接口，正如其名，它是bean的包裹类，即在外部中将会保留该bean的实例，提供其它一些扩大性能。同时，BeanWrapper接口还继承了PropertyAccessor, propertyEditorRegistry, TypeConverter、ConfigurablePropertyAccessor接口，所以它还提供了拜访bean的属性值、属性编辑器注册、类型转换等性能。

咱们回顾一下bean的实例化过程：

1. ResourceLoader加载配置信息
2. BeanDefinitionReader读取并解析<bean>标签，并将<bean>标签的属性转换为BeanDefinition对应的属性，并注册到BeanDefinitionRegistry注册表中。
3. 容器扫描BeanDefinitionRegistry注册表，通过反射机制获取BeanFactoryPostProcessor类型的工厂后处理器，并用这个工厂后处理器对BeanDefinition进行加工。
4. 依据解决过的BeanDefinition，实例化bean。而后BeanWrapper联合BeanDefinitionRegistry和PropertyEditorRegistry对Bean的属性赋值。

4. 思考和总结

4.1. 问题：多例的循环依赖能够解决吗

单例bean的循环援用是因为每个对象都是固定的，只是提前裸露对象的援用，最终这个援用对应的对象是创立实现的。然而多例的状况下，每次getBean都会创立一个新的对象，那么应该援用哪一个对象呢，这自身就曾经是矛盾的了。多实例Bean是每次创立都会调用doGetBean办法，基本没有应用一二三级缓存，必定不能解决循环依赖。因此spring中对于多例之间互相援用是会提醒谬误的。

Error creating bean with name 'beanA': Requested bean is currently in creation: Is there an unresolvable circular reference?

可见spring会认为多例之间的循环援用是无奈解决的。

4.2. 问题：结构器、setter注入形式的循环依赖能够解决吗

这里还是拿A和B两个Bean举例说明：

4.3. 问题：为什么是三级缓存，二级不行吗？

咱们再整顿一下spring解决循环依赖的过程：一级缓存singletonObject存储成品的Bean，二级缓存earlySingletonObject存储半成品的Bean，当呈现循环依赖时能够先注入earlySingletonObject中的Bean实例。那三级缓存singletonFactory存在的意义何在？

singletonFactory 存储的对象工厂是 ObjectFactory，这是一个函数式接口，惟一形象办法是getObject。在doCreateBean办法的第三步addSingletonFactory，往singletonFactory增加ObjectFactory的匿名外部类中，返回对象的办法是getEarlyBeanReference。

this.addSingletonFactory(beanName, () -> {                return this.getEarlyBeanReference(beanName, mbd, bean);            });

咱们再看看 getEarlyBeanReference 的办法实现：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {    Object exposedObject = bean;    if (bean != null && !mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {        for (BeanPostProcessor bp : getBeanPostProcessors()) {            if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {                SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);                if (exposedObject == null) {                    return exposedObject;                }            }        }    }    return exposedObject;}

这里也设置了一个InstantiationAwareBeanPostProcessor后置处理器的扩大点，容许在对象返回之前批改甚至替换bean，总的来说，这是某一AOP办法的实现步骤。因而如果存在 AOP的定义，singletonFactory返回的不是原始的Bean实例，而是实现AOP办法的代理类。

那么如果在doCreateBean办法中，间接生成Bean基于AOP的代理对象，将代理对象存入二级缓存earlySingleton，是不是还是能够不须要三级缓存singletonFactory呢？

如果这么做了，就把AOP中创立代理对象的机会提前了，不论是否产生循环依赖，都在doCreateBean办法中实现了AOP的代理。不仅没有必要，而且违反了Spring在联合AOP跟Bean的生命周期的设计！Spring联合AOP跟Bean的生命周期自身就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来实现的，在这个后置解决的postProcessAfterInitialization办法中对初始化后的Bean实现AOP代理。如果呈现了循环依赖，那没有方法，只有给Bean先创立代理，然而没有呈现循环依赖的状况下，设计之初就是让Bean在生命周期的最初一步实现代理而不是在实例化后就立马实现代理。

因而在三级缓存的架构中，earlySingletonObject 和 singletonFactory 的意义在于：

• 三级缓存singletonFactory：裸露ObjectFactory目标是为了实现AOP代理。对象工厂分明如何创建对象的AOP代理，然而不会立马创立，而是到适合的机会进行AOP代理对象的创立。
• 二级缓存earlySingletonObject：存在的目标之一是保障对象只有一次AOP代理。当调用三级缓存的getObject()办法返回的对象会存入二级缓存，这样，当接下来的依赖者调用的时候， 会先判断二级缓存是否有指标对象，如果存在间接返回。

4.4. 总结

咱们再回顾spring中循环依赖的解决流程，网上看到一个流程图很能清晰的阐明其中过程。

Spring通过三级缓存解决了循环依赖。一级缓存为单例池，二级缓存为晚期曝光对象，三级缓存为晚期曝光对象工厂。当A、B两类产生循环援用，在A实例化之后，将本人提前曝光(即退出三级缓存)，如果A初始AOP代理，该工厂对象返回的是被代理的对象，若未被代理，返回对象自身。当A进行属性注入时，通过之前实例化步骤，此时轮到B属性注入，调用getBean(a)获取A对象，因为A解决正在创立汇合中，此时也发了循环依赖，所以能够从三级缓存获取对象工厂(如果A被AOP代理，此时返回就是代理对象)，并把对象放到二级缓存中，这样保障A只通过一次AOP代理。接下来，B走完Spring生命周期流程，并放入单例池中。当B创立完后，会将B注入A，A走完Spring生命周期流程。到此，循环依赖完结。