Spring为何要用三级缓存来解决循环依赖问题
我们都知道Spring为了解决循环依赖使用了三级缓存
Spring三级缓存
一级缓存singletonObjects
用于保存BeanName和创建bean实例之间的关系,beanName -> bean instance
private final Map<String, Object> singletonObjects = new ConcurrentHashMap(256);
二级缓存earlySingletonObjects
保存提前曝光的单例bean对象
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
三级缓存singletonFactories
保存beanName和创建bean实例之间的关系,与singletonObjects不同的地方在于,当一个单例bean被放到这里面后,bean在创建过程中,可以通过getBean方法获取到,目的是用来检测循环引用
private final Map<String, Object> singletonFactories = new HashMap(16);
在创建bean的时候,首先从缓存中获取单例的bean,这个缓存就是singletonObjects,如果获取不到且bean正在创建中,就再从earlySingletonObjects中获取,如果还是获取不到且允许从singletonFactories中通过getObject拿到对象,就从singletonFactories中获取,如果获取到了就存入earlySingletonObjects并从singletonFactories中移除。
为什么要使用三级缓存?
一级缓存
首先我们看看一级缓存行不行,如果只留第一级缓存,那么单例的Bean都存在singletonObjects 中,Spring循环依赖主要基于Java引用传递,当获取到对象时,对象的field或者属性可以延后设置,理论上可以,但是如果延后设置出了问题,就会导致完整的Bean和不完整的Bean都在一级缓存中,这个引用时就有空指针的可能,所以一级缓存不行,至少要有singletonObjects 和earlySingletonObjects 两级。
两级缓存
那么我们再看看两级缓存行不行
现在有A的field或者setter依赖B的实例对象,同时B的field或者setter依赖了A的实例,A首先开始创建,并将自己暴露到 earlySingletonObjects 中,开始填充属性,此时发现自己依赖B的属性,尝试去get(B),发现B还没有被创建,所以开始创建B,在进行属性填充时初始化A,就从earlySingletonObjects 中获取到了实例化但没有任何属性的A,B拿到A后完成了初始化阶段,将自己放到singletonObjects中,此时返回A,A拿到B的对象继续完成初始化,完成后将自己放到singletonObjects中,由A与B中所表示的A的属性地址是一样的,所以A的属性填充完后,B也获取了A的属性,这样就解决了循环的问题。
似乎完美解决,如果就这么使用的话也没什么问题,但是再加上AOP情况就不同了,被AOP增强的Bean会在初始化后代理成为一个新的对象,也就是说:
如果有AOP,A依赖于B,B依赖于A,A实例化完成暴露出去,开始注入属性,发现引用B,B开始实例化,使用A暴露的对象,初始化完成后封装成代理对象,A再将代理后的B注入,再做代理,那么代理A中的B就是代理后的B,但是代理后的B中的A是没用代理的A。
显然这是不对的,所以在Spring中存在第三级缓存,在创建对象时判断是否是单例,允许循环依赖,正在创建中,就将其从earlySingletonObjects中移除掉,并在singletonFactories放入新的对象,这样后续再查询beanName时会走到singletonFactory.getObject(),其中就会去调用各个beanPostProcessor的getEarlyBeanReference方法,返回的对象就是代理后的对象。
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory implements AutowireCapableBeanFactory { // Eagerly cache singletons to be able to resolve circular references // even when triggered by lifecycle interfaces like BeanFactoryAware. boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { if (logger.isDebugEnabled()) { logger.debug("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references"); } addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); } /** * Add the given singleton factory for building the specified singleton * if necessary. * <p>To be called for eager registration of singletons, e.g. to be able to * resolve circular references. * @param beanName the name of the bean * @param singletonFactory the factory for the singleton object */ 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); } } }
总结
到此这篇关于Spring为何要用三级缓存来解决循环依赖问题的文章就介绍到这了,更多相关Spring用三级缓存解决循环依赖内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!