跳出源码陷阱，Spring是怎样巧用三级缓存解决循环依赖的？-CSDN博客

本文链接：https://blog.csdn.net/2301_82241647/article/details/138441481

创建 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必须是单例的，如果不是单例的，就会出现我们上面说的无限循环的问题！

「图例」

三、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！