关于java:Spring-FrameWork从入门到NB-单例Bean生命周期

对于 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 之所以这么弱小的一个重要起因就是他的 PostProcessors，Spring 不仅仅是通过反转管制的形式创立了一个 IoC 容器帮你治理 Bean，更重要的是他能够通过各种 PostProcessors 实现各种各样的性能，其中最重要的就是 AOP。

好的接下来进入正题。

也就是 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。

也就是 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 把失常的（没有循环依赖的）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 - 三级缓存解决循环依赖底细（二）

关于java:Spring-FrameWork从入门到NB-单例Bean生命周期

Spring 为什么要用三级缓存？

Spring 单例 Bean 的生命周期

Spring 单例 Bean 的创立过程

单例 Bean 的 get 过程

为什么要用三级缓存解决循环依赖

Spring 为什么把 AOP 代理对象的解决放在最初一步？

总结