0源码基础学习Spring源码系列（二）——Spring如何解决循环依赖-六虎

作者：作者：京东科技韩国凯

导读：本篇文章适用于0根底学习spring源码，文章重点解析spring怎么处理循环依靠，并从处理循环依靠进程、三级缓存在循环依靠中的效果、处理署理方针的问题、二级缓存、初始化几个维度出发，解析spring 源码。

1.1 处理循环依靠进程

1.1.1 三级缓存的效果

循环依靠在咱们日常开发中归于比较常见的问题，spring对循环依靠做了优化，使得咱们在无感知的状况下协助咱们处理了循环依靠的问题。

最简略的循环依靠便是，A依靠B，B依靠C，C依靠A，假如不处理循环依靠的问题终究会导致OOM，可是也不是一切的循环依靠都能够处理，spring只能够处理通过特点或许setter注入的单例bean，而通过构造器注入或非单例形式的bean都是不可处理的。

通过上文创立bean的进程中咱们知道，在获取bean的时分，首要会测验从缓存中获取，假如从缓存中获取不到才会去创立bean，而三层的缓存正是处理循环依靠的要害：

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
   // Quick check for existing instance without full singleton lock
   //从一级缓存中加载
   Object singletonObject = this.singletonObjects.get(beanName);
   if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
      //从二级缓存中加载
      singletonObject = this.earlySingletonObjects.get(beanName);
      //allowEarlyReference为true代表要去三级缓存中查找，此刻为true
      if (singletonObject == null && allowEarlyReference) {
         synchronized (this.singletonObjects) {
            singletonObject = this.singletonObjects.get(beanName);
            if (singletonObject == null) {
               singletonObject = this.earlySingletonObjects.get(beanName);
               if (singletonObject == null) {
                  //从三级缓存中加载
                  ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                  if (singletonFactory != null) {
                     singletonObject = singletonFactory.getObject();
                     this.earlySingletonObjects.put(beanName, singletonObject);
                     this.singletonFactories.remove(beanName);
                  }
               }
            }
         }
      }
   }
   return singletonObject;
}

能够看到三层缓存其实便是三个hashmap:

/** Cache of singleton objects: bean name to bean instance. */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
/** Cache of singleton factories: bean name to ObjectFactory. */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
/** Cache of early singleton objects: bean name to bean instance. */
private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);

三级缓存的效果：

singletonObjects：用于寄存彻底初始化好的 bean，从该缓存中取出的 bean 能够直接运用
earlySingletonObjects：提早曝光的单例方针的cache，寄存原始的 bean 方针（没有填充特点），用于处理循环依靠
singletonFactories：单例方针工厂的cache，寄存 bean 工厂方针，用于处理循环依靠

1.1.2 处理循环依靠的流程

依据上文，咱们都知道创立bean的流程首要包含以下三步：

实例化bean
安装bean特点
初始化bean

例如咱们现在有 A依靠B，B依靠A，那么spring是怎么处理三层循环的呢？

首要测验从缓存中加载A，发现A不存在
实例化A（没有特点，半制品）
将实例化完结的A放入第三级缓存中
安装特点B（没有特点，半制品）
测验从缓存中加载B，发现B不存在
实例化B
将实例化完结的B放入第三级缓存中
安装特点A
测验从缓存中加载A，发现A存在于缓存中（第3步），将A从第三级缓存中移除，放入第二级缓存中，并将其赋值给B，B安装特点完结
此刻B的安装特点完毕，初始化B，并将B从三级缓存中移除，放入一级缓存
回来第四步，此刻A的特点也安装完结
初始化A，并将A放入一级缓存

自此，实例A于B都分别完结了创立的流程。

用一张图来描述：

那么此刻有一个问题，在第9步中B具有的A是只实例化完结的方针，并没有特点安装以及初始化，A的初始化是在11步今后，那么在最后悉数创立完结此刻B中的的特点A是半制品仍是现已能够正常作业的制品呢？答案是制品，由于B对A能够理解为引证传递，也便是说B中的特点A于第11步之前的A为同一个A，那么A在第11步完结了特点安装，天然B中的特点也会完结特点安装。

例如咱们在一个办法中传入一个实例化方针，假如在办法中对实例化方针做了修正，那么在办法完毕后该实例化方针也会做出修正，需求留意的是实例化方针，而不是java中的几种基本方针，基本方针是归于值传递（其实实例化方针也是值传递，不过传入的是方针的引证，能够理解为引证传递）。

private static void fun3(){
    Student student = new Student();
    student.setName("zhangsan");
    System.out.println(student.getName());
    changeName(student);
    System.out.println(student.getName());
    String str = "zhangsan";
    System.out.println(str);
    changeString(str);
    System.out.println(str);
}
private static void changeName(Student student){
    student.setName("lisi");
}
private static void changeString(String str){
    str = "lisi";
}
//输出成果
zhangsan
lisi
zhangsan
zhangsan

能够看出引证传递会改动方针，而值传递不会。

2.2 为什么是三层缓存

2.2.1 三级缓存在循环依靠中的效果

有的小伙伴可能现已留意到了，为什么需求三层缓存，两层缓存如同就能够处理问题了，可是假如不考虑署理的状况下确实两层缓存就能处理问题，可是假如要引证的方针不是一般bean而是被署理的方针就会出现问题。

大家需求知道的是，spring在创立署理方针时，首要会实例化源方针，然后在源方针初始化完结之后才会获取署理方针。

咱们先不考虑为什么是三级缓存，先看一下在刚才的流程中署理方针存在什么问题

回到咱们刚刚举的比如，加入现在咱们需求署理方针A，其间A依靠于B，而B也是署理方针，假如不进行特殊处理的话会出现问题：

首要测验从缓存中加载A，发现A不存在

实例化A（没有特点，半制品）

将实例化完结的A放入第三级缓存中

安装特点B（没有特点，半制品）

测验从缓存中加载B，发现B不存在

实例化B

将实例化完结的B放入第三级缓存中

安装特点A

测验从缓存中加载A，发现A存在于缓存中（第3步），将A从第三级缓存中移除，放入第二级缓存中，并将其赋值给B，B安装特点完结

此刻B的安装特点完毕，初始化B，并将B从三级缓存中移除，放入一级缓存

回来第四步，此刻A的特点也安装完结

初始化A，并将A放入一级缓存

跟之前相同的流程，那么此刻B具有的方针是A的一般方针，而不是署理方针，这就有问题了。

可能有同学会问，不是存在引证传递吗？A被署理完结不是仍是会被B所具有吗？

可是答案也很简略，并不是，A跟A的署理方针肯定时两个方针，在内存中肯定也是两个地址，因而需求处理这种状况。

2.2.2 处理署理方针的问题

咱们来看看spring是怎么处理这个问题的：

依据bean创立的进程咱们知道，bean会首要被实例化，在实例化完结之后会执行这样一段代码：

//3.是否需求提早曝光，用来处理循环依靠时运用
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");
   }
   addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

这也是咱们2.2.5（详见上篇文章）中的代码，首要有两部分

首要会判别是否需求提早曝光，判别成果由三部分组成，分别是：

是否是单例形式，默许状况下都是单例形式，spring也只能处理这种状况下的循环依靠
是否答应提早曝光，默许是true，也能够更改
是否正在创立，正常来说一个bean在创立开始该值为true，创立完毕该值为false

能够看到正常状况下一个bean的这些成果都为true，也便是会进入到下面的办法中，该办法中有一个lamda表达式，为了可读性这儿进行了拆分。

ObjectFactory<Object> objectFactory = new ObjectFactory<Object>() {
   @Override
   public Object getObject() throws BeansException {
      return getEarlyBeanReference(beanName, mbd, bean);
   }
} ;
addSingletonFactory(beanName, objectFactory);

该办法的首要内容便是创立了一个ObjectFactory，其间getObject()办法回来了getEarlyBeanReference(beanName, mbd, bean)这个办法调用成果。

看看addSingletonFactory()这个办法都干了什么

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
   Assert.notNull(singletonFactory, "Singleton factory must not be null");
   synchronized (this.singletonObjects) {
      if (!this.singletonObjects.containsKey(beanName)) {
         //向三级缓存中增加内容
         this.singletonFactories.put(beanName, singletonFactory);
         this.earlySingletonObjects.remove(beanName);
         this.registeredSingletons.add(beanName);
      }
   }
}

其间最首要的一行代码便是向三级缓存中增加了方针，而增加的方针便是传入的objectFactory，留意，此处增加的不是bean，而是factory。这也是咱们上文处理循环依靠进程中第三步的操作。

加入存在循环依靠的话，此刻A现已被加入到缓存中，当A被作为依靠被其他bean运用时，依照咱们之前的逻辑会调用缓存

//从三级缓存中加载
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
   //从刚刚增加的objectFactory获取其间的方针，也便是调用getObject，也便是获取getEarlyBeanReference办法的内容
   singletonObject = singletonFactory.getObject();
   this.earlySingletonObjects.put(beanName, singletonObject);
   this.singletonFactories.remove(beanName);
}

从刚刚增加的objectFactory获取其间的方针，也便是调用getObject，也便是获取getEarlyBeanReference办法的内容

那么咱们看看为什么会回来一个factory而不是一个bean

exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);

return wrapIfNecessary(bean, beanName, cacheKey);

依据链路能够看到，终究调用到这个办法中回来的，也便是说当实例A被别的bean依靠时，回来的其实是这个办法中的成果。

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;
   }
   // 假如是一个需求被署理方针的话，会在此处回来被署理的方针
   Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
   if (specificInterceptors != DO_NOT_PROXY) {
      this.advisedBeans.put(cacheKey, Boolean.TRUE);
      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;
}

看到这儿应该便是一目了然了spring是怎么处理存在署理方针且存在循环依靠的状况的。

回到之前的逻辑，例如此刻实例B需求装填特点A，会从缓存中查询A是否存咋，查询到A现已存在，则调用A的getObject()办法，假如A是需求被署理的方针则回来被署理过得方针，不然回来一般bean。

此外还需求留意的是：先创立方针，再创立署理类，再初始化原方针，和初始化之后再创立署理类，是相同的，这也是能够提早露出署理方针的根底。

2.2.3 二级缓存的效果

那么二级缓存是干什么用的呢？

addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));

能够在源代码中看出每调用一次getObject()然后调用getEarlyBeanReference()中createProxy()都会发生一个新的署理方针，并不不符合单例形式。

（网上有许多文章说是由于调用lamda表达式所以会发生新的方针，其实假如非署理bean并不会发生新的方针，由于objectFactory所持有的是有原始方针的，即时屡次调用也会回来相同的成果。可是关于署理方针则会每次新create一个，所以其实会发生新的署理方针而不会是新发生一般方针。所以就其实质为什么运用二级缓存的原因是由于创立署理方针是运用createProxy()的办法，每次调用都会发生新的署理方针，那么其实只要有一个当地能依据beanName回来同一个署理方针，也就不需求二级缓存了，这也是二级缓存的实质含义。其实也能够在getObject()办法中去缓存创立完结的署理方针，只不过这样做就太不高雅，不太符合spring的编码标准。）

Object proxy = createProxy(
            bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));

例如A依靠于B，B依靠与A、C、D，而C、D又依靠于A，假如不进行处理的话，A实例化完结之后，在B创立进程中获取A的署理方针A1，然后C、D获取的署理方针便是A2、A3，明显不符合单例形式。

因而需求有一个当地存储从factory中获取到的方针，也便是二级缓存的功用：

if (singletonFactory != null) {
   singletonObject = singletonFactory.getObject();
   //存储获取到的署理方针或一般bean
   this.earlySingletonObjects.put(beanName, singletonObject);
   //此刻三级缓存的工厂现已没有含义了
   this.singletonFactories.remove(beanName);
}

2.2.4 署理方针什么时分被初始化的

本来以为到这儿就完毕了，可是在梳理有署理方针的循环依靠时，忽然又发现一个问题：

仍是A、B都有署理相互依靠的比如，在B安装完A的署理方针后，B初始化完结，A开始初始化，可是此刻的A是原始beanA1，并不是署理方针A2，而B持有的是署理方针A2，那么原始方针A1初始化A2并没有初始化，这不是有问题的吗？

在通过一天的查找以及搜寻材料还有debug后，终于在一篇文章中到答案：

不会，这是由于不管是cglib署理仍是jdk动态署理生成的署理类，内部都持有一个方针类的引证，当调用署理方针的办法时，实践会去调用方针方针的办法，A完结初始化相当于署理方针本身也完结了初始化

也便是说原始方针A1初始化完结后，由于A2是对A1的封装以及增强，也就代表着A2也完结了初始化。

2.2.5 什么时分回来署理方针

此外还有一点需求留意的是，在A1安装完之后，今后其他bean依靠的应该是A2，而且加入到一级缓存中的也应该是A2，那么什么时分A1被换成A2的呢？

//在上方现已判别过，一般为true
if (earlySingletonExposure) {
   //1.留意此处传入的是false，并不会去三级缓存中查找，而且假如是署理方针的话此刻会回来署理方针
   Object earlySingletonReference = getSingleton(beanName, false);
   if (earlySingletonReference != null) {
      //2.判别通过后置处理器后方针是否被改动 ==的话说明没有被改动 那么假如是署理方针的话回来被署理的bean
      if (exposedObject == bean) {
         exposedObject = earlySingletonReference;
      }
      else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
         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 " +
                  "'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");
         }
      }
   }
}

以上有两个需求留意的当地：

由于在之前在B安装特点A的时分，即从三级缓存中查找A的时分，假如查到了会将A的bean(有可能是署理方针)放入二级缓存，然后删去三级缓存，那么此刻getSingleton()回来的便是二级缓存中的bean。
这儿判别通过后置处理器的bean是否被改动，一般是不会改动的，除非实现BeanPostProcessor接口手艺改动。假如没有改动的话则将缓存中的数据取出回来，也便是说假如此刻二级缓存中的是署理beanA2，此刻会回来A2而不是原始方针A1，假如是一般bean的话则都相同。而假如方针现已被改动则走下面的判别有没有可能报错的逻辑。

3.1循环依靠总结

在学习署理在循环依靠的，发现其实并不太需求二级缓存，能够在bean实例化完结之后就挑选要不要生成署理方针，假如要生成的话就往三级缓存中放入署理方针，不然的话就放入一般bean，这样别人过来拿的时分就不用判别是否需求回来署理方针了。

后面发现在网络上有许多跟我想得相同的人，目前参阅别人的主意以及自己进行了总结大概是这样子的：

无论是实例化完结之后就进行方针署理仍是挑选回来一个factory在运用的时分进行署理其实功率上都没有什么区别，只不过一个是提早做一个是滞后做，那么为什么spring挑选滞后做的这件事呢？我自己的考虑是：

道理也很简略，既然功率没有什么提高的话，为什么要破坏一般bean的创立流程，本来循环依靠便是一件十分小概率的事，没必要由于小概率工作而且滞后也能够处理，然后挑选需求修正一般bean的创立逻辑，这无异于是舍本求末，而这也是二级缓存或许说三级缓存中寄存的是factory的含义。

0源码基础学习Spring源码系列（二）——Spring如何解决循环依赖

1.1 处理循环依靠进程

1.1.1 三级缓存的效果

1.1.2 处理循环依靠的流程

2.2 为什么是三层缓存

2.2.1 三级缓存在循环依靠中的效果

2.2.2 处理署理方针的问题

2.2.3 二级缓存的效果

2.2.4 署理方针什么时分被初始化的

2.2.5 什么时分回来署理方针

3.1循环依靠总结

相关文章

Java和Kotlin中的深拷贝与浅拷贝

正式开源！字节安全团队自研敏感信息保护方案 GoDLP

Swift – 闭包

Android的媒体播放器——简易音乐播放器(详解)【转载】

作者信息