ThinkSSL🔒 一键申购 5分钟快速签发 30天无理由退款 购买更放心 广告
[TOC] ### 一、面试为啥好问循环依赖问题 Spring是一个集大成者,我想能对其细节摸的透透的人,必定是大神级别了。 其实我一直好奇为啥网上一直流传`Spring 循环依赖问题`的面试题。我也断断续续看了很多人再解释循环依赖原理问题。但对于我来说,似乎还是对其有种似懂非懂的感觉。 > 面试问这个问题的意义在哪? 直到,我从源码世界转了几圈后,再回头看这个问题,我有种豁然开朗的感觉。 是因为这个循环依赖问题背后所需要的知识。 * **你需要对Bean的生命周期(即Spring 创建Bean的过程)有了解** * **你需要对AOP原理有了解** 是的,简简单单一个循环依赖问题,其实蕴含的是Spring 最核心的两个点: Bean的生命周期与AOP原理。 > 这个问题很大程序上就能拷问出你对Spring框架的理解程度,这才是这道题深层的含义吧 基于此种思考,我也来讲讲我对循环依赖的理解。 ### 二、基础知识准备 #### 1\. Java 引用传递还是值传递? **`JAVA 里是值传递,值传递,值传递!!!`** ``` public class Test2 { public static void main(String[] args) { A a = new A(); System.out.println("(1)调用change前" + a); change(a); System.out.println("(3)调用change后" + a); } public static void change(A a) { a = new A(); System.out.println("(2)change方法内" + a); } } class A { } (1)调用change前com.wsjia.ms.controller.A@61064425 (2)change方法内com.wsjia.ms.controller.A@7b1d7fff (3)调用change后com.wsjia.ms.controller.A@61064425 ``` 我承认JAVA中都是值传递。 但此处想要表达的是:引用类型参数,与原引用值共同指向一块内存地址,对对象的修改是相互影响的。 本文姑且叫他`引用的传递`【我知道你应该懂得什么意思】 #### 2\. Bean创建的几个关键点 > 此处只是列出Bean的几个重要的阶段,为了讲清楚循环依赖,具体的在以后专门讲讲Bean的创建。 Spring 创建Bean的过程,大致和对象的初始化有点类似吧。有几个关键的步骤 * createBeanInstance :实例化,此处要强调的是,`Bean的早期引用在此出现`了。 * populateBean : 填充属性,此处我们熟悉的`@Autowired`属性注入就发生在此处 * initializeBean : 调用一些初始化方法,例如`init` ,`afterPropertiesSet` 此外:`BeanPostProcessor`作为一个扩展接口,会穿插在Bean的创建流程中,留下很多钩子,让我们可以去影响Bean的创建过程。其中最主要的就属AOP代理的创建了。 #### 3\. AOP的原理 AOP是以一个`InstantiationAwareBeanPostProcessor`类型的`BeanPostProcessor`,参与到Bean的创建逻辑中,并根据是否需要代理当前Bean,决定是否创建代理对象。 主要逻辑在`(BeanPostProcessor)AbstractAutoProxyCreator类中`中,有三个重要方法。 ~~~ //早期bean创建代理用 public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { Object cacheKey = getCacheKey(bean.getClass(), beanName); this.earlyProxyReferences.put(cacheKey, bean); return wrapIfNecessary(bean, beanName, cacheKey); } //bean创建代理用 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { 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) { //创建代理的逻辑 } ~~~ 当一个Bean创建代理后,我们通过beanname从BeanFactory中获取的就是就是代理的对象的了 #### 4\. getBean()返回的是什么? 当我们尝试按name从BeanFactory.getBean(beanname)一个Bean时,返回的一定是A类对应的实例吗? 答案是否, 当A需要需要创建代理对象时,我们getBean 得到是 代理对象的引用。 #### 5\. 三个缓存 > 本文暂时只考虑单例的情况 把创建好的Bean缓存起来,这是非常平常的逻辑。 ~~~ /** Cache of singleton objects: bean name --> bean instance */ //一级缓存:singletonObjects,存放完全实例化属性赋值完成的Bean,直接可以使用 private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256); /** * Cache of early singleton objects: bean name --> bean instance */ //二级缓存:earlySingletonObjects,存放早期Bean的引用,尚未属性装配的Bean private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16); /** * Cache of singleton factories: bean name --> ObjectFactory */ //三级缓存:singletonFactories,三级缓存,存放实例化完成的Bean工厂。 private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16); ~~~ * singletonObjects:第一级缓存,里面存放的都是创建好的`成品Bean`。 * earlySingletonObjects : 第二级缓存,里面存放的都是`半成品的Bean`。 * singletonFactories :第三级缓存, 不同于前两个存的是 Bean对象引用,此缓存存的bean 工厂对象,也就存的是 `专门创建Bean的一个工厂对象`。此缓存用于解决循环依赖 这里有个点:我个人认为这么叫这三个缓存更加合适 * singletonObjects:**成品缓存** * earlySingletonObjects: **半成品缓存** * singletonFactories :**单例工厂缓存** > 至于为什么,稍微给我个人理解。 ### 三、解析循环依赖 接下来开始讲讲循环依赖 > 本文只讨论,属性注入的情况。 假设有这么两个类产生了循环依赖。如果解决这个问题? ~~~ public class A { B b; public A() { } } class B { @Autowired A a; public B() { } } ~~~ #### 1.一个缓存能解决不? 首先我们先来讨论下这个循环依赖问题 ![](https://img.kancloud.cn/eb/c7/ebc792d46f46f7479173fbf88fbcc752_661x436.png) * 从A获取开始,从缓存里查看,没有开始创建A实例,执行构造方法,填充属性时发现需要依赖B, * 尝试从缓存中获取B。 * 开始创建B实例,执行构造方法,填充属性时,发现需要依赖A,取缓存找A . * A正在创建没有完成。 * **`死结`** #### 2.两个缓存能解决不?? 不等创建完成,有了引用后,**`提前放入半成品缓存`** ![](https://img.kancloud.cn/a3/09/a3095a059b528cf78a02381865516d47_802x558.png) * A引用创建后,提前暴露到`半成品缓存中` * 依赖B,创建B ,B填充属性时发现依赖A, `先从成品缓存查找,没有,再从半成品缓存查找` 取到A的`早期引用`。 * `B顺利走完创建过程`, 将`B的早期引用从半成品缓存移动到成品缓存` * B创建完成,A获取到B的引用,继续创建。 * A创建完成,将`A的早期引用从半成品缓存移动到成品缓存` * **`完美解决循环依赖`** > 嗯? 两个缓存就能解决???为啥需要三个缓存?? #### 3.为啥需要三个缓存 > Spring 为啥用三个缓存去解决循环依赖问题? 上面两个缓存的地方,我们只是没有考虑代理的情况。 ##### 代理的存在 > Bean在创建的最后阶段,会检查是否需要创建代理,如果创建了代理,那么最终返回的就是代理实例的引用。我们通过beanname获取到最终是代理实例的引用 也就是说:上文中,假设A最终会创建代理,提前暴露A的引用, B填充属性时填充的是A的原始对象引用。A最终放入成品库里是代理的引用。那么B中依然是A的早期引用。这种结果最终会与我们的期望的大相径庭了。 > 怎么办??? ##### Spring 是这么做的 ~~~ //=======AbstractAutowireCapableBeanFactory.doCreateBean protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) throws BeanCreationException { //【1】Instantiate the bean. BeanWrapper instanceWrapper = null; if (mbd.isSingleton()) { instanceWrapper = this.factoryBeanInstanceCache.remove(beanName); } if (instanceWrapper == null) { instanceWrapper = createBeanInstance(beanName, mbd, args); } //【早期引用】 final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null); //【2】在需要暴露早期引用的条件下 boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { //【2.1】绑定当前Bean引用到ObjectFactory, 注册到三级 singletonFactories addSingletonFactory (beanName, new ObjectFactory<Object>() { //【重写getObject】 @Override public Object getObject() throws BeansException { return getEarlyBeanReference(beanName, mbd, bean); } }); } } //===AbstractAutowireCapableBeanFactory.doCreateBean--->DefaultSingletonBeanRegistry.getSingleton protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) { synchronized (this.singletonObjects) { if (!this.singletonObjects.containsKey(beanName)) { //【3】放入到singletonFactories 缓存中,清除其他缓存 this.singletonFactories.put(beanName, singletonFactory); this.earlySingletonObjects.remove(beanName); this.registeredSingletons.add(beanName); } } //===========AbstractBeanFactory.doGetBean--->DefaultSingletonBeanRegistry.getSingleton //【4】按Beanname取Beanprotected Object getSingleton(String beanName, boolean allowEarlyReference) { //【4.1】先尝试从成品缓存获取 Object singletonObject = this.singletonObjects.get(beanName); //【4.2】成品缓存没有,且正在创建, 尝试从半成品缓存获取 if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { synchronized (this.singletonObjects) { singletonObject = this.earlySingletonObjects.get(beanName); if (singletonObject == null && allowEarlyReference) { //【4.3】半成品缓存没有,且允许早期引用,尝试从工厂缓存中查找有此Bean的工厂类存在 ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName); if (singletonFactory != null) { //【4.4】存在,执行getObject获取早期引用,放入到半成品缓存,并将工厂类从工厂缓存中移除 singletonObject = singletonFactory.getObject(); this.earlySingletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName); } } } } return (singletonObject != NULL_OBJECT ? singletonObject : null); } ~~~ 注册 **`ObjectFactory工厂类到工厂缓存`**: `singletonFactory.getObject()`;会调用重写`getObject()`调用`getEarlyBeanReference`的后续操作。 * 如果后续操作没有创建代理,`返回的依然是原始引用` * 如果需要代理,在此处`返回就是代理的引用` ~~~ //早期的扩展处理 protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) { Object exposedObject = bean; if (bean != null && !mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { for (BeanPostProcessor bp : getBeanPostProcessors()) { if (bp instanceof SmartInstantiationAwareBeanPostProcessor) { SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp; exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName); if (exposedObject == null) { return null; } } } } return exposedObject; } ~~~ 可以看出此处是执行扩展的操作。 AbstractAutoProxyCreator ~~~ //【1】针对提前创建代理,返回代理引用 public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { Object cacheKey = getCacheKey(bean.getClass(), beanName); this.earlyProxyReferences.put(cacheKey, bean); return wrapIfNecessary(bean, beanName, cacheKey); } //【2】 针对不是提前创建代理的情况 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { if (bean != null) { Object cacheKey = getCacheKey(bean.getClass(), beanName); if (this.earlyProxyReferences.remove(cacheKey) != bean) { return wrapIfNecessary(bean, beanName, cacheKey); } } return bean; } ~~~ 可以看出`singletonFactory` **工厂缓存,解决了代理问题的关键** 大体流程如图 ![](https://img.kancloud.cn/86/1c/861c86e26dbcf48c7a29a1f3f9f05cb1_934x714.png) 关键点: * A绑定到ObjectFactory 注册到`工厂缓存singletonFactory`中, * B在填充A时,`先查成品缓存`有没有,`再查半成品缓存`有没有,`最后看工厂缓存有没有单例工厂类`,有A的ObjectFactory。调用getObject ,执行扩展逻辑,可能返回的代理引用,也可能返回原始引用。 * 成功获取到A的早期引用,将A放入到`半成品缓存`中,B填充A引用完毕。 * 代理问题, 循环依赖问题都解决了。 ### 四、额外思考的自问自答 > 在这之外,我还有一些思考,并提出自己的观点。 1:为啥不提前调用`ObjectFactory.getObject ()`直接执行扩展逻辑处理A的早期引用,得到半成品实例引用放入到`earlySingletonObjects`中,非要先放一个工厂类到工厂缓存中?使用三级缓存呢? 答:假设A只是依赖B 。如果提前执行A扩展操作,在A创建的后期,还会遍历一遍扩展点,岂不是浪费? 2.二级缓存存在意义是啥? 答:其实吧,我觉得 `二级缓存earlySingletonObjects` 与 `三级缓存singletonFactories` 。都是为`分工明确`而生。 * `一级缓存singletonObjects`: 就是存的`最终的成品` * `二级缓存earlySingletonObjects` 就是为存`半成品Bean` * `三级缓存singletonFactories`: 就是为存`bean工厂` 因为是早期暴露,从`工厂里创建`完成后,是半成品,放入`半成品缓存`,全部流程执行完时是成品放入到`成品缓存`。**`分工明确`** > 这也为什么,我认为叫成品缓存,半成品缓存,单例工厂缓存 更加合适的原因 3.是不是走极端,让我设计此块,我非得设计成单个缓存。提前执行后续操作,把他放到`singletonObjects`。 好像也没有问题,就是非常乱 ### 五、总结 以上就是我对Spring循环依赖的一些理解与思考 循环依赖的关键点:**提前暴露绑定A原始引用的工厂类到工厂缓存。等需要时触发后续操作处理A的早期引用,将处理结果放入二级缓存** 作者:享学源码 链接:https://juejin.cn/post/6844904166351978504 来源:掘金 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。