这篇文章主要介绍了怎么使用Spring三级缓存解决循环依赖问题的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇怎么使用Spring三级缓存解决循环依赖问题文章都会有所收获,下面我们一起来看看吧。
循环依赖
什么是循环依赖?很简单,看下方的代码就知晓了
@Servicepublic class A { @Autowired private B b;}@Servicepublic class B { @Autowired private A a;}
上面这两种方式都是循环依赖,应该很好理解,当然也可以是三个 Bean 甚至更多的 Bean 相互依赖,原理都是一样的,今天我们主要分析两个 Bean 的依赖。
这种循环依赖可能会产生问题,例如 A 要依赖 B,发现 B 还没创建。
于是开始创建 B ,创建的过程发现 B 要依赖 A, 而 A 还没创建好呀,因为它要等 B 创建好。
就这样它们俩就搁这卡 bug 了。
解决思路
上面这种循环依赖在实际场景中是会出现的,所以 Spring 需要解决这个问题,那如何解决呢?
关键就是提前暴露未完全创建完毕的 Bean。
在 Spring 中,只有同时满足以下两点才能解决循环依赖的问题:
依赖的 Bean 必须都是单例依赖注入的方式,必须不全是构造器注入,且 beanName 字母序在前的不能是构造器注入
Spring 只支持单例的循环依赖,因为如果两个 Bean 都是原型模式的话:
创建 A1 需要创建一个 B1。
创建 B1 的时候要创建一个 A2。
创建 A2 又要创建一个 B2。
创建 B2 又要创建一个 A3。
创建 A3 又要创建一个 B3…
就又卡 BUG 了,是吧,因为原型模式都需要创建新的对象,不能跟用以前的对象。
如果是单例的话,创建 A 需要创建 B,而创建的 B 需要的是之前的个 A, 不然就不叫单例了,对吧?
也是基于这点, Spring 就能操作操作了。
具体做法就是:先创建 A,此时的 A 是不完整的(没有注入 B),用个 map 保存这个不完整的 A,再创建 B ,B 需要 A。
所以从那个 map 得到“不完整”的 A,此时的 B 就完整了,然后 A 就可以注入 B,然后 A 就完整了,B 也完整了,且它们是相互依赖的。
那为啥必须不全是构造器注入,因为在 Spring 中创建 Bean 分三步:
实例化,createBeanInstance,就是 new 了个对象
属性注入,populateBean, 就是 set 一些属性值
初始化,initializeBean,执行一些 aware 接口中的方法,initMethod,AOP代理等
明确了上面这三点,再结合我上面说的“不完整的”,我们来理一下。
如果全是构造器注入,比如A(B b),那表明在 new 的时候,就需要得到 B,此时需要 new B 。
但是 B 也是要在构造的时候注入 A ,即B(A a),这时候 B 需要在一个 map 中找到不完整的 A ,发现找不到。
为什么找不到?因为 A 还没 new 完呢,所以找到不完整的 A,因此如果全是构造器注入的话,那么 Spring 无法处理循环依赖。
解决流程
经过上面的铺垫,我想你对 Spring 如何解决循环依赖应该已经有点感觉了,接下来我们就来看看它到底是如何实现的。
明确了 Spring 创建 Bean 的三步骤之后,我们再来看看它为单例搞的三个 map:
一级缓存,singletonObjects,存储所有已创建完毕的单例 Bean (完整的 Bean)
二级缓存,earlySingletonObjects,存储所有仅完成实例化,但还未进行属性注入和初始化的 Bean
三级缓存,singletonFactories,存储能建立这个 Bean 的一个工厂,通过工厂能获取这个 Bean,延迟化 Bean 的生成,工厂生成的 Bean 会塞入二级缓存
这三个 map 是如何配合的呢?
首先,获取单例 Bean 的时候会通过 BeanName 先去 singletonObjects(一级缓存) 查找完整的 Bean,如果找到则直接返回,否则进行步骤 2。
看对应的 Bean 是否在创建中,如果不在直接返回找不到,如果是,则会去 earlySingletonObjects (二级缓存)查找 Bean,如果找到则返回,否则进行步骤 3
去 singletonFactories (三级缓存)通过 BeanName 查找到对应的工厂,如果存着工厂则通过工厂创建 Bean ,并且放置到 earlySingletonObjects 中。
如果三个缓存都没找到,则返回 null。
从上面的步骤我们可以得知,如果查询发现 Bean 还未创建,到第二步就直接返回 null,不会继续查二级和三级缓存。
返回 null 之后,说明这个 Bean 还未创建,这个时候会标记这个 Bean 正在创建中,然后再调用 createBean 来创建 Bean,而实际创建是调用方法 doCreateBean。
doCreateBean 这个方法就会执行上面我们说的三步骤:
实例化
属性注入
初始化
以上面的例子来讲解,在实例化A 之后,会往三级缓存 singletonFactories 塞入一个工厂A,而调用这个工厂A的 getObject 方法,就能得到这个 A。
要注意,此时 Spring 是不知道会不会有循环依赖发生的,但是它不管,反正往 singletonFactories 塞这个工厂,这里就是提前暴露。
然后就开始执行属性注入,这个时候 A 发现需要注入 B,所以去 getBean(B),此时又会走一遍上面描述的逻辑,到了 B 的属性注入这一步。
此时 B 调用 getBean(A),这时候一级缓存里面找不到,但是发现 A 正在创建中的,于是去二级缓存找,发现没找到,于是去三级缓存找,然后找到了。
并且通过上面提前在三级缓存里暴露的工厂得到 A,然后将这个工厂从三级缓存里删除,并将 A 加入到二级缓存中。
然后结果就是 B 属性注入成功。
紧接着 B 调用 initializeBean 初始化,最终返回,此时 B 已经被加到了一级缓存里 。
这时候就回到了 A 的属性注入,此时注入了 B,接着执行初始化,最后 A 也会被加到一级缓存里,且从二级缓存中删除 A。
Spring 解决依赖循环就是按照上面所述的逻辑来实现的。
重点就是在对象实例化之后,都会在三级缓存里加入一个工厂,提前对外暴露还未完整的 Bean,这样如果被循环依赖了,对方就可以利用这个工厂得到一个不完整的 Bean,破坏了循环的条件。
二个缓存不行?
上面都说了那么多了,那我们思考下,解决循环依赖需要三级缓存吗?
很明显,如果仅仅只是为了破解循环依赖,二个缓存够了,压根就不必要三级。
你思考一下,在实例化 Bean A 之后,我在二级 map 里面塞入这个 A,然后继续属性注入。
发现 A 依赖 B 所以要创建 Bean B,这时候 B 就能从二级 map 得到 A ,完成 B 的建立之后, A 自然而然能完成。
所以为什么要搞个三级缓存,且里面存的是创建 Bean 的工厂呢?
我们来看下调用工厂的 getObject 到底会做什么,实际会调用下面这个方法:
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) { Object exposedObject = bean; if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) { exposedObject = bp.getEarlyBeanReference(exposedObject, beanName); } } return exposedObject;}
重点就在中间的判断,如果 false,返回就是参数传进来的 bean,没任何变化。
如果是 true 说明有 InstantiationAwareBeanPostProcessors 。
且循环的是 smartInstantiationAware 类型,如有这个 BeanPostProcessor 说明 Bean 需要被 aop 代理。
我们都知道如果有代理的话,那么我们想要直接拿到的是代理对象。
也就是说如果 A 需要被代理,那么 B 依赖的 A 是已经被代理的 A,所以我们不能返回 A 给 B,而是返回代理的 A 给 B。
这个工厂的作用就是判断这个对象是否需要代理,如果否则直接返回,如果是则返回代理对象。
看到这明白的小伙伴肯定会问,那跟三级缓存有什么关系,我可以在要放到二级缓存的时候判断这个 Bean 是否需要代理,如果要直接放代理的对象不就完事儿了。
是的,这个思路看起来没任何问题,问题就出在时机,这跟 Bean 的生命周期有关系。
Spring 原本的设计是,bean 的创建过程分三个阶段:
1 创建实例 createBeanInstance – 创建出 bean 的原始对象
2 填充依赖 populateBean – 利用反射,使用 BeanWrapper 来设置属性值
3 initializeBean – 执行 bean 创建后的处理,包括 AOP 对象的产生
在没有循环依赖的场景下:第 1,2 步都是 bean 的原始对象,第 3 步 initializeBean 时,才会生成 AOP 代理对象。
所以,循环依赖打破了 AOP 代理 bean 生成的时机,需要在 populateBean 之前就生成 AOP 代理 bean。
而且,生成 AOP 代理需要执行 BeanPostProcessor,而 Spring 原本的设计是在第 3 步 initializeBean 时才去调用 BeanPostProcessor 的。
所以 Spring 先在一个三级缓存放置一个工厂,用于代表Bean的引用。只有在上面的第三步时,才会通过这个工厂去创建代理对象,这样生命周期就不会乱套了。
理论上来说,使用二级缓存是可以解决 AOP 代理 bean 的循环依赖的。只是 Spring 没有选择这样去实现。Spring 选择了三级缓存来实现,让 bean 的创建流程更加符合常理,更加清晰明了。
关于“怎么使用Spring三级缓存解决循环依赖问题”这篇文章的内容就介绍到这里,感谢各位的阅读!相信大家对“怎么使用Spring三级缓存解决循环依赖问题”知识都有一定的了解,大家如果还想学习更多知识,欢迎关注编程网行业资讯频道。