Spring循环依赖
循环依赖过程
假设一个情景：A引用B,B引用A
核心代码：
@Nullable
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && this.isSingletonCurrentlyInCreation(beanName)) {
synchronized(this.singletonObjects) {
/**
* 三级缓存获取，key=beanName value=objectFactory，objectFactory中存储getObject()方法用于获取提前曝光的实例
*
* 而为什么不直接将实例缓存到二级缓存，而要多此一举将实例先封装到objectFactory中？
* 主要关键点在getObject()方法并非直接返回实例，而是对实例又使用
* SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法对bean进行处理
*
* 也就是说，当spring中存在该后置处理器，所有的单例bean在实例化后都会被进行提前曝光到三级缓存中，
* 但是并不是所有的bean都存在循环依赖，也就是三级缓存到二级缓存的步骤不一定都会被执行，有可能曝光后直接创建完成，没被提前引用过，
* 就直接被加入到一级缓存中。因此可以确保只有提前曝光且被引用的bean才会进行该后置处理
*/
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = (ObjectFactory)this.singletonFactories.get(beanName);
if (singletonFactory != null) {
/**
* 通过getObject()方法获取bean，通过此方法获取到的实例不单单是提前曝光出来的实例，
* 它还经过了SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法处理过。
* 这也正是三级缓存存在的意义，可以通过重写该后置处理器对提前曝光的实例，在被提前引用时进行一些操作
*/
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return singletonObject;
}
创建步骤：
- 在获取A时，调用getSingleton方法，此时一级缓存singletonObject中获取不到，由于是第一次创建，isSingletonCurrentlyInCreation(beanName)也返回false,因此不会走上面那段核心代码，继续往下走
- 把A放入singletonsCurrentlyInCreation集合中，表示A正在被创建
protected void beforeSingletonCreation(String beanName) {
if (!this.inCreationCheckExclusions.contains(beanName) && !this.singletonsCurrentlyInCreation.add(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
}
- 在对A进行赋值前，会判断是否允许循环依赖，如果允许，则在三级缓存SingletonFactory中缓存该bean的工厂类，可以通过该Factory获得该bean，并进行包装
#allowCircularReferences默认为true，表示允许循环依赖，可以将其修改为false关闭循环依赖
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);
});
}
- 接下来对A进行赋值，在解析时发现依赖B，于是对B调用getSingleton方法
- B前面对创建过程与A类似，直至到了B的赋值阶段，发现又依赖A,于是再次对A调用getSingleton方法
- 由于此时A还未创建完成，所以singletonObject == null，但是之前已经把A放入了isSingletonCurrentlyInCreation中，因此this.isSingletonCurrentlyInCreation(beanName)返回true，进入核心代码
- singletonObject = this.earlySingletonObjects.get(beanName);首先先去二级缓存earlySingletonObjects中获取，因为是第一次创建肯定获取不到
- 于是去三级缓存中获取该bean之前缓存的工厂类ObjectFactory<?> singletonFactory = (ObjectFactory)this.singletonFactories.get(beanName);
- 通过该工厂类提前返回A，并将其放入二级缓存中，如果还有其他循环依赖调用，则直接从该二级缓存中获取A
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
- 然后B实例构造完成，放入一级缓存singletonObjects中；接下来A也构造完成，放入singletonObjects中，后面再要获取这两个Bean，直接从一级缓存中获取即可
知道了这个原理时候，肯定就知道为啥Spring不能解决“A的构造方法中依赖了B的实例对象，同时B的构造方法中依赖了A的实例对象”这类问题了！因为加入singletonFactories三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决
循环依赖三级缓存
通过上面循环依赖的过程可以看到，解决循环依赖涉及到三级缓存：
- singletonObjects：单例对象的cache，用于存放已经创建完成的bean
- earlySingletonObjects ：提前曝光的单例对象的cache，里面缓存的bean还没创建完成的,只能确保已经进行了实例化，但是属性填充跟初始化肯定还没有做完，因此该bean还没创建完成，仅仅能作为指针提前曝光，被其他bean所引用
- singletonFactories ： 单例对象工厂的cache ,在需要引用提前曝光对象时再通过singletonFactory.getObject()获取。
这里抛出问题，如果我们直接将提前曝光的对象放到二级缓存earlySingletonObjects，Spring循环依赖时直接取就可以解决循环依赖了，为什么还要三级缓存singletonFactory然后再通过getObject()来获取呢？这不是多此一举？
三级缓存的意义
singletonFactories这个三级cache的类型是ObjectFactory，定义如下：
public interface ObjectFactory<T> {
T getObject() throws BeansException;
}
这个接口在下面被引用
this.addSingletonFactory(beanName, () -> {
return this.getEarlyBeanReference(beanName, mbd, bean);
});
其中addSingletonFactory()方法内容如下
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(singletonFactory, "Singleton factory must not be null");
synchronized (this.singletonObjects) {
if (!this.singletonObjects.containsKey(beanName)) {
#向三级缓存中放入该singletonFactory
this.singletonFactories.put(beanName, singletonFactory);
this.earlySingletonObjects.remove(beanName);
this.registeredSingletons.add(beanName);
}
}
}
这里存在一个问题，我们知道AOP代理对象是在赋值和初始化之后创建的，但是这里提前暴露的对象仅仅只完成了实例化这一步，那么给B注入的A是否已完成了AOP代理呢？
接着回到上面的代码，可以看到在返回getObject()时，多做了一步getEarlyBeanReference操作，这步操作是BeanPostProcess的一种，也就是给子类重写的一个后处理器，目的是用于被提前引用时进行拓展。因此：所有的单例bean在实例化后都会被进行提前曝光到三级缓存中，但是曝光的时候并不调用该后置处理器，只有曝光，且被提前引用的时候才调用，确保了被提前引用这个时机触发
因此所有的重点都落到了getEarlyBeanReference上，下面为getEarlyBeanReference()方法的代码
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
// 这么一大段就这句话是核心，也就是当bean要进行提前曝光时，
// 给一个机会，通过重写后置处理器的getEarlyBeanReference方法，来自定义操作bean
// 值得注意的是，如果提前曝光了，但是没有被提前引用，则该后置处理器并不生效!!!
// 这也正式三级缓存存在的意义，否则二级缓存就可以解决循环依赖的问题
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
}
}
}
return exposedObject;
}
在exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);这行代码中调用来SmartInstantiationAwareBeanPostProcessor对getEarlyBeanReference方法的实现。
再通过UML的类图查看实现类，仅有AbstractAutoProxyCreator进行了实现对该后置处理器进行了实现。下面为AbstractAutoProxyCreator对getEarlyBeanReference()方法的实现
// AbstractAutoProxyCreator.java
public Object getEarlyBeanReference(Object bean, String beanName) {
// 缓存当前bean，表示该bean被提前代理了
Object cacheKey = getCacheKey(bean.getClass(), beanName);
this.earlyProxyReferences.put(cacheKey, bean);
// 对bean进行提前Spring AOP代理
return wrapIfNecessary(bean, beanName, cacheKey);
}
wrapIfNecessary是用于Spring AOP自动代理的。Spring将当前bean缓存到earlyProxyReferences中标识提前曝光的bean在被提前引用之前，然后进行了Spring AOP代理。所以说给B注入的A已经是经过提前经过AOP代理的类
但是经过Spring AOP代理后的bean就已经不再是原来的bean了，经过代理后的bean是一个全新的bean，也就是说代理前后的2个bean连内存地址都不一样了。这时将再引出新的问题：B提前引用A将引用到A的代理，这是符合常理的，但是最原始的bean A在B完成创建后将继续创建，那么Spring Ioc最后返回的Bean是Bean A呢还是经过代理后的Bean呢？
提前代理bean与原bean的冲突解决
这个问题我们得回到Spring AOP代理，Spring AOP代理时机有2个：
- 当自定义了TargetSource，则在bean实例化前完成Spring AOP代理并且直接发生短路操作，返回bean
- 正常情况下，都是在bean初始化后进行Spring AOP代理
- 如果要加上今天说的提前曝光代理，getEarlyBeanReference可以说3种
第一种情况就没什么好探究的了，直接短路了，根本没有后续操作。而我们关心的是第二种情况，在Spring初始化后置处理器中发生的Spring AOP代理
public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
throws BeansException {
Object result = existingBean;
for (BeanPostProcessor processor : getBeanPostProcessors()) {
// 调用bean初始化后置处理器处理
Object current = processor.postProcessAfterInitialization(result, beanName);
if (current == null) {
return result;
}
result = current;
}
return result;
}
// AbstractAutoProxyCreator.java
public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
if (bean != null) {
// 获取缓存key
Object cacheKey = getCacheKey(bean.getClass(), beanName);
// 查看该bean是否被Spring AOP提前代理！而缓存的是原始的bean，因此如果bean被提前代理过，这此处会跳过
// 如果bean没有被提前代理过，则进入AOP代理
if (this.earlyProxyReferences.remove(cacheKey) != bean) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
}
return bean;
}
earlyProxyReferences是不是有点熟悉，是的，这就是我们刚刚提前曝光并且进行Spring AOP提前代理时缓存的原始bean，如果缓存的原始bean跟当前的bean是一致的，说明该bean已经提前进行过代理，那么就不进行Spring AOP代理了！而是直接返回原始的bean
那么如何将代理后的bean返回给容器呢，继续看属性赋值完毕后的代码：
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
throws BeanCreationException {
try {
//
/**
* 4. 填充属性
* 如果@Autowired注解属性，则在上方完成解析后，在这里完成注入
*
* @Autowired
* private Inner inner;
*/
populateBean(beanName, mbd, instanceWrapper);
// 5. 初始化
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
catch (Throwable ex) {
if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
throw (BeanCreationException) ex;
}
else {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
}
}
// 6. 存在提前曝光情况下
if (earlySingletonExposure) {
// earlySingletonReference：二级缓存，缓存的是经过提前曝光提前Spring AOP代理的bean
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
// exposedObject跟bean一样，说明初始化操作没用应用Initialization后置处理器(指AOP操作)改变exposedObject
// 主要是因为exposedObject如果提前代理过，就会跳过Spring AOP代理，所以exposedObject没被改变，也就等于bean了
if (exposedObject == bean) {
// 将二级缓存中的提前AOP代理的bean赋值给exposedObject，并返回
exposedObject = earlySingletonReference;
}
// 引用都不相等了，也就是现在的bean已经不是当时提前曝光的bean了
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
// dependentBeans也就是B, C, D
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
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 " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
这个时候我们需要理清一下3个变量
- earlySingletonReference：二级缓存，缓存的是经过提前曝光提前AOP代理的bean
- bean：这个就是经过了实例化、填充、初始化的bean
- exposedObject：这个是经过了AbstractAutoProxyCreator的postProcessAfterInitialization处理过后的bean，但是在其中因为发现当前bean已经被earlyProxyReferences缓存，所以并没有进行AOP处理，而是直接跳过，因此还是跟第2点一样的bean
理清这3个变量以后，就会发现，exposedObject = earlySingletonReference;
AOP代理过的Bean赋值给了exposedObject并返回，这时候用户拿到的bean就是AOP代理过后的bean了，一切皆大欢喜了。
但是中间还有一个问题！提前曝光的bean在提前引用时被Spring AOP代理了，但是此时的bean只是经过了实例化的bean，还没有进行@Autowire的注入啊！也就是说此时代理的bean里面自动注入的属性是空的！
提前AOP代理对象的 属性填充、初始化
是的，确实在Spring AOP提前代理后没有经过属性填充和初始化。那么这个代理又是如何保证依赖属性的注入的呢？答案回到Spring AOP最早最早讲的JDK动态代理上找，JDK动态代理时，会将目标对象target保存在最后生成的代理 p r o x y 中 ， 当 调 用 proxy中，当调用 proxy中，当调用proxy方法时会回调h.invoke，而h.invoke又会回调目标对象target的原始方法。因此，其实在Spring AOP动态代理时，原始bean已经被保存在提前曝光代理中了。而后原始Bean继续完成属性填充和初始化操作。因为AOP代理$proxy中保存着traget也就是是原始bean的引用，因此后续原始bean的完善，也就相当于Spring AOP中的target的完善，这样就保证了Spring AOP的属性填充与初始化了！
最后是对循环依赖流程的总结：
参考文献：https://blog.csdn.net/chaitoudaren/article/details/105060882
546
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
