对于Spring为什么要采纳三级缓存架构解决循环依赖这个问题，Spring官网并没有给出阐明，也没有找到设计者的相干设计文档。钻研这个问题其实就是对着代码实现猜想设计用意，所以网上就有了各种猜想，并不完全一致。
钻研这个问题有什么意义吗？集体认为其实也就是学习一下大佬的设计思维从而晋升或者潜在晋升集体能力，除此之外，不会对你应用Spring产生任何影响。
然而据说当初好多面试官会问这个问题，那就和你的切身利益高度相干了，不论是哪一种解释，你终归是须要筹备一套逻辑清晰、可能解释分明说得明确的说法的。
所以咱们也尝试钻研一下这个问题，如果能钻研分明的话，没准能够帮你保命。
Spring为什么要用三级缓存？
Spring通过三级缓存解决循环依赖，其中一级缓存是真正的Spring IoC容器，用来存储最终实现创立的bean，这个是必不可少的（其实不应该叫“缓存”，应该叫IoC容器）。
二级缓存是用来在创立过程中缓存对象的，比方对象A的创立过程中须要依赖对象B，然而对象B尚未创立，所以就必须要首先创建对象B，这个时候对象A还没有实现最终的创立，所以必须找个中央把他缓存起来，因而二级缓存看似也很必要。
那咱们能不能不要二级缓存，创立B的时候先把A间接放入一级缓存，即便A不是最终状态，然而后续的逻辑究竟是会实现A的创立、使A变为最终状态的。
那到底为什么非要这个三级缓存呢？
搞清楚这个问题之前，有必要初步理解一下Spring单例bean的生命周期。
Spring单例Bean的生命周期
Spring单例Bean的生命周期这个话题其实是有点简单的，咱们当初还不想深刻到这个层面，因而咱们临时不会深入研究生命周期中的每一个过程，只是大略晓得Spring的单例Bean创立过程中都包含那些重要节点，每一个节点大略要干啥，就能够了。
插入一点点题外话：Spring之所以这么弱小的一个重要起因就是他的PostProcessors，Spring不仅仅是通过反转管制的形式创立了一个IoC容器帮你治理Bean，更重要的是他能够通过各种PostProcessors实现各种各样的性能，其中最重要的就是AOP。
好的接下来进入正题。
Spring单例Bean的创立过程
也就是Spring源码中doCreateBean的的逻辑。
Spring依照如下程序创立bean实例：
applyBeanPostProcessorsBeforeInstantiation
实例化前的后置处理器。这个时候指标Bean还没有实例化。
实例化前的后置处理器通过CustomTargetSource配置，配置之后Spring将bean实例的创立权交给用户，其实就是Spring不负责bean的创立了。个人感觉应该很少有实用的场景，咱们还是要剖析我的项目中最常见的场景，所以这部分能够疏忽。多说一句，实例化前和实例化后的后置处理器（BeforeInstantiation和AfterInstantiation）是InstantiationAwareBeanPostProcessor接口（BeanPostProcessor的子接口）中定义的，类定义的javaDoc中原本就说是Spring Framework外部应用的，不倡议用户间接应用。
This interface is a special purpose interface, mainly for internal use within the framework. It is recommended to implement the plain {@link BeanPostProcessor} interface as far as possible.
- applyBeanPostProcessorsAfterInitialization
初始化后的BeanPostProcessor解决，指标Bean必须曾经被BeanPostProcessorsBeforeInstantiation创立。如果实例曾经被创立，打标签beforeInstantiationResolved=true。
同上，依赖于第1步的BeforeInstantiation后置处理器，疏忽。 - createBeanInstance
创立Bean实例。 - populateBean
属性填充。 - applyBeanPostProcessorsBeforeInitialization
初始化前的BeanPostProcessors。
对于实现了BeanPostProcessor并注册到以后容器中的所有BeanPostProcessor，调用其办法postProcessBeforeInitialization。和咱们明天的主题关系不大，临时疏忽。 - invokeInitMethods
调用配置的init-method，或者如果bean实现了InitializingBean接口的话则调用afterPropertiesSet办法，执行初始化。 - applyBeanPostProcessorsAfterInitialization
初始化后的BeanPostProcessors。调用所有实现了BeanPostProcessor接口并注册到以后容器的BeanPostProcessor，调用其postProcessAfterInitialization办法。
以上7步，实现bean的创立。
咱们重点阐明一下第7步，调用BeanPostProcessor的postProcessAfterInitialization办法。咱们晓得Spring的很多重要性能都是通过BeanPostProcessor实现的，其中就包含AOP。Spring中有几个不同的BeanPostProcessor实现AOP，包含：
他们都是虚构类AbstractAutoProxyCreator的扩大类，而AbstractAutoProxyCreator的接口继承关系如下：
AbstractAutoProxyCreator - >SmartInstantiationAwareBeanPostProcessor->InstantiationAwareBeanPostProcessor->BeanPostProcessor。
能够看到AbstractAutoProxyCreator实现了的BeanPostProcessor接口，所以他的postProcessAfterInitialization办法最终会被以上的第7步调用到：
@Override public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) { if (bean != null) { Object cacheKey = getCacheKey(bean.getClass(), beanName); if (this.earlyProxyReferences.remove(cacheKey) != bean) { return wrapIfNecessary(bean, beanName, cacheKey); } } return bean; }wrapIfNecessary的作用是，判断以后对象如果须要AOP的话，应用CGLIB创立以后对象的代理对象后返回。
所以咱们能够晓得第7步applyBeanPostProcessorsAfterInitialization的目标：如果以后对象须要AOP的话，创立代理对象以便实现AOP。
单例Bean的get过程
也就是Spring查找bean的过程。其中就包含咱们下面探讨过的7步创立过程。
咱们对Spring getBean的探讨要尽可能精简然而必须要蕴含次要的或者与明天主题相干的逻辑，下面探讨过的7步（doCreateBean的过程）会糅合进来然而曾经申明与明天主题无关的步骤就疏忽掉了，整顿后的getBean的逻辑如下：
- getBean入口，首先查看一级缓存如果存在的话，间接返回。否则查看二级缓存存在的话间接返回，否则，查看三级缓存存在的话，用三级缓存中的bean工厂加工bean（参考第3步的解释，理论是在进行AOP的解决）后放入二级缓存，革除三级缓存，返回bean。
- 第1步没有拿到bean，则将以后beanName放入“正在创立中”列表，开始创立bean。
- createBeanInstance
创立Bean实例，如果以后bean处于“正在创立中”列表，则创立一个bean工厂放入三级缓存。留神这个bean工厂的目标就是要在工厂办法中实现applyBeanPostProcessorsAfterInitialization办法，也就是失常状况下第7步才要执行的动作。 - populateBean
属性填充。进行依赖对象的查找和注入，查找依赖对象的入口仍然是getBean，返回到以后第1步。 - applyBeanPostProcessorsBeforeInitialization
初始化前的BeanPostProcessors。 - invokeInitMethods
调用配置的init-method，执行初始化。 - applyBeanPostProcessorsAfterInitialization
为实现AOP，利用以后原始bean实例创立代理实例。 - 以后bean从“正在创立中”列表移除。
- 实现bean的创立，bean从一、二级缓存移除，放入一级缓存。
通过以上9步工作法实现单例bean的创立，要了然于心。
为什么要用三级缓存解决循环依赖
绕回这个问题上来了。
尽管做了很多铺垫，解释起来还是不会很容易。然而其实铺垫并不仅仅是为了答复这个问题，其实自己对这个问题自身的价值存疑，而后面几篇文章的铺垫内容的价值远远大于答复这个问题的价值了。
咱们尝试答复这个问题，为什么不能去掉二级、或者去掉三级缓存，只用一级或一级、二级缓存解决问题。
Spring用以上9步工作法实现bean的创立，顺利的状况下（没有依赖的bean，或者依赖的bean曾经实现创立了）从第1步开始始终到第9步完结，一口气实现bean的创立。
如果有依赖、尤其是有循环依赖的话，bean的创立过程就不会一口气实现以上9个步骤，比方A依赖B、B依赖C、C依赖D,D依赖A这种场景，bean的创立过程就会是（假如bean的创立程序是A -> B -> C -> D）:创立A对象从第1步走到第4步，发现A依赖B，则创立B对象又是从第一步走到第4步...创立C对象从第1步到第4步，创立D对象从第1步到第9步，而后再一次退回去跑C对象的第5步到第9步...始终退回到A对象的创立，跑完第5到第9步。
在整个Bean的创立过程中，失常状况下AOP的解决是放在第7步，也就是bean创立过程的最初来实现的。
在没有循环依赖的状况下AOP放在最初解决是没有问题的，然而如果有循环依赖，比方A依赖B，B依赖A（假如创立程序是A->B），其实首先实现创立的是B，在B实现创立的时候A的创立过程只走到了第4步，尚未执行AOP解决，这种状况下如果不做非凡解决的话、注入B的A实例原本应该是代理对象、但理论注入的就是原始对象，出问题了。
Spring对这个问题的解决方案就是引入了二级缓存和三级缓存，bean实例创立之后首先创立一个bean工厂放入三级缓存（参考9步工作法中的第3步），如果产生循环依赖的话，在查找依赖对象的时候的第1步中就会在三级缓存中发现这个bean，而后调用工厂办法实现AOP代理对象的解决，之后把解决后的代理对象放入二级缓存。
这样的话Spring就完满解决了循环依赖问题（Sorry，道歉，不应该这么说，应该说通过下面的解释阐明，咱们就能了解Spring循环依赖解决方案的逻辑了...）。
所以其实Spring之所以有三级缓存，就是为了解决循环依赖处理过程中的AOP代理对象的创立问题 - 循环依赖的状况下提前创立（所以叫early...）AOP代理对象。
Spring为什么把AOP代理对象的解决放在最初一步？
如果Spring把失常的（没有循环依赖的）Bean创立过程调整一下，把AOP代理对象的创立放在第一步、实例化的时候同步实现，就不会有“为了解决循环依赖处理过程中AOP代理对象的创立问题，从而引入了三级缓存”这个问题了。最多须要二级缓存用来存储依赖查找过程中尚未实现创立的半成品Bean对象。
这可能又是一个是否有价值的问题，不过Spring官网貌似给出了答案，所以就拿进去阐明一下，不费力气：
The Spring container guarantees that a configured initialization callback is called immediately after a bean is supplied with all dependencies. Thus, the initialization callback is called on the raw bean reference, which means that AOP interceptors and so forth are not yet applied to the bean. A target bean is fully created first and then an AOP proxy (for example) with its interceptor chain is applied. If the target bean and the proxy are defined separately, your code can even interact with the raw target bean, bypassing the proxy. Hence, it would be inconsistent to apply the interceptors to the init method, because doing so would couple the lifecycle of the target bean to its proxy or interceptors and leave strange semantics when your code interacts directly with the raw target bean.
下面这段话是在将Spring讲init办法的章节中、阐明init办法在什么阶段被Spring回调执行。对应咱们下面9步工作法的第6步，AOP代理对象的解决在第7步，所以init办法在AOP代理对象解决之前。
这一大段english读起来比拟吃力，翻译一下：
外面提到一个说法：指标Bean的实例化和AOP代理对象的解决是拆散、解耦的，这种设计能够给使用者（也就是咱们啦）极大地灵活性：比方不触发任何AOP拦截器的状况下间接拜访原始指标Bean的初始化办法！
那循环依赖是不是就毁坏了Spring的这一设计呢？我感觉我的助手对这一问题的答复还是很有程度的：
总结
貌似咱们曾经对“Spring为什么要用三级缓存解决循环依赖”这个问题解释的很分明了。
然而我感觉还有一个问题：能够去掉二级缓存吗？利用三级缓存创立AOP代理对象之后（没有AOP代理的话还是原对象），不放入二级缓存、间接放入一级缓存，能够吗？
道歉，自己尚未找到不能够的强硬理由。然而退出二级缓存之后，整个bean的创立逻辑更加清晰了：一级缓存中存储的是最终实现创立的bean，能够间接拿来应用了，二级缓存中的bean是尚未进行属性填充、初始化前后置处理器、初始化、初始化后后置处理器等一些列解决，只是个半成品。
上一篇 Spring FrameWork从入门到NB -三级缓存解决循环依赖底细 （二）