Spring源码分析(九)循环依赖源码分析

什么是循环依赖？

很简单，就是A对象依赖了B对象，B对象依赖了A对象。

比如：

// A依赖了B
class A{
    public B b;
}

// B依赖了A
class B{
    public A a;
}

那么循环依赖是个问题吗？

如果不考虑Spring，循环依赖并不是问题，因为对象之间相互依赖是很正常的事情。

比如

A a = new A();
B b = new B();

a.b = b;
b.a = a;

 

这样，A,B就依赖上了。

但是，在Spring中循环依赖就是一个问题了，为什么？

因为，在Spring中，一个对象并不是简单new出来了，而是会经过一系列的Bean的生命周期，就是因为Bean的生命周期所以才会出现循环依赖问题。当然，在Spring中，出现循环依赖的场景很多，有的场景Spring自动帮我们解决了，而有的场景则需要程序员来解决，下文详细来说。

要明白Spring中的循环依赖，得先明白Spring中Bean的生命周期。

Bean的生命周期

这里不会对Bean的生命周期进行详细的描述，只描述一下大概的过程。

Bean的生命周期指的就是：在Spring中，Bean是如何生成的？

被Spring管理的对象叫做Bean。Bean的生成步骤如下：

  1. Spring扫描class得到BeanDefinition
  2. 根据得到的BeanDefinition去生成bean
  3. 首先根据class推断构造方法
  4. 根据推断出来的构造方法，反射，得到一个对象（暂时叫做原始对象）
  5. 填充原始对象中的属性（依赖注入）
  6. 如果原始对象中的某个方法被AOP了，那么则需要根据原始对象生成一个代理对象
  7. 把最终生成的代理对象放入单例池（源码中叫做singletonObjects）中，下次getBean时就直接从单例池拿即可

可以看到，对于Spring中的Bean的生成过程，步骤还是很多的，并且不仅仅只有上面的7步，还有很多很多，比如Aware回调、初始化等等，这里不详细讨论。

可以发现，在Spring中，构造一个Bean，包括了new这个步骤（第4步构造方法反射）。

得到一个原始对象后，Spring需要给对象中的属性进行依赖注入，那么这个注入过程是怎样的？

比如上文说的A类，A类中存在一个B类的b属性，所以，当A类生成了一个原始对象之后，就会去给b属性去赋值，此时就会根据b属性的类型和属性名去BeanFactory中去获取B类所对应的单例bean。如果此时BeanFactory中存在B对应的Bean，那么直接拿来赋值给b属性；如果此时BeanFactory中不存在B对应的Bean，则需要生成一个B对应的Bean，然后赋值给b属性。 

问题就出现在第二种情况，如果此时B类在BeanFactory中还没有生成对应的Bean，那么就需要去生成，就会经过B的Bean的生命周期。 

那么在创建B类的Bean的过程中，如果B类中存在一个A类的a属性，那么在创建B的Bean的过程中就需要A类对应的Bean，但是，触发B类Bean的创建的条件是A类Bean在创建过程中的依赖注入，所以这里就出现了循环依赖：

ABean创建-->依赖了B属性-->触发BBean创建--->B依赖了A属性--->需要ABean（但ABean还在创建过程中）

 从而导致ABean创建不出来，BBean也创建不出来。我们只考虑上面的场景，解决其实并不难，只要把ABean创建的实例后（属性填充在后面）放到一个缓存中earlySingletonObjects  这样在B依赖A的时候直接从这个缓存中拿就可以了。

这样去做确实能解决上面提到的循环依赖的问题。但是在Spring中有一个特殊的功能就是AOP,会造成某个beanName对应的最终对象和原始对象不是同一个对象，因为有AOP功能的bean最后的对象是个代理对象，而刚创建完的对象还是原始对象，这样就会造成B属性中的A对象和最终的对象不一致。

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

一般过程就是：A类--->生成一个普通对象-->属性注入-->基于切面生成一个代理对象-->把代理对象放入singletonObjects单例池中。

而AOP可以说是Spring中除开IOC的另外一大功能，而循环依赖又是属于IOC范畴的，所以这两大功能想要并存，Spring需要特殊处理。

如何处理的，就是利用了第三级缓存singletonFactories。

首先，singletonFactories中存的是某个beanName对应的ObjectFactory，在bean的生命周期中，生成完原始对象之后，就会构造一个ObjectFactory存入singletonFactories中。这个ObjectFactory是一个函数式接口，所以支持Lambda表达式：() -> getEarlyBeanReference(beanName, mbd, bean)

上面的Lambda表达式就是一个ObjectFactory，执行该Lambda表达式就会去执行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;
                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
            }
        }
    }
    return exposedObject;
}

 

该方法会去执行SmartInstantiationAwareBeanPostProcessor中的getEarlyBeanReference方法，而这个接口下的实现类中只有两个类实现了这个方法，一个是AbstractAutoProxyCreator，一个是InstantiationAwareBeanPostProcessorAdapter，它的实现如下：

// InstantiationAwareBeanPostProcessorAdapter
@Override
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
    return bean;
}
// AbstractAutoProxyCreator
@Override
public Object getEarlyBeanReference(Object bean, String beanName) {
    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    this.earlyProxyReferences.put(cacheKey, bean);
    return wrapIfNecessary(bean, beanName, cacheKey);
}

所以很明显，在整个Spring中，默认就只有AbstractAutoProxyCreator真正意义上实现了getEarlyBeanReference方法，而该类就是用来进行AOP的。上文提到的AnnotationAwareAspectJAutoProxyCreator的父类就是AbstractAutoProxyCreator。

 

那么getEarlyBeanReference方法到底在干什么？

首先得到一个cachekey，cachekey就是beanName。

然后把beanName和bean（这是原始对象）存入earlyProxyReferences中

调用wrapIfNecessary进行AOP，得到一个代理对象。

那么，什么时候会调用getEarlyBeanReference方法呢？回到循环依赖的场景中

 

 

 

 

这是循环依赖的场景，但是上文说了，在Spring中，通过某些机制帮开发者解决了部分循环依赖的问题，这个机制就是三级缓存。

三级缓存是通用的叫法。

一级缓存为：singletonObjects   单例池  存储的是容器创建的单例 是个Map  <beanName,实例>   是个 ConcurrentHashMap

二级缓存为：earlySingletonObjects    是为了解决因为循环依赖提前创建的AOP代理对象无法保证唯一的问题，用这个map存储 Map<String, AOP代理对象>    注意这个代理对象里面有一个实际的对象属性target，是个HashMap

                 

三级缓存为：singletonFactories         但是只有上面两个缓存还不够，因为涉及到AOP代理对象的创建时间，因为二级缓存中的提前创建的AOP代理的时候要用到AService的原始对象，而没有地方能获取到，为了解决这个问题，用三级缓存来存储。

                                                                用这个map存储 Map<String, ObjectFactory<?>>    注意这个代理对象里面有一个实际的对象属性target  是个HashMap。

                                                                因为这个三级缓存为AOP提前创建代理对象服务的 所以不止 有原始实例对象 还有bd,beanName,封装成了一个lambd表达式 ，存入了singletonFactory中 ，使用的时候就是执行AOP的代理。

                                                                三级缓存在创建AService实例的时候就放入了一个lambd表达式了 ，当出现了循环依赖的时候才会判断要不要走Aop的代理逻辑

二级缓存，三级缓存是同命运的，在DefaultSingletonBeanRegistry#getSingleton() 方法中会在锁中对它俩进行操作。这里有个点二级缓存和三级缓存对于同一个beanName 都只保留一个 所以就算是用ConcurrentHashMap 要保证两个map操作的原子性也是要加锁的，所以它俩都是hashMap的 一级缓存单例池是ConcurrentHashMap的

还有一个和AOP关系的map, this.earlyProxyReferences  中存的就是那些提前进行了Aop的bean beanName： AOP之前的对象

总结

  1. singletonObjects：缓存某个beanName对应的经过了完整生命周期的bean
  2. earlySingletonObjects：缓存提前通过原始对象进行了AOP之后得到的代理对象，原始对象还没有进行属性注入和后续的BeanPostProcessor等生命周期
  3. singletonFactories：缓存的是一个ObjectFactory，也就是一个Lambda表达式。在创建一个Bean时，在每个Bean的生成过程中，都会提前暴露一个Lambda表达式，并保存到三级缓存中，这个Lambda表达式可能用到，也可能用不到，如果没有出现循环依赖依赖本bean，那么这个Lambda表达式无用，本bean按照自己的生命周期执行，执行完后直接把本bean放入singletonObjects中即可，如果出现了循环依赖依赖了本bean，则从三级缓存中获取Lambda表达式，并执行Lambda表达式得到一个AOP之后的代理对象(如果有AOP的话，如果无需AOP，则直接得到一个原始对象)，并把得到的对象放入二级缓存
  4. 其实还要一个缓存，就是earlyProxyReferences，它用来记录某个原始对象是否进行过AOP了。




 


 


 


 下图中的第四步： 会有正常AOP的代理逻辑，但是如果之前已经走了AOP的代理 这里是不会走的，那怎么判断呢？AOP是后处理器处理的。有一个 AbstractAutoProxyCreator后置处理器，里面有 getEarlyBeanReference 方法，这是提前进行AOP代理类出现的方法，


还有一个 postProcessAfterInitialization 正常AOP代理处理会走的逻辑，它们方法里都会有一个map的操作： this.earlyProxyReferences  中存的就是那些提前进行了Aop的bean beanName： AOP之前的对象




 


 


 


 


 


 


 


 


 


 


 Spring无法解决的循环依赖的情况


1：循环依赖的两个bean至少其中一个是单例的bean，这种情况Spring都可以正常处理好。但是两个循环依赖的bean都是原型的话，这种就会报循环依赖的错了。


 2：上面说的能处理的循环依赖，还要是那种属性注入的方式才可行，不能是构造函数的方式注入，因为根据上面的流程我们可以知道，Spring处理循环依赖都是在实例创建好之后，在初始化属性的时候进行循环依赖处理的，如果要是构造函数的时候就出现了循环依赖，实例都无法创建，自然也解决不了了。


       但是这种构造函数注入的循环依赖问题，可以通过在构造函数上加@Lazy注解解决，因为加了这个注解，构造函数中的参数就是个代理对象，不需要创建真正的实例对象了。但是注解加在类上是没办法解决的，但是注解加在类上面是不行的。为啥呢？留个悬念


 


 


 






            

            
posted @ 
2021-07-06 22:28 
蒙恬括 
阅读(192) 
评论(0) 
编辑 
收藏 
举报