Spring一定要用三级缓存吗?

发布于 2021-09-05 00:23

前言

Spring三级缓存的执行细节
https://mp.weixin.qq.com/s?__biz=MzU2NDg5NTYyMQ==&mid=2247483846&idx=1&sn=10a5d1fe0aeeb40f647f99d1562bf901&chksm=fc454b2ccb32c23a4815a4bbfb15f7f3236e32ad41c39748bab896c42cd94b9e49ab526b634a&token=1310368283&lang=zh_CN#rd

分析

三级缓存划分:

  • 一级: 缓存成品bean的map

  • 二级: 缓存半成本bean的map

  • 三级: 缓存生成bean的工厂

问题来了,Spring一定要用三个缓存吗?

首先,在解答这个问题之前要先搞清楚各级缓存的必要性;
级缓存须要有的,这毫无疑问因为Spring初始化完成之后所有的单例bean都要放到一存中去,这是Spring核心中的核所以呢,如果不用三级缓存,就只剩下三种组合一级一级+二级,一级+三级;

一级

其实只用一级缓存也是可以解决循环依赖问题,java的注入无非就是对象的引用,既然是引用那就无所谓成品还是半成品,反正地址都是固定的;
看过上一篇文章的可以知道,Spring二级缓存的使用时机仅仅只在循环依赖的后半段 (AB相互依赖,初始化先A后B) ,只在初始化B的过程中,get到A bean后,会把A入到二级缓存,所以Spring设计二级缓存,我觉得更多的是从软件设计的角度去考虑的,为的是更加清晰地划分bean的生命周期;

一级 + 二级

上面说了,二级缓存本质上是为了更加清晰地划分bean的生命周期,所以判断只保留一二级是否能支持Spring初始化还要看看三级缓存到底解决了什么问题;

一级 + 三级

既然理论上二级缓存的功能可以被一级缓存取代,那么一三这种组合当然是可以支持Spring初始化的,只不过要搞清楚三级缓存存在的意义;
在Spring源码中,三级缓存的定义是:Map<String, ObjectFactory<?>>singletonFactories,准确来讲是一个bean factory,之所以这样设计主要就是因为有的bean并不是以原始bean的形式放进一级缓存的,例如:代理bean, 在Spring切面编程当中,织入了切面的bean是以代理的形式放进一级缓存的,但是这依然不能解释为什么一定要有三级缓存。因为一级缓存的value类型是Object, 照样可以存储bean factory,对于一个普通的切面bean来说,理论上一级缓存也能够解决初始化问题.
例如MVC架构中的controller和service,如果对controller做了切面,初始化流程就是:
  1. 通过构造先实例化controller bean, 然后把创建controller bean的lambda表达式放进一级缓存;

  2. 给controller bean注入service bean, 创建service bean并放进一级缓存;

  3. 完成注入, 重新getBean得到controller bean的代理, 覆盖一级缓存;

你看, 这样做也没毛病!

再来个复杂点的,代理bean相互依赖的场景:

  1. 通过构造先实例化A bean,把A bean的lambda表达式放进一级缓存;

  2. 给A bean注入B bean,查询B bean, 发现没有

  3. 创建B bean,同样的先构造实例化B bean, 把B bean的lambda表达式放进一级缓存;

  4. 给B bean注入A bean,通过getSingleton取A,但是发现A需要代理,于是乎生成A bean的代理;

  5. 此时A bean代理生成后要替换缓存中原有的A bean, 同时注入B bean;

  6. 完成B bean的注入,调用getSingleton重新获取B,发现B也需要代理,于是生成B bean的代理;

  7. 同样的B bean代理要覆盖原有的B,B bean初始化完成!

  8. 回到A bean初始化流程,调用getSingleton重新获取A,发现A已经是代理bean了,直接返回!

  9. 你看, 这样也可以支持,但是有个细节要注意,就是getSingleton的时候要能够判断bean是否已经是代理bean了;

补充一点细节(博客里没写的):循环依赖的代理bean在初始化过程中也是有半成品的,先A后B的场景下,在B的初始化流程中获取A的时候,会生成A的代理,并放到二级缓存,此时代理A中的原始A bean下是不持有B的引用的。只有在回到A的初始化流程之后,继续进行原始A bean的注入(其实就是给原始A bean注入代理好的B bean),才会完成A,B的整个代理初始化!

下图是bean初始化的核心流程:

下面源码中我标注了这四步:

  protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable 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);    }    Object bean = instanceWrapper.getWrappedInstance();    Class<?> beanType = instanceWrapper.getWrappedClass();    if (beanType != NullBean.class) {      mbd.resolvedTargetType = beanType;    }    // Allow post-processors to modify the merged bean definition.    synchronized (mbd.postProcessingLock) {      if (!mbd.postProcessed) {        try {          applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);        }        catch (Throwable ex) {          throw new BeanCreationException(mbd.getResourceDescription(), beanName,              "Post-processing of merged bean definition failed", ex);        }        mbd.postProcessed = true;      }    }        // ====== 2 ======    // Eagerly cache singletons to be able to resolve circular references    // even when triggered by lifecycle interfaces like BeanFactoryAware.    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));    }        // ====== 3 ======    // Initialize the bean instance.    Object exposedObject = bean;    try {      populateBean(beanName, mbd, instanceWrapper);      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);      }    }        // ====== 4 ======    if (earlySingletonExposure) {      Object earlySingletonReference = getSingleton(beanName, false);      if (earlySingletonReference != null) {        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.");          }        }      }    }    // Register bean as disposable.    try {      registerDisposableBeanIfNecessary(beanName, bean, mbd);    }    catch (BeanDefinitionValidationException ex) {      throw new BeanCreationException(          mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);    }    return exposedObject;  }

总结:

理论上讲,只用一个缓存既可以解决循环依赖问题也可以解决代理bean问题,只是过程会比较杂乱,需要对一些细节进行判断,而且对缓存有直接覆盖,不符合软件设计的思想。而bean的创建过程很显然是有不同层级的,也就是bean的生命周期,特别是在循环依赖的场景下,Spring很自然地就把这种生命周期转换成了不同的缓存进行承接存储,使得初始化过程与bean的生命周期一一对应,一级缓存只存储完工的bean,二级缓存过度半成本bean(包括代理半成品bean),三级缓存负责bean的创建,非常清晰明了,分工明确,各司其职,这才是软件设计的经典之处啊!

本文来自网络或网友投稿,如有侵犯您的权益,请发邮件至:aisoutu@outlook.com 我们将第一时间删除。

相关素材