一文告诉你Spring是如何利用“三级缓存“巧妙解决Bean的循环依赖问题的【享学Spring】（中）-阿里云开发者社区

getSingleton()从缓存里获取单例对象步骤分析可知，Spring解决循环依赖的诀窍：就在于singletonFactories这个三级缓存。这个Cache里面都是ObjectFactory，它是解决问题的关键。

// 它可以将创建对象的步骤封装到ObjectFactory中 交给自定义的Scope来选择是否需要创建对象来灵活的实现scope。  具体参见Scope接口
@FunctionalInterface
public interface ObjectFactory<T> {
  T getObject() throws BeansException;
}

经过ObjectFactory.getObject()后，此时放进了二级缓存earlySingletonObjects内。这个时候对象已经实例化了，虽然还不完美，但是对象的引用已经可以被其它引用了。

此处说一下二级缓存earlySingletonObjects它里面的数据什么时候添加什么移除？？?

添加：向里面添加数据只有一个地方，就是上面说的getSingleton()里从三级缓存里挪过来

移除：addSingleton、addSingletonFactory、removeSingleton从语义中可以看出添加单例、添加单例工厂ObjectFactory的时候都会删除二级缓存里面对应的缓存值，是互斥的

源码解析

Spring容器会将每一个正在创建的Bean 标识符放在一个“当前创建Bean池”中，Bean标识符在创建过程中将一直保持在这个池中，而对于创建完毕的Bean将从当前创建Bean池中清除掉。

这个“当前创建Bean池”指的是上面提到的singletonsCurrentlyInCreation那个集合。

public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
  ...
  protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
    ...
    // Eagerly check singleton cache for manually registered singletons.
    // 先去获取一次，如果不为null，此处就会走缓存了~~
    Object sharedInstance = getSingleton(beanName);
    ...
    // 如果不是只检查类型，那就标记这个Bean被创建了~~添加到缓存里 也就是所谓的  当前创建Bean池
    if (!typeCheckOnly) {
      markBeanAsCreated(beanName);
    }
    ...
    // Create bean instance.
    if (mbd.isSingleton()) {
      // 这个getSingleton方法不是SingletonBeanRegistry的接口方法  属于实现类DefaultSingletonBeanRegistry的一个public重载方法~~~
      // 它的特点是在执行singletonFactory.getObject();前后会执行beforeSingletonCreation(beanName);和afterSingletonCreation(beanName);  
      // 也就是保证这个Bean在创建过程中，放入正在创建的缓存池里  可以看到它实际创建bean调用的是我们的createBean方法~~~~
      sharedInstance = getSingleton(beanName, () -> {
        try {
          return createBean(beanName, mbd, args);
        } catch (BeansException ex) {
          destroySingleton(beanName);
          throw ex;
        }
      });
      bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
    }
  }
  ...
}
// 抽象方法createBean所在地  这个接口方法是属于抽象父类AbstractBeanFactory的   实现在这个抽象类里
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory implements AutowireCapableBeanFactory {
  ...
  protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException {
    ...
    // 创建Bean对象，并且将对象包裹在BeanWrapper 中
    instanceWrapper = createBeanInstance(beanName, mbd, args);
    // 再从Wrapper中把Bean原始对象（非代理~~~）  这个时候这个Bean就有地址值了，就能被引用了~~~
    // 注意：此处是原始对象，这点非常的重要
    final Object bean = instanceWrapper.getWrappedInstance();
    ...
    // earlySingletonExposure 用于表示是否”提前暴露“原始对象的引用，用于解决循环依赖。
    // 对于单例Bean，该变量一般为 true   但你也可以通过属性allowCircularReferences = false来关闭循环引用
    // isSingletonCurrentlyInCreation(beanName) 表示当前bean必须在创建中才行
    boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
    if (earlySingletonExposure) {
      if (logger.isTraceEnabled()) {
        logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");
      }
      // 上面讲过调用此方法放进一个ObjectFactory，二级缓存会对应删除的
      // getEarlyBeanReference的作用：调用SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference()这个方法  否则啥都不做
      // 也就是给调用者个机会，自己去实现暴露这个bean的应用的逻辑~~~
      // 比如在getEarlyBeanReference()里可以实现AOP的逻辑~~~  参考自动代理创建器AbstractAutoProxyCreator  实现了这个方法来创建代理对象
      // 若不需要执行AOP的逻辑，直接返回Bean
      addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
    }
    Object exposedObject = bean; //exposedObject 是最终返回的对象
    ...
    // 填充属于，解决@Autowired依赖~
    populateBean(beanName, mbd, instanceWrapper);
    // 执行初始化回调方法们~~~
    exposedObject = initializeBean(beanName, exposedObject, mbd);
    // earlySingletonExposure：如果你的bean允许被早期暴露出去 也就是说可以被循环引用  那这里就会进行检查
    // 此段代码非常重要~~~~~但大多数人都忽略了它
    if (earlySingletonExposure) {
      // 此时一级缓存肯定还没数据，但是呢此时候二级缓存earlySingletonObjects也没数据
      //注意，注意：第二参数为false  表示不会再去三级缓存里查了~~~
      // 此处非常巧妙的一点：：：因为上面各式各样的实例化、初始化的后置处理器都执行了，如果你在上面执行了这一句
      //  ((ConfigurableListableBeanFactory)this.beanFactory).registerSingleton(beanName, bean);
      // 那么此处得到的earlySingletonReference 的引用最终会是你手动放进去的Bean最终返回，完美的实现了"偷天换日" 特别适合中间件的设计
      // 我们知道，执行完此doCreateBean后执行addSingleton()  其实就是把自己再添加一次  **再一次强调，完美实现偷天换日**
      Object earlySingletonReference = getSingleton(beanName, false);
      if (earlySingletonReference != null) {
        // 这个意思是如果经过了initializeBean()后，exposedObject还是木有变，那就可以大胆放心的返回了
        // initializeBean会调用后置处理器，这个时候可以生成一个代理对象，那这个时候它哥俩就不会相等了 走else去判断吧
        if (exposedObject == bean) {
          exposedObject = earlySingletonReference;
        } 
        // allowRawInjectionDespiteWrapping这个值默认是false
        // hasDependentBean：若它有依赖的bean 那就需要继续校验了~~~(若没有依赖的 就放过它~)
        else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
          // 拿到它所依赖的Bean们~~~~ 下面会遍历一个一个的去看~~
          String[] dependentBeans = getDependentBeans(beanName);
          Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
          // 一个个检查它所以Bean
          // removeSingletonIfCreatedForTypeCheckOnly这个放见下面  在AbstractBeanFactory里面
          // 简单的说，它如果判断到该dependentBean并没有在创建中的了的情况下,那就把它从所有缓存中移除~~~  并且返回true
          // 否则（比如确实在创建中） 那就返回false 进入我们的if里面~  表示所谓的真正依赖
          //（解释：就是真的需要依赖它先实例化，才能实例化自己的依赖）
          for (String dependentBean : dependentBeans) {
            if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
              actualDependentBeans.add(dependentBean);
            }
          }
          // 若存在真正依赖，那就报错（不要等到内存移除你才报错，那是非常不友好的） 
          // 这个异常是BeanCurrentlyInCreationException，报错日志也稍微留意一下，方便定位错误~~~~
          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.");
          }
        }
      }
    }
    return exposedObject;
  }
  // 虽然是remove方法 但是它的返回值也非常重要
  // 该方法唯一调用的地方就是循环依赖的最后检查处~~~~~
  protected boolean removeSingletonIfCreatedForTypeCheckOnly(String beanName) {
    // 如果这个bean不在创建中  比如是ForTypeCheckOnly的  那就移除掉
    if (!this.alreadyCreated.contains(beanName)) {
      removeSingleton(beanName);
      return true;
    }
    else {
      return false;
    }
  }
}

这里举例：例如是field属性依赖注入，在populateBean时它就会先去完成它所依赖注入的那个bean的实例化、初始化过程，最终返回到本流程继续处理，因此Spring这样处理是不存在任何问题的。

这里有个小细节：

if (exposedObject == bean) {
  exposedObject = earlySingletonReference;
}

这一句如果exposedObject == bean表示最终返回的对象就是原始对象，说明在populateBean和initializeBean没对他代理过，那就啥话都不说了exposedObject = earlySingletonReference，最终把二级缓存里的引用返回即可~

流程总结（非常重要）

此处以如上的A、B类的互相依赖注入为例，在这里表达出关键代码的走势：

1、入口处即是实例化、初始化A这个单例Bean。AbstractBeanFactory.doGetBean("a")

protected <T> T doGetBean(...){
  ... 
  // 标记beanName a是已经创建过至少一次的~~~ 它会一直存留在缓存里不会被移除（除非抛出了异常）
  // 参见缓存Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256))
  if (!typeCheckOnly) {
    markBeanAsCreated(beanName);
  }
  // 此时a不存在任何一级缓存中，且不是在创建中  所以此处返回null
  // 此处若不为null，然后从缓存里拿就可以了(主要处理FactoryBean和BeanFactory情况吧)
  Object beanInstance = getSingleton(beanName, false);
  ...
  // 这个getSingleton方法非常关键。
  //1、标注a正在创建中~
  //2、调用singletonObject = singletonFactory.getObject();（实际上调用的是createBean()方法）  因此这一步最为关键
  //3、此时实例已经创建完成  会把a移除整整创建的缓存中
  //4、执行addSingleton()添加进去。（备注：注册bean的接口方法为registerSingleton，它依赖于addSingleton方法）
  sharedInstance = getSingleton(beanName, () -> { ... return createBean(beanName, mbd, args); });
}

2、下面进入到最为复杂的AbstractAutowireCapableBeanFactory.createBean/doCreateBean()环节，创建A的实例

protected Object doCreateBean(){
  ...
  // 使用构造器/工厂方法   instanceWrapper是一个BeanWrapper
  instanceWrapper = createBeanInstance(beanName, mbd, args);
  // 此处bean为"原始Bean"   也就是这里的A实例对象：A@1234
  final Object bean = instanceWrapper.getWrappedInstance();
  ...
  // 是否要提前暴露（允许循环依赖）  现在此处A是被允许的
  boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
  // 允许暴露，就把A绑定在ObjectFactory上，注册到三级缓存`singletonFactories`里面去保存着
  // Tips:这里后置处理器的getEarlyBeanReference方法会被促发，自动代理创建器在此处创建代理对象（注意执行时机 为执行三级缓存的时候）
  if (earlySingletonExposure) {
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
  }
  ...
  // exposedObject 为最终返回的对象，此处为原始对象bean也就是A@1234,下面会有用处
  Object exposedObject = bean; 
  // 给A@1234属性完成赋值，@Autowired在此处起作用~
  // 因此此处会调用getBean("b")，so 会重复上面步骤创建B类的实例
  // 此处我们假设B已经创建好了 为B@5678
  // 需要注意的是在populateBean("b")的时候依赖有beanA，所以此时候调用getBean("a")最终会调用getSingleton("a")，
  //此时候上面说到的getEarlyBeanReference方法就会被执行。这也解释为何我们@Autowired是个代理对象，而不是普通对象的根本原因
  populateBean(beanName, mbd, instanceWrapper);
  // 实例化。这里会执行后置处理器BeanPostProcessor的两个方法
  // 此处注意：postProcessAfterInitialization()是有可能返回一个代理对象的，这样exposedObject 就不再是原始对象了  特备注意哦~~~
  // 比如处理@Aysnc的AsyncAnnotationBeanPostProcessor它就是在这个时间里生成代理对象的（有坑，请小心使用@Aysnc）
  exposedObject = initializeBean(beanName, exposedObject, mbd);
  ... // 至此，相当于A@1234已经实例化完成、初始化完成（属性也全部赋值了~）
  // 这一步我把它理解为校验：校验：校验是否有循环引用问题~~~~~
  if (earlySingletonExposure) {
    // 注意此处第二个参数传的false，表示不去三级缓存里singletonFactories再去调用一次getObject()方法了~~~
    // 上面建讲到了由于B在初始化的时候，会触发A的ObjectFactory.getObject()  所以a此处已经在二级缓存earlySingletonObjects里了
    // 因此此处返回A的实例：A@1234
    Object earlySingletonReference = getSingleton(beanName, false);
    if (earlySingletonReference != null) {
      // 这个等式表示，exposedObject若没有再被代理过，这里就是相等的
      // 显然此处我们的a对象的exposedObject它是没有被代理过的  所以if会进去~
      // 这种情况至此，就全部结束了~~~
      if (exposedObject == bean) {
        exposedObject = earlySingletonReference;
      }
      // 继续以A为例，比如方法标注了@Aysnc注解，exposedObject此时候就是一个代理对象，因此就会进到这里来
      //hasDependentBean(beanName)是肯定为true，因为getDependentBeans(beanName)得到的是["b"]这个依赖
      else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
        String[] dependentBeans = getDependentBeans(beanName);
        Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
        // A@1234依赖的是["b"]，所以此处去检查b
        // 如果最终存在实际依赖的bean：actualDependentBeans不为空 那就抛出异常  证明循环引用了~
        for (String dependentBean : dependentBeans) {
          // 这个判断原则是：如果此时候b并还没有创建好，this.alreadyCreated.contains(beanName)=true表示此bean已经被创建过，就返回false
          // 若该bean没有在alreadyCreated缓存里，就是说没被创建过(其实只有CreatedForTypeCheckOnly才会是此仓库)
          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.");
        }
      }
    }
  }
}

由于关键代码部分的步骤不太好拆分，为了更具象表达，那么使用下面一副图示帮助小伙伴们理解：

最后的最后，由于我太暖心了_，再来个纯文字版的总结。

依旧以上面A、B类使用属性field注入循环依赖的例子为例，对整个流程做文字步骤总结如下：

使用context.getBean(A.class)，旨在获取容器内的单例A(若A不存在，就会走A这个Bean的创建流程)，显然初次获取A是不存在的，因此走A的创建之路~
实例化A（注意此处仅仅是实例化），并将它放进缓存（此时A已经实例化完成，已经可以被引用了）
初始化A：@Autowired依赖注入B（此时需要去容器内获取B）
为了完成依赖注入B，会通过getBean(B)去容器内找B。但此时B在容器内不存在，就走向B的创建之路~
实例化B，并将其放入缓存。（此时B也能够被引用了）
初始化B，@Autowired依赖注入A（此时需要去容器内获取A）
此处重要：初始化B时会调用getBean(A)去容器内找到A，上面我们已经说过了此时候因为A已经实例化完成了并且放进了缓存里，所以这个时候去看缓存里是已经存在A的引用了的，所以getBean(A)能够正常返回
B初始化成功（此时已经注入A成功了，已成功持有A的引用了），return（注意此处return相当于是返回最上面的getBean(B)这句代码，回到了初始化A的流程中~）。
因为B实例已经成功返回了，因此最终A也初始化成功
到此，B持有的已经是初始化完成的A，A持有的也是初始化完成的B，完美~

站的角度高一点，宏观上看Spring处理循环依赖的整个流程就是如此。希望这个宏观层面的总结能更加有助于小伙伴们对Spring解决循环依赖的原理的了解，同时也顺便能解释为何构造器循环依赖就不好使的原因。

一文告诉你Spring是如何利用“三级缓存“巧妙解决Bean的循环依赖问题的【享学Spring】（中）

源码解析

流程总结（非常重要）

热门文章

最新文章

相关课程

相关电子书

相关实验场景