跳出源码地狱,Spring巧用三级缓存解决循环依赖-原理篇

有道无术,术尚可求也!有术无道,止于术!

一、循环依赖所产生的原因

在探讨Spring三级缓存解决循环引用之前,我们需要了解一点就是Spring所谓的循环依赖到底是什么,是如何产生的,为什么会产生这种问题?

这就是经典的一个循环引用的问题,一个类的实例化依赖另外一个类,如果我们不使用Spring管理这两个bean而是自己手动创建,这种循环引用的方式实现极其简单:

为什么Spring解决循环依赖比较麻烦呢?因为Spring创建一个Bean是需要通过反射来构建的,构建过程中无法感知这个类具体是什么类型的,它只能够实例化一个填充一个实体!于是:

  • 创建 UserServiceImpl完成后发现依赖EmailServiceImpl
  • 于是创建EmailServiceImpl ,但是创建完成后又发现依赖于UserServiceImpl
  • 于是又去创建UserServiceImpl,又发现EmailServiceImpl
  • 然后我又去创建EmailServiceImpl
  • ........

一直循环往复,从而产生了循环依赖的问题!由此我们循环不断的创建,从而造成了不断的死循环,此时Spring会抛出BeanCurrentlyInCreationException异常!

如何解决这个问题呢?循环依赖的矛盾点就在于要创建UserServiceImpl,它需要EmailServiceImpl ,而创建EmailServiceImpl ,又需要UserServiceImpl,然后两个bean都创建不出来!

二、如何解决循环依赖

我们可以创建两个容器(Map),一个起名为singletonObjects,一个起名为earlySingletonObjects!

  • 「singletonObjects」:单例池,我们去存放已经创建完成,并且属性也注入完毕的对象!
  • 「earlySingletonObjects」:提前暴露的对象,存放已经创建完成,但是没有注入好的对象!

我们有了这两个Map对象,那么我们再次试图创建一个被循环依赖的bean!

  • 创建 UserServiceImpl完成后,把自己存到「earlySingletonObjects」里面去,然后发现依赖EmailServiceImpl
  • 于是试图从「singletonObjects」寻找,很显然是没有的,然后到「earlySingletonObjects」里面寻找发现也没有,开始新建!
  • 创建EmailServiceImpl 完成后,把自己存放到「earlySingletonObjects」里面去,然后发现依赖UserServiceImpl
  • 于是试图从「singletonObjects」寻找,很显然是没有的,然后到「earlySingletonObjects」里面寻找,发现了UserServiceImpl对象!
  • 「earlySingletonObjects」返回的对象UserServiceImpl设置到EmailServiceImpl 中去,创建完成!
  • 把自己放置到「singletonObjects」里面,然后把自己从「earlySingletonObjects」删除掉!返回!
  • UserServiceImpl将返回的EmailServiceImpl 设置到对应的属性中,创建完成!
  • 把自己放置到「singletonObjects」里面,然后把自己从「earlySingletonObjects」删除掉!返回!

至此我们解决了循环引用的问题!

由此至少,解决循环依赖,我们现在至少知道需要两个条件:

  • 循环依赖的解决必须要经过反射创建对象这一步,如果你不使用属性注入,转而使用构造参数注入就会出问题,因为Spring都没有办法实例化对象,就更不要谈属性注入了!
  • 循环依赖的bean必须是单例的,如果不是单例的,就会出现我们上面说的无限循环的问题!

「图例」

image-20200923141100566

三、Spring为什么使用三级缓存解决呢?

通过上面的解释我们大概明白了循环依赖的解决方案,Spring也是这样解决的,但是Spring所考虑的要比我们详细的多,我们明明采用二级缓存就能够解决循环依赖,但是Spring为什么使用了三级缓存呢?

我们先来了解一下Spring每个缓存的名字及其作用:

  • 「singletonObjects」:单例池,我们去存放已经创建完成,并且属性也注入完毕的对象!
  • 「earlySingletonObjects」:提前暴露的对象,存放已经创建完成,但是没有注入好的对象!
  • **singletonFactories:**提前暴露的对象,存放已经创建完成,但是还没有注入好的对象的工厂对象!通过这个工厂可以返回这个对象!

为什么?事实上Spring循环依赖能够被众多人提起,其根本原因就是明明使用二级缓存就能够解决的问题,为什么偏偏要使用三级缓存去解决呢?

我们上面的设计方案是能够很好的解决循环依赖所带来的问题,但是请大家思考一个问题:

❝我们创建的bean所依赖的对象是一个需要被Aop代理的对象,怎么办?遇到这种情况,我们肯定不能够直接把创建完成的对象放到缓存中去的!为什么,因为我们期望的注入的是一个被代理后的对象,而不是一个原始对象!
所以这里并不能够直接将一个原始对象放置到缓存中,我们可以直接进行判断,如果需要Aop的话进行代理之后放入缓存!
但是,请大家想一下,上一篇复习中Aop的操作是在哪里做的?是在Spring声明周期的最后一步来做的!但是,如果我们进行判断创建的话,Aop的代理逻辑就会在创建实例的时候就进行Aop的代理了,这明显是不符合Spring对于Bean生命周期的定义的!
所以,Spring由重新定义了一个缓存【「singletonFactories」】用来存放一个Bean的工厂对象,创建的对象之后,填充属性之前会把创建好的对象放置到【「singletonFactories」】缓存中去,并不进行实例化,只有在发生了循环引用,或者有对象依赖他的时候,他才会调用工厂方法返回一个代理对象,从而保证了Spring对于Bean生命周期的定义!

我们先看一下关于三级缓存的定义!

会发现,他并不像一级缓存和二级缓存一样,放的是Bean的对象,他存放的是一个ObjectFactory对象,这个对象是干什么呢?我们需要继续深入!

这个就是Spring三级缓存里面对ObjectFactory的实现!大致功能就是,遍历所有的BeanPostProcessor后置处理器,如果找到了SmartInstantiationAwareBeanPostProcessor类型的后置处理器,也就是处理Aop的后置处理器,就返回一个Aop处理后的对象,如果该类没有被代理就返回一个传入的bean!

im

四、从源码上看循环引用

首先,我们会先创建对象【「UserServiceImpl」】的时候会先从缓存中获取一下,获取到直接返回,获取不到在创建!

第一次获取肯定为null,因为没有任何人往这些缓存里面放数据!获取到空对象之后,开始创建对象!

创建对象完成之后,把这个对象包装成工厂对象,然后放到三级缓存!

然后,开始进行属性的填充【「EmailServiceImpl」】!

填充过程中,调用getBean 查询缓存中是否存在需要注入的对象

我们会发现,此时又回到了第一步的逻辑,也是获取不到任何对象!于是往下走,开始创建对象,然后将创建好的对象【「EmailServiceImpl」】放置到三级缓存!

然后再次开始属性注入,发现依赖【UserServiceImpl】,于是再次开始尝试用bean容器里面获取【UserServiceImpl】,于是再次走到第一步!

但是这一次和以往不同,在获取【UserSercieImpl】的时候,因为在创建的时候已经放置到了三级缓存中去,此时是能够获取到数据的!

于是这个对象就被返回,注入到对应的属性,一路返回到,注入完成,初始化完成,走完整个【EmailServiceImpl】Bean的生命周期!然后一路返回到,创建bean的调用处!将【EmailServiceImpl】放到一级缓存里面

然后再次返回这个对象,到**【UserServciceImpl】「的注入逻辑,最终」【EmailServiceImpl】**被注入到UserServiceImpl,然后UserServiceImpl也返回到创建Bean的调用处,放置到一级缓存,最终整个循环引用彻底完成!

本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
跳出源码地狱,Spring巧用三级缓存解决循环依赖-原理篇
在探讨Spring三级缓存解决循环引用之前,我们需要了解一点就是Spring所谓的循环依赖到底是什么,是如何产生的,为什么会产生这种问题?
<<上一篇
下一篇>>