Spring之循环依赖底层源码解析

三级缓存
解决循环依赖思路分析
总结
- 三级缓存总结
- 反向分析singletonFactories

三级缓存

三级缓存是通用的叫法

一级缓存: singletonObjects
- singletonObjects中缓存的是已经经历了完整生命周期的Bean对象
二级缓存: earlySingletonObjects
- earlySingletonObjects比singletonObjects多了一个early,表示缓存的是早期的Bean对象
  
  早期是表示Bean的生命周期还没走完就把这个Bean放入earySingletonObjects
三级缓存: singletonFactories
- singletonFactories中缓存的是ObjectFactory,表示对象工厂,表示用来创建早期Bean对象的工厂

解决循环依赖思路分析

先来分析为什么缓存能解决循环依赖

之所以产生循环依赖的原因,主要是：

A创建时->需要B->B去创建->需要A,从而产生了循环

A与B之间产生循环依赖.png

那么如何打破这个循环,就需要加个中间人缓存

A与B产生循环依赖,如何打破呢.png

A的Bean在创建过程中,在进行依赖注入之前,先把A的原始Bean放入缓存(提早暴露,只要放到缓存了,其他Bean需要的时候就可以从缓存中拿出来用),放入缓存后,再进行依赖注入,此时A的Bean依赖了B的Bean,如果B的Bean不存在,就需要创建B的Bean,而创建B的Bean的过程和A一样,也是先创建一个B的原始对象,然后把B的原始对象提早暴露出来放入缓存中,然后在对B的原始对象进行依赖注入A,此时能从缓存中拿到A的原始对象（虽然是A的原始对象,还不是最终的Bean),B的原始对象依赖注入完之后,B的生命周期结束,那么A的生命周期也能结束.

因为整个过程中,都只有一个A原始对象,所以对于B而言,就算在属性注入时,注入的是A原始对象,也没有关系,因为A原始对象在后续的生命周期中在堆中没有发生变化.

从这里可以看出,只需要一个缓存就能解决循环依赖的问题了,那么为什么Spring还需要singletonFactories呢?

这是难点,基于上面的场景想一个问题: 如果A的原始对象注入给B属性之后,A原始对象进行了AOP产生了一个代理对象,此时就会出现,对于A而言,它的Bean对象起始应该是AOP之后的代理对象,而B的A属性对应的并不是AOP之后的代理对象,这就产生冲突了

B依赖的A和最终的A不是同一个对象

AOP就是通过一个BeanPostProcessor来实现的,这个BeanPostProcessor就是AnnotationAwareAspectJAutoProxyCreator,它的父类是AspectJAwareAdvisorAutoProxyCreator,而在Spring中AOP利用的要么是JDK动态代理,要么是CGLIB动态代理,所以如果给一个类中的某个方法设置了切面,那么这个类最终就需要产生一个代理对象.

一般过程就是: A类->生成一个普通对象->属性注入->基于切面生成一个代理对象->把代理对象放入singletonObjects单例池中,而AOP可以说是Spring除开IOC的另外一个大功能,而循环依赖又属于IOC范畴的,所以这两个功能想要共存,Spring需要进行特殊处理.

如何进行处理的,那就是利用第三级缓存singletonFactories

首先,singletonFactories中存的是某个beanName对应的ObjectFactory,在Bean的生命周期中,生成完原始对象之后,就会构造一个ObjcetFactory存入singletonFactories中,这个ObjectFactory是一个函数式接口,所以支持lambda表达式

() -> getEarlyBeanReference(beanName, mbd,bean)

上面的lambda表达式就是一个ObjectFactory,执行该lambda表达式就会去执行AbstractAutowireCapableBeanFactory#getEarlyBeanReference方法,而该方法如下

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
	Object exposedObject = bean;
	if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
		for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
			exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
		}
	}
	return exposedObject;
}

该方法会去执行SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference方法,而这个接口下的实现类只有两个类实现了这个方法,一个是AbstractAutoProxyCreator,一个是InstantiationAwareBeanPostProcessorAdapter

AbstractAutoProxyCreator#getEarlyBeanReference

public Object getEarlyBeanReference(Object bean, String beanName) {
	Object cacheKey = getCacheKey(bean.getClass(), beanName);
	this.earlyProxyReferences.put(cacheKey, bean);
	return wrapIfNecessary(bean, beanName, cacheKey);
}

InstantiationAwareBeanPostProcessorAdapter#getEarlyBeanReference

default Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
	return bean;
}

在整个Spring中,默认就只有AbstractAutoProxyCreator真正意义上实现了getEarlyBeanReference方法,而该类就是用来进行AOP的.

上面提到的AnnotationAwareAspectJAutoProxyCreator的父类就是AbstractAutoProxyCreator,那么getEarlyBeanReference到底是干什么用的呢?

首先得到一个cacheKey,cacheKey就是beanName.然后把beanName和bean原始对象存入earyProxyRefrences调动wrapIfNecessary进行AOP,得到一个代理对象

那么,什么时候会调用getEarlyBeanReference方法呢？

这个ObjectFactory就是上文说的lambda表达式,中间有getEarlyBeanReference方法,注意存入singletonFactories时并不执行lamda表达式,也就是不会执行getEarlyBeanReference方法

从singletonFactories根据beanName得到一个ObjectFactory,然后执行ObjectFactory,也就是执行getEarlyBeanReference方法,此时会得到一个A原始对象经过AOP之后的代理对象,然后把这个代理对象放入earylySingletonObjects中,注意此时并没有把代理对象放入singletonObjects,那什么时候放入到singletonObjects呢?

我们这个时候得来理解一下earylySingletonObjects的作用,此时,我们只得到了A原始对象的代理对象,这个对象还不完整,因为A原始对象还没有进行属性填充,所以此时不能直接把A的代理对象放入singletonObjects中,所以只能把代理对象放入earlySingletonObjects,假设现在有其他对象依赖了A,那么就可以从earylySingletonObjects中得到A的原始对象的代理对象了,并且是A的同一个代理对象.

当B创建完了之后,A继续进行生命周期,而A在完成属性注入之后,会按照它本身的逻辑去进行AOP,而此时我们知道A原始对象已经经历过AOP,所以对于A本身而言,不会再去进行AOP了,那么怎么判断一个对象是否经历过AOP呢?

会利用上面提到的earlyProxyRefrences,在AbstractAutoProxyCreator#postProcessAfterInitialization方法中,会去判断当前beanName是否在earlyProxyRefrences,如果在就表示已经提前进行过AOP了,无需再次进行AOP

对于A而言,进行了AOP的判断后,以及BeanPostProcessor的执行之后,就需要把A对应的对象放入singletonObjects中了,但是我们知道,应该是要把A的代理对象放入sigletonObjects中,所以此时需要earlySingletonObjects中得到代理对象,然后放入singletonObjects中.

整个循环依赖解决完毕

public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
	if (bean != null) {
		Object cacheKey = getCacheKey(bean.getClass(), beanName);
		if (this.earlyProxyReferences.remove(cacheKey) != bean) {
			return wrapIfNecessary(bean, beanName, cacheKey);
		}
	}
	return bean;
}

protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
	if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) {
		return bean;
	}
	// advisedBeans表示已经判断过了的bean，false表示此bean不需要进行Aop
	if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
		return bean;
	}
	// 当前正在创建的Bean不用进行AOP，比如切面Bean
	if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
		this.advisedBeans.put(cacheKey, Boolean.FALSE);
		return bean;
	}
	// Create proxy if we have advice.
	// 判断当前bean是否存在匹配的advice，如果存在则要生成一个代理对象
	// 此处根据类以及类中的方法去匹配到Interceptor（也就是Advice），然后生成代理对象，代理对象在执行的时候，还会根据当前执行的方法去匹配
	Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
	if (specificInterceptors != DO_NOT_PROXY) {
		// advisedBeans记录了某个Bean已经进行过AOP了
		this.advisedBeans.put(cacheKey, Boolean.TRUE);
		Object proxy = createProxy(
				bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
		this.proxyTypes.put(cacheKey, proxy.getClass());
		return proxy;
	}
	this.advisedBeans.put(cacheKey, Boolean.FALSE);
	return bean;
}

总结

三级缓存总结

singletonObjects
- 缓存经历过完整生命周期的Bean
earylySingletonObjects
- 缓存未经历过完整生命周期的Bean
- 如果某个Bean出现了循环依赖,就会提前把这个暂时未经历过完整生命周期的Bean放入二级缓存earlySIngletonObjects中,这个Bean如果要经历AOP,那么就会把代理对象放入二级缓存earlySIngletonObjects中,否则就是把原始对象放入二级缓存earlySIngletonObjects中,但是不管怎么样,就算是代理对象,代理对象所代理的原始对象也是没有经历过完整生命周期的,所以放入二级缓存earlySIngletonObjects中可以认为是未经历过完整生命周期的Bean
singletonFactories
- 缓存的是一个ObjectFactory,也就是一个lambda表达式.
- 在每个Bean的生成过程中,经过实例化得到一个原始对象后,都会提前基于原始对象暴露一个lambda表达式,并且保存在三级缓存singletonFactories中,这个lambda表达式可能用到,也可能用不到.
- 如果当前Bean没有出现循环依赖,那么这个lambda表达式就没有用,当前Bean按照自己的生命周期正常执行,执行完之后直接把当前Bean放入singletonObjects中
- 如果当前Bean在依赖注入时发现出现了循环依赖(当前正在创建的Bean被其他Bean依赖了),那么就从三级缓存中拿到lambda表达式,并且执行lambda表达式得到一个对象,并把得到的对象放入二级缓存(如果当前Bean需要进行AOP,那么就执行lambda表达式,得到对应的代理对象,如果不需要AOP,那么就直接得到一个原始对象)
earlyProxyReferences
- 它是用来记录某个原始对象是否进行过AOP

反向分析singletonFactories

为什么需要singletonFactories

假设没有singletonFactories,只有earlySIngletonObjects,earlySIngletonObjects是二级缓存,它存储的是未经历过完整生命周期的Bean对象,Spring原有的流程是出现了循环依赖的情况下:

先从singletonFactories中拿到lambda表达式,这里肯定是能拿到的,因为每个Bean实例化之后,依赖注入之前,就会生成一个lambda表达式放入singletonFactories中
执行lambda表达式,得到结果,将结果放入earlySIngletonObjects中

那如果没有singletonFactories,该如何把原始对象或AOP之后的代理对象放入earlySingletonObjects中呢?何时放入呢?

首先,将原始对象或AOP之后的代理对象放入earlySingletonObjects中的有两种:

实例化之后,依赖注入之前
如果是这样,那么对于每个Bean而言,都是在依赖注入之前会去进行AOP,这是不符合Bean生命周期步骤的设计的
真正发现某个bean出现了循环依赖时
- 按现在Spring源码的流程来说,就是getSingleton中是在这个方法中判断出来了当前获取的这个bean在创建中,就表示获取的这个bean出现了循环依赖.
- 那在这个方法中该如何拿到原始对象呢?更加重要的是,该如何拿到AOP之后的代理对象呢?
- 难道在这个方法中去循环调用BeanPostProcessor的初始化后的方法吗?不是做不到,不太合适,代码质量下降.
- 最关键的是在这个方法中该如何拿到原始对象呢?还是得需要一个Map,预先把这个Bean实例化后的对象存在这个Map中,那这样的话还不如直接用第一种方案,但是第一种又直接打破了Bean生命周期的设计
所以,我们可以发现,现在Spring所用的singletonFactories,为了调和不同的情况,在 singletonFactories中存的是lambda表达式,这样的话,只有在出现了循环依赖的情况,才会执行lambda表达式,才会进行AOP,也就说只有在出现了循环依赖的情况下才会打破Bean生命周期的设计,如果一个Bean没有出现循环依赖,那么它还是遵守了Bean的生命周期的设计的