Spring为何要用三级缓存来解决循环依赖问题

2023-07-13 08:37:03 278

我们都知道Spring为了解决循环依赖使用了三级缓存

Spring三级缓存

一级缓存singletonObjects

用于保存BeanName和创建bean实例之间的关系,beanName->beaninstance

privatefinalMapsingletonObjects=newConcurrentHashMap(256);

二级缓存earlySingletonObjects

保存提前曝光的单例bean对象

privatefinalMapearlySingletonObjects=newHashMap<>(16);

三级缓存singletonFactories

保存beanName和创建bean实例之间的关系,与singletonObjects不同的地方在于，当一个单例bean被放到这里面后，bean在创建过程中，可以通过getBean方法获取到,目的是用来检测循环引用

privatefinalMapsingletonFactories=newHashMap(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方法，返回的对象就是代理后的对象。

publicabstractclassAbstractAutowireCapableBeanFactoryextendsAbstractBeanFactory
implementsAutowireCapableBeanFactory{

//Eagerlycachesingletonstobeabletoresolvecircularreferences
//evenwhentriggeredbylifecycleinterfaceslikeBeanFactoryAware.
booleanearlySingletonExposure=(mbd.isSingleton()&&this.allowCircularReferences&&
isSingletonCurrentlyInCreation(beanName));
if(earlySingletonExposure){
if(logger.isDebugEnabled()){
logger.debug("Eagerlycachingbean'"+beanName+
"'toallowforresolvingpotentialcircularreferences");
}
addSingletonFactory(beanName,()->getEarlyBeanReference(beanName,mbd,bean));
}

/**
*Addthegivensingletonfactoryforbuildingthespecifiedsingleton
*ifnecessary.
*Tobecalledforeagerregistrationofsingletons,e.g.tobeableto
*resolvecircularreferences.
*@parambeanNamethenameofthebean
*@paramsingletonFactorythefactoryforthesingletonobject
*/
protectedvoidaddSingletonFactory(StringbeanName,ObjectFactorysingletonFactory){
Assert.notNull(singletonFactory,"Singletonfactorymustnotbenull");
synchronized(this.singletonObjects){
if(!this.singletonObjects.containsKey(beanName)){
this.singletonFactories.put(beanName,singletonFactory);
this.earlySingletonObjects.remove(beanName);
this.registeredSingletons.add(beanName);
}
}
}

总结

到此这篇关于Spring为何要用三级缓存来解决循环依赖问题的文章就介绍到这了,更多相关Spring用三级缓存解决循环依赖内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！

声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。

Spring为何要用三级缓存来解决循环依赖问题

热门推荐

随机推荐