循环依赖如下图所示:
对应的spring代码形式如下:
@Component
public class A {
@Autowired
private B b;
}
@Component
public class B {
@Autowired
private C c;
}
@Component
public class C {
@Autowired
private A a;
}
又或者:
对应的spring代码形式如下:
@Component
public class A {
@Autowired
private A a;
}
上面展示的循环依赖都是Spring可以解决的,但是对于构造器的循环依赖注入,Spring无法解决,会抛出异常:
@Component
public class A {
private B b;
public A(B b) {
this.b = b;
}
}
@Component
public class B {
private A a;
public B(A a) {
this.a = a;
}
}
对于Prototype类型的bean来说,如果存在循环引用也是会直接抛出异常结束
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class A {
@Autowired
private B b;
}
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class B {
@Autowired
private A a;
}
在正式研究Spring如何解决循环依赖之前,不如我们就假设spring目前没有提供三级缓存来解决循环依赖,那么目前spring的getBean流程图就如下所示:
getBean总共就三个大的阶段:
对于Spring而言,循环依赖会发生在第二步,即属性注入的过程,因此我们要想办法在属性注入前将当前Bean依赖的其他bean都进行创建。
在属性注入环节,如果发现当前bean依赖于其他bean,那么会去创建对应的bean.
不妨思考下面这个流程:
大家可以思考一下,如何解决上面这个死循环.
这里提前暴露的意思就是将已经实例化bean但是还没有赋值的bean实例放到一个缓存池中,可以让其他bean在需要当前bean,但是当前bean还没初始化完的情况下,先引用这个暴露的bean
注意: 暴露出去的是这个bean对象的引用,因此该bean后续的属性注入的修改都是在同一块内存上完成的。
添加了提前暴露的缓存池后,循环引用的流程就变成了下面这样子:
还有一点大家可以看出来,因为必须在实例化后,当前bean对象才会被提前放入缓存池中,因此构造器造成的循环依赖无法解决
可以看到此时循环引用的问题就已经被解决了,但是我们给出的解决方案还存在诸多问题,但是思路是正确的,那么下面来看看Spring是如何完美解决bean的循环依赖的吧。
我们上面只使用了二级缓存,即一个单例缓存池和一个提前暴露的单例缓存池,但是spring在此基础上多加了一个缓存池,并且具体的使用上也和我们上面讲的有点区别:
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
...
// 从上至下 分表代表这“三级缓存”
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); // 三级缓存
...
//用来记录正在创建的单例bean有哪些,当bean创建完毕后,会从该集合中移除
private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<>(16));
//标记已经创建完毕的bean有哪些
private final Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256));
}
三级缓存的作用分别如下:
下面跟随我的脚本一起来看看getBean过程中三级缓存是如何发挥作用并巧妙解决循环依赖问题的吧:
protected <T> T doGetBean(
String name, @Nullable Class<T> requiredType, @Nullable Object[] args, boolean typeCheckOnly)
throws BeansException {
String beanName = transformedBeanName(name);
Object beanInstance;
//查询三级缓存
Object sharedInstance = getSingleton(beanName);
//如果缓存中存在,就直接返回
if (sharedInstance != null && args == null) {
...
//对FactoryBean的返回值做处理
beanInstance = getObjectForBeanInstance(sharedInstance, name, beanName, null);
}
else {
//如果当前beanName是Prototype并且正处于创建状态,那么这里直接抛出异常
//Prototype类型的bean不能被循环引用的体现
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
//先去父IOC找找有无,有的话直接返回
BeanFactory parentBeanFactory = getParentBeanFactory();
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {...}
if (!typeCheckOnly) {
//标记当前bean创建完毕
//加入alreadyCreated集合
markBeanAsCreated(beanName);
}
StartupStep beanCreation = this.applicationStartup.start("spring.beans.instantiate")
.tag("beanName", name);
try {
...
//如果设置了beanDefintion的dependon属性,那么这里会进行处理
String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null) {
....
}
//下面进行bean的创建流程
if (mbd.isSingleton()) {
sharedInstance = getSingleton(beanName, () -> {
try {
//创建单例Bean
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
//创建失败,销毁该单例bean
destroySingleton(beanName);
throw ex;
}
});
//对FactoryBean的返回值做处理
beanInstance = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
//其他类型的scope的bean的创建流程
....
}
return adaptBeanInstance(name, beanInstance, requiredType);
}
我们最关心的应该是三层缓存的查询方法,即getSingleton:
public Object getSingleton(String beanName) {
//第二个参数表示是否允许循环依赖,这里允许
return getSingleton(beanName, true);
}
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
//先查询一级缓存--即单例缓存池,如果这里面有就直接返回
Object singletonObject = this.singletonObjects.get(beanName);
//如果没有,并且当前bean正在创建中
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
//查询二级缓存,判断有无
singletonObject = this.earlySingletonObjects.get(beanName);
//如果二级缓存也没有,并且允许循环依赖
if (singletonObject == null && allowEarlyReference) {
synchronized (this.singletonObjects) {
singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null) {
//查询三级缓存--取出当前bean关联的单例工厂
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
//如果存在的话
if (singletonFactory != null) {
//从工厂中获取到这个单例对象
singletonObject = singletonFactory.getObject();
//加入二级缓存
this.earlySingletonObjects.put(beanName, singletonObject);
//并从三级缓存中移除这个单例工厂
this.singletonFactories.remove(beanName);
}
}
}
}
}
}
//找到就返回,否则返回null
return singletonObject;
}
我相信各位此时都有一个疑惑,为什么需要singletonFactories,而不是直接两级缓存完事了呢?
先来看看getSingleton方法:
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(beanName, "Bean name must not be null");
synchronized (this.singletonObjects) {
//首先查看单例缓存池中是否已经存在了当前bean
//即当前bean是否已经创建完了
Object singletonObject = this.singletonObjects.get(beanName);
//如果一级缓存中没有
if (singletonObject == null) {
//并且如果单例bean集合正处于销毁状态,那么抛出异常
if (this.singletonsCurrentlyInDestruction) {
throw new BeanCreationNotAllowedException(beanName,
"Singleton bean creation not allowed while singletons of this factory are in destruction " +
"(Do not request a bean from a BeanFactory in a destroy method implementation!)");
}
if (logger.isDebugEnabled()) {
logger.debug("Creating shared instance of singleton bean '" + beanName + "'");
}
//记录当前bean正处于创建状态--加入singletonsCurrentlyInCreation
beforeSingletonCreation(beanName);
boolean newSingleton = false;
boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
if (recordSuppressedExceptions) {
this.suppressedExceptions = new LinkedHashSet<>();
}
try {
//这里就是调用createBean方法来创建单例对象
singletonObject = singletonFactory.getObject();
newSingleton = true;
}
catch (IllegalStateException ex) {
// Has the singleton object implicitly appeared in the meantime ->
// if yes, proceed with it since the exception indicates that state.
singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
throw ex;
}
}
catch (BeanCreationException ex) {
if (recordSuppressedExceptions) {
for (Exception suppressedException : this.suppressedExceptions) {
ex.addRelatedCause(suppressedException);
}
}
throw ex;
}
finally {
if (recordSuppressedExceptions) {
this.suppressedExceptions = null;
}
//当前单例对象创建完毕后
//清除其正处于创建状态的标记,即从singletonsCurrentlyInCreation集合中移除
afterSingletonCreation(beanName);
}
//如果是一个新的单例对象被创建
if (newSingleton) {
//加入一级缓存中去--顺便清除二三级缓存中当前bean的信息
addSingleton(beanName, singletonObject);
}
}
//返回创建的单例对象
return singletonObject;
}
}
下面再来看看createBean方法:
protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
throws BeanCreationException {
...
RootBeanDefinition mbdToUse = mbd;
...
try {
//初始化前,先去调用bean的后置处理器两个初始化前后的回调接口
//如果在这里,返回的值不为空,那么会直接形成短路
Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
if (bean != null) {
return bean;
}
}
catch (Throwable ex) {
throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
"BeanPostProcessor before instantiation of bean failed", ex);
}
try {
//真正创建bean
Object beanInstance = doCreateBean(beanName, mbdToUse, args);
if (logger.isTraceEnabled()) {
logger.trace("Finished creating instance of bean '" + beanName + "'");
}
return beanInstance;
}
....
}
看来还需要再追踪一层doCreateBean:
protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
throws BeanCreationException {
...
if (instanceWrapper == null) {
//实例化bean
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
//从BeanWrapper中取出真正被创建出来的bean实例
Object bean = instanceWrapper.getWrappedInstance();
...
//调用相关bean后置处理器的回调接口
synchronized (mbd.postProcessingLock) {
if (!mbd.postProcessed) {
try {
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
}
....
}
}
//当前bean是否允许早期被暴露出去
//三个前提: 当前bean是单例的,允许循环依赖,当前bean处于正创建的状态
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
...
//加入单例工厂---就是加入三级缓存中
//这里getEarlyBeanReference是关键,这里会调用bean后置处理器的getEarlyBeanReference接口
//自动代理创建器在此处创建代理对象
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
//拿到暴露出去的bean实例
Object exposedObject = bean;
try {
//属性赋值
populateBean(beanName, mbd, instanceWrapper);
//初始化bean
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
catch (Throwable ex) {
....
}
//当前bean是否允许早期暴露---满足上面三个条件
if (earlySingletonExposure) {
//此时第二个参数为false,表示不允许提前暴露
//因此不会去查询三级缓存---只会去查询到二级缓存
//当前bean因为还处于创建状态,因此一级缓存是绝对没有的,二级缓存可能有,可能没有
Object earlySingletonReference = getSingleton(beanName, false);
//如果二级缓存有,说明产生了循环依赖
if (earlySingletonReference != null) {
//如果经历过属性赋值和初始化过后的bean依然和之前的bean实例一致
//说明当前bean没有被代理过,否则就是两个对象了
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
//如果当前bean被代理了,那么默认是不支持循环引用发生的
//下面再判断被代理后的对象是否允许在存在循环引用的情况下再注入其他bean实例,默认为false
//并且当前bean确实存在对其他bean的依赖
//这里举个例子:
//例如A与B相互引用,此时A走到这里,说明引用的B已经从三级缓存中获取到了提早暴露出的A的引用,并放入了二级缓存
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
//A这里拿到的应该是B
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
//这里会判断B是否在alreadyCreated集合中,即B是否已经创建好了
//如果是的话,该方法返回false,下面的条件成立,会将当前依赖bean加入集合,表示存在循环依赖
//否则,返回true,不会满足下面的条件
if (!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.");
}
}
}
}
//处理当前bean相关的销毁回调接口
try {
registerDisposableBeanIfNecessary(beanName, bean, mbd);
}
...
return exposedObject;
}
从上面代码的分析中,我们洞悉到了一点:
这里我们可以模拟一下Spring三级缓存解决循环依赖的过程:
我相信各位还记得getEarlyBeanReference
方法,也就是从三级缓存中取出提早暴露的bean时,会调用该方法,那么这与aop有什么关系呢?
getEarlyBeanReference实际会去调用相关后置处理器的回调接口来对bean进行处理,而不是单单返回原本的bean实例:
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
//调用相关后置处理器的getEarlyBeanReference回调接口
exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
}
}
return exposedObject;
}
通过追踪getEarlyBeanReference方法的实现子类,我们可以发现只有AbstractAutoProxyCreator实现了此方法,即抽象的自动代理创建器实现了这个方法:
@Override
public Object getEarlyBeanReference(Object bean, String beanName) {
//为当前bean构造一个缓存key
Object cacheKey = getCacheKey(bean.getClass(), beanName);
//加入提前被代理的bean引用集合
this.earlyProxyReferences.put(cacheKey, bean);
//判断当前bean是否需要被代理
return wrapIfNecessary(bean, beanName, cacheKey);
}
wrapIfNecessary决定当前被提早暴露的bean是否需要被代理,那么判断条件是什么呢?
protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
//targetSourcedBeans集合中存在,也表明是已经被代理过的
if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) {
return bean;
}
//如果advisedBeans集合存在当前bean的缓存信息,并且上一次判断后,说明当前bean不需要被代理
//那么直接返回
if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
return bean;
}
//如果是一些基础类或者内部使用的类,则不进行代理
if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
}
//获取可以应用到当前bean的相关拦截器--getAdvicesAndAdvisorsForBean由子类实现
Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
//如果返回的拦截器数组为空,说明不需要代理,否则进行代理
if (specificInterceptors != DO_NOT_PROXY) {
//创建代理,然后缓存后返回
//Boolean.TRUE表名当前bean被判断过是需要进行代理的
this.advisedBeans.put(cacheKey, Boolean.TRUE);
Object proxy = createProxy(
bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
this.proxyTypes.put(cacheKey, proxy.getClass());
return proxy;
}
//返回原bean,未被代理
this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
}
可以看到getEarlyBeanReference接口可以确保被提前暴露的bean,如果是需要被代理的,那么直接通过这里的回调接口返回代理对象,这样在存在循环依赖的情况下,注入的对象也是代理对象,而非原对象。
postProcessAfterInitialization: bean的初始化方法被调用后执行
public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
//bean==null,说明applyBeanPostProcessorsBeforeInitialization返回的是null
if (bean != null) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
// remove方法返回被移除的value,上面说了它记录的是原始bean
// 若被循环引用了,那就是执行了上面的`getEarlyBeanReference`方法,所以此时remove返回值肯定是==bean的(注意此时方法入参的bean还是原始对象)
// 若没有被循环引用,getEarlyBeanReference()不执行 所以remove方法返回null,所以就进入if执行此处的创建代理对象方法
//只有在不存在循环引用的条件下,才会进入if语句
if (this.earlyProxyReferences.remove(cacheKey) != bean) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
}
return bean;
}
这里可能有小伙伴会疑问,如果getEarlyBeanReference()被调用后返回的是代理后的对象,那么postProcessAfterInitialization()方法的返回的是原始bean对象,这不是对不上了吗?
先来看看存在循环依赖并且自动代理创建器将提前暴露的bean给代理了的情况:
如果只有自动代理创建器的情况下,由于存在循环依赖getEarlyBeanReference方法返回的是代理对象,那么postProcessAfterInitialization就会返回原对象,因此exposedObject和bean是相等的,所以会将提前暴露的bean赋值给exposedObject对象
当然没问题,之所以会有这个疑惑,是因为对动态代理底层不够了解,cglib动态代理和jdk动态代理在生产代理对象的时候,是需要获取到目标对象引用的,这个引用和后面被经过属性赋值和初始化阶段的bean引用是同一个,然后再方法被调用的时候,是会去调用内部保存的目标对象方法的,因此最终访问的是同一个对象,没得问题。
代理对象底层的拥有的目标对象和原始bean的引用是一致的,这点要牢记,不然容易搞迷糊