⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 bugpool.blog.csdn.net/article/details/105060882 「bugpool」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

前言

问：Spring如何解决循环依赖？

答：Spring通过提前曝光机制，利用三级缓存解决循环依赖。

再问：Spring通过提前曝光，直接曝光到二级缓存已经可以解决循环依赖问题了，为什么一定要三级缓存？

再细问：如果循环依赖的时候，所有类又都需要Spring AOP自动代理，那Spring如何提前曝光？曝光的是原始bean还是代理后的bean？

这些问题算是Spring源码的压轴题了，如果这些问题都弄明白，恭喜你顺利结业Spring源码了。就单单对Spring这一块的理解，不夸张的说可以达到阿里水准了

源码分析

进入正题，在Spring创建Bean的核心代码doGetBean中，在实例化bean之前，会先尝试从三级缓存获取bean，这也是Spring解决循环依赖的开始

（一）缓存中获取bean

// AbstractBeanFactory.java
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
   @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {

  final String beanName = transformedBeanName(name);
  Object bean;

  // 2. 尝试从缓存中获取bean
  Object sharedInstance = getSingleton(beanName);
  ...
}
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
 // 从一级缓存获取，key=beanName value=bean
 Object singletonObject = this.singletonObjects.get(beanName);
 if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
  synchronized (this.singletonObjects) {
   // 从二级缓存获取，key=beanName value=bean
   singletonObject = this.earlySingletonObjects.get(beanName);
   // 是否允许循环引用
   if (singletonObject == null && allowEarlyReference) {
    /**
     * 三级缓存获取，key=beanName value=objectFactory，objectFactory中存储getObject()方法用于获取提前曝光的实例
     *
     * 而为什么不直接将实例缓存到二级缓存，而要多此一举将实例先封装到objectFactory中？
     * 主要关键点在getObject()方法并非直接返回实例，而是对实例又使用
     * SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法对bean进行处理
     *
     * 也就是说，当spring中存在该后置处理器，所有的单例bean在实例化后都会被进行提前曝光到三级缓存中，
     * 但是并不是所有的bean都存在循环依赖，也就是三级缓存到二级缓存的步骤不一定都会被执行，有可能曝光后直接创建完成，没被提前引用过，
     * 就直接被加入到一级缓存中。因此可以确保只有提前曝光且被引用的bean才会进行该后置处理
     */
    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
    if (singletonFactory != null) {
     /**
      * 通过getObject()方法获取bean，通过此方法获取到的实例不单单是提前曝光出来的实例，
      * 它还经过了SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法处理过。
      * 这也正是三级缓存存在的意义，可以通过重写该后置处理器对提前曝光的实例，在被提前引用时进行一些操作
      */
     singletonObject = singletonFactory.getObject();
     // 将三级缓存生产的bean放入二级缓存中
     this.earlySingletonObjects.put(beanName, singletonObject);
     // 删除三级缓存
     this.singletonFactories.remove(beanName);
    }
   }
  }
 }
 return singletonObject;
}

三级缓存分别是：

singletonObject： 一级缓存，该缓存key = beanName, value = bean;这里的bean是已经创建完成的，该bean经历过实例化->属性填充->初始化以及各类的后置处理。因此，一旦需要获取bean时，我们第一时间就会寻找一级缓存
earlySingletonObjects： 二级缓存，该缓存key = beanName, value = bean;这里跟一级缓存的区别在于，该缓存所获取到的bean是提前曝光出来的，是还没创建完成的。也就是说获取到的bean只能确保已经进行了实例化，但是属性填充跟初始化肯定还没有做完，因此该bean还没创建完成，仅仅能作为指针提前曝光，被其他bean所引用
singletonFactories： 三级缓存，该缓存key = beanName, value = beanFactory;在bean实例化完之后，属性填充以及初始化之前，如果允许提前曝光，spring会将实例化后的bean提前曝光，也就是把该bean转换成beanFactory并加入到三级缓存。在需要引用提前曝光对象时再通过singletonFactory.getObject()获取。

这里抛出问题，如果我们直接将提前曝光的对象放到二级缓存earlySingletonObjects，Spring循环依赖时直接取就可以解决循环依赖了，为什么还要三级缓存singletonFactory然后再通过getObject()来获取呢？这不是多此一举？

（二）三级缓存的添加

我们回到添加三级缓存，添加SingletonFactory的地方，看看getObject()到底做了什么操作

this.addSingletonFactory(beanName, () -> {
 return this.getEarlyBeanReference(beanName, mbd, bean);
});

可以看到在返回getObject()时，多做了一步getEarlyBeanReference操作，这步操作是BeanPostProcess的一种，也就是给子类重写的一个后处理器，目的是用于被提前引用时进行拓展。

即：曝光的时候并不调用该后置处理器，只有曝光，且被提前引用的时候才调用，确保了被提前引用这个时机触发。

（三）提前曝光代理earlyProxyReferences

因此所有的重点都落到了getEarlyBeanReference上，getEarlyBeanReference方法是SmartInstantiationAwareBeanPostProcessor所规定的接口。再通过UML的类图查看实现类，仅有AbstractAutoProxyCreator进行了实现。也就是说，除了用户在子类重写，否则仅有AbstractAutoProxyCreator一种情况

// 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代理。

但是经过Spring AOP代理后的bean就已经不再是原来的bean了，经过代理后的bean是一个全新的bean，也就是说代理前后的2个bean连内存地址都不一样了。

这时将再引出新的问题：B提前引用A将引用到A的代理，这是符合常理的，但是最原始的bean A在B完成创建后将继续创建，那么Spring Ioc最后返回的Bean是Bean A呢还是经过代理后的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是一至的，那么就不进行Spring AOP代理了！返回原始的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保存在最后生成的代理$proxy中，当调用$proxy方法时会回调h.invoke，而h.invoke又会回调目标对象target的原始方法。

因此，其实在Spring AOP动态代理时，原始bean已经被保存在提前曝光代理中了。而后原始Bean继续完成属性填充和初始化操作。因为AOP代理$proxy中保存着traget也就是是原始bean的引用，因此后续原始bean的完善，也就相当于Spring AOP中的target的完善，这样就保证了Spring AOP的属性填充与初始化了！

（五）循环依赖遇上Spring AOP 图解

为了帮助大家理解，这里灵魂画手画张流程图帮助大家理解

首先又bean A，bean B，他们循环依赖注入，同时bean A还需要被Spring AOP代理，例如事务管理或者日志之类的操作。原始bean A，bean B图中用a，b表示，而代理后的bean A我们用aop.a表示

看完也算是Spring的顺利结业了！

画图不易，看懂的小伙伴给个赞，有什么不明白的或者写的有误的地方欢迎评论交流！

芋道源码 —— 纯源码解析博客

Spring源码最难问题：当Spring AOP遇上循环依赖

前言

问：Spring如何解决循环依赖？

再问：Spring通过提前曝光，直接曝光到二级缓存已经可以解决循环依赖问题了，为什么一定要三级缓存？

再细问：如果循环依赖的时候，所有类又都需要Spring AOP自动代理，那Spring如何提前曝光？曝光的是原始bean还是代理后的bean？

源码分析

（一）缓存中获取bean

（二）三级缓存的添加

（三）提前曝光代理earlyProxyReferences

（四）提前AOP代理对象的属性填充、初始化

（五）循环依赖遇上Spring AOP 图解

前言

问：Spring如何解决循环依赖？

再问：Spring通过提前曝光，直接曝光到二级缓存已经可以解决循环依赖问题了，为什么一定要三级缓存？

再细问：如果循环依赖的时候，所有类又都需要Spring AOP自动代理，那Spring如何提前曝光？曝光的是原始bean还是代理后的bean？

源码分析

（一） 缓存中获取bean

（二） 三级缓存的添加

（三） 提前曝光代理earlyProxyReferences

（四） 提前AOP代理对象的 属性填充、初始化

（五） 循环依赖遇上Spring AOP 图解

（一）缓存中获取bean

（二）三级缓存的添加

（三）提前曝光代理earlyProxyReferences

（四）提前AOP代理对象的属性填充、初始化

（五）循环依赖遇上Spring AOP 图解