流程图：Spring 解决循环依赖

末蓝、 2023-01-18 14:21 111阅读 0赞

Spring Boot 启动过程：  
[1. 创建 SpringApplication 对象。][1. _ SpringApplication]  
[2. 执行对象的 run() 方法。][2. _ run_]  
[3. 将 class 变成 beanDefinition。][3. _ class _ beanDefinition]  
[4. 将 beanDefinition 变成 bean][4. _ beanDefinition _ bean]  
[5. 图解 循环依赖][5. _]  
[6. 图解 bean 的生命周期][6. _ bean]  
[7. 图解 aop 拦截器链调用][7. _ aop]

--------------------

# 1. 循环依赖 #

// A.java
    @Component
    public class A { 
      
      @Autowired
      private B b;
      
      public String getA(){ 
        return a;
      }
    }
    
    // B.java
    @Component
    public class B { 
    
      @Autowired
      private A a;
    
      public String getB(){ 
        return b;
      }
    }

在程序启动时，A、B在各自 bean 的创建过程中均需要对方来“填充”自己，此时就发生了循环依赖。

# 2. 解决循环依赖 #

Spring 通过 三级缓存、将创建和填充分开、提前暴露创建的“裸”对象，三种方式结合使用，解决这种场景下的循环依赖，从而完成 bean 的创建。看下具体解决过程，假设先要为 A 创建 bean。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l5X2RpZWdv_size_16_color_FFFFFF_t_70_pic_center][]

# 3. 为什么需要三级缓存解决循环依赖。 #

第三级缓存：存放封装着 bean 的 接口方法。

第二级缓存：不完整的普通 bean，或者 aop 场景下的 bean 的代理对象。

第一级缓存：完整的普通 bean，或者 aop 场景下的 bean 的代理对象。

只有一级缓存肯定不行，不管是哪一级，创建 a 对象时需要 b 对象来填充属性，为了填充 a 的属性而去创建 b 对象，结果填充 b 的属性又需要 a 对象来填充，循环依赖解决不了。

**更多的问题是：没了第二级缓存行不行？答案是普通循环依赖没问题，如果是 aop 的场景下就有问题了。**

原因就在这里：

`createBeanInstance(...)` 创建的裸 bean，会封装成 `getEarlyBeanReference(beanName, mbd, bean)` 接口方法，保存到第三级缓存：`singletonFactories` 中。

// AbstractAutowireCapableBeanFactory.java
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));

`getSingleton(beanName)` 从第三级换从拿 bean 时，会执行下面这个方法：

// DefaultsingletonBeanRegistory.java
    // 从第三级缓存中拿出封装了 bean 的接口方法。
    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
    // 再从接口方法中拿 bean。
    singletonObject = singletonFactory.getObject();

从接口方法中拿 bean 会执行 `getEarlyBeanReference(...)` 方法。

// AbstractAutowireCapableBeanFactory.java
    // bean 是 createBeanInstance(...) 方法创建的裸bean。
    protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) { 
        Object exposedObject = bean;
        if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { 
            // 遍历符合条件的 beanPostProcessor
            for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) 		{ 
                // 执行每一个 beanPostProcessor 的 getEarlyBeanReference() 方法。
                // 将结果赋值给 exposedObject。
                exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
            }
        }
        // 返回。
        return exposedObject;
    }

**当没有 aop 时**，这里只有一个 beanPostProcessor：`AutoWiredAnnotationBeanPostProcessor`，看下它的 `getEarlyBeanReference(...)` 方法做了什么？

// SmartInstantiationAwareBeanPostProcesor.java
    // AutoWiredAnnotationBeanPostProcessor 实现了 SmartInstantiationAwareBeanPostProcesor。
    default Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { 
        return bean;
    }

什么也没干，拿着入口参数 bean 直接返回了。也就是说 `getEarlyBeanReference(...)`在这种场景下对 bean 什么也没干。**所以当没有 aop 的时候，相同的 beanName 无论从第三级缓存中拿多少次 bean，拿到的都是同一个。**

**当有 aop 且出现循环依赖时**，依旧是这里，不过这种场景下多了一个 beanPostProcessor：`AnnotationAwareAspectjAutoProxyCreator`，看下它的 `getEarlyBeanReference(...)` 方法做了什么？

// AbstractAutoProxyCreator
    // AnnotationAwareAspectjAutoProxyCreator 继承了 AbstractAutoProxyCreator
    public Object getEarlyBeanReference(Object bean, String beanName) { 
        Object cacheKey = getCacheKey(bean.getClass(), beanName);
        this.earlyProxyReferences.put(cacheKey, bean);
        // 如果需要创建为 bean 创建一个 wrapper。
        return wrapIfNecessary(bean, beanName, cacheKey);
    }
    // ------
    protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) { 
        if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) { 
            return 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;
        }
    
        // Create proxy if we have advice.
        Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
        if (specificInterceptors != DO_NOT_PROXY) { 
            this.advisedBeans.put(cacheKey, Boolean.TRUE);
            // 这个地方给 bean 创建了一个代理对象 proxy。
            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;
    }

在这种场景下，bean 经过 `getEarlyBeanReference(...)` 方法处理后，变成了一个新的代理对象返回了。也就是说，从第三级缓存拿bean，拿到的实际上是 bean 的代理对象，而且这个代理对象是中途创建的。也就是说，**相同 beanName 多次从 第三级缓存中拿 bean，每次拿到的都是 bean的不同的代理对象。这就不是单例了。**

使用第二级缓存保存 bean的代理对象，之后如果再需要拿该 bean 的代理对象时，直接从第二级缓存中拿走就行了，不需要再访问第三级缓存，此时就能保证代理对象也是单例的了。

[1. _ SpringApplication]: https://blog.csdn.net/yy_diego/article/details/115445424
[2. _ run_]: https://blog.csdn.net/yy_diego/article/details/116141806
[3. _ class _ beanDefinition]: https://blog.csdn.net/yy_diego/article/details/116228491
[4. _ beanDefinition _ bean]: https://blog.csdn.net/yy_diego/article/details/116351420
[5. _]: https://blog.csdn.net/yy_diego/article/details/116460830
[6. _ bean]: https://blog.csdn.net/yy_diego/article/details/116466407
[7. _ aop]: https://blog.csdn.net/yy_diego/article/details/116575367
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l5X2RpZWdv_size_16_color_FFFFFF_t_70_pic_center]: /images/20221021/b93154c8a54d46b09b270d4a8d7da3f7.png