Spring核心之bean生命周期和三級緩存

 

目錄

• 1 Spring核心
  • 1.1 bean生命周期
    • 1.1.1 bean生命周期中重要接口
    • 1.1.2 創建bean
    • 1.1.3 屬性填充
    • 1.1.4 初始化bean
      • 1.1.4.1 Aware相關接口
      • 1.1.4.2 BeanPostProcessors相關接口
      • 1.1.4.3 InitializingBean接口
      • 1.1.4.4 BeanPostProcessors接口后置方法
    • 1.1.5 bean生命周期總結
  • 1.2 三級緩存
    • 1.2.1 引言
    • 1.2.2 三級緩存各個存放對象
    • 1.2.3 解決循環依賴條件
    • 1.2.4 循環依賴
    • 1.2.5 是否可以移除二級緩存

 

1 Spring核心

在使用spring框架的日常開發中，bean之間的循環依賴太頻繁了，spring已經幫我們去解決循環依賴問題，對我們開發者來說是無感知的，下面具體分析一下spring是如何解決bean之間循環依賴，為什么要使用到三級緩存，而不是二級緩存？

1.1 bean生命周期

首先大家需要了解一下bean在spring中的生命周期，bean在spring的加載流程，才能夠更加清晰知道spring是如何解決循環依賴的。

1.1.1 bean生命周期中重要接口

我們在spring的BeanFactory工廠列舉了很多接口，代表着bean的生命周期，我們主要記住的是圈紅線圈出來的接口, 再結合spring的源碼來看這些接口主要是在哪里調用的

1.1.2 創建bean

AbstractAutowireCapableBeanFactory類的doCreateBean方法是創建bean的開始，我們可以看到首先需要實例化這個bean，也就是在堆中開辟一塊內存空間給這個對象，createBeanInstance方法里面邏輯大概就是采用反射生成實例對象，進行到這里表示對象還並未進行屬性的填充，也就是@Autowired注解的屬性還未得到注入

1.1.3 屬性填充

我們可以看到第二步就是填充bean的成員屬性，populateBean方法里面的邏輯大致就是對使用到了注入屬性的注解就會進行注入，如果在注入的過程發現注入的對象還沒生成，則會跑去生產要注入的對象，第三步就是調用initializeBean方法初始化bean，也就是調用我們上述所提到的接口

1.1.4 初始化bean

可以看到initializeBean方法中，首先調用的是使用的Aware接口的方法，我們具體看一下invokeAwareMethods方法中會調用Aware接口的那些方法

1.1.4.1 Aware相關接口

我們可以知道如果我們實現了BeanNameAware，BeanClassLoaderAware，BeanFactoryAware三個Aware接口的話，會依次調用setBeanName(), setBeanClassLoader(), setBeanFactory()方法，再看applyBeanPostProcessorsBeforeInitialization源碼

1.1.4.2 BeanPostProcessors相關接口

發現會如果有類實現了BeanPostProcessor接口，就會執行postProcessBeforeInitialization方法，這里需要注意的是：如果多個類實現BeanPostProcessor接口，那么多個實現類都會執行postProcessBeforeInitialization方法，可以看到是for循環依次執行的，還有一個注意的點就是如果加載A類到spring容器中，A類也重寫了BeanPostProcessor接口的postProcessBeforeInitialization方法，這時要注意A類的postProcessBeforeInitialization方法並不會得到執行，因為A類還未加載完成，還未完全放到spring的singletonObjects一級緩存中。

再看一個注意的點

可以看到ApplicationContextAwareProcessor也實現了BeanPostProcessor接口，重寫了postProcessBeforeInitialization方法，方法里面並調用了invokeAwareInterfaces方法，而invokeAwareInterfaces方法也寫着如果實現了眾多的Aware接口，則會依次執行相應的方法，值得注意的是ApplicationContextAware接口的setApplicationContext方法，再看一下invokeInitMethods源碼

1.1.4.3 InitializingBean接口

發現如果實現了InitializingBean接口，重寫了afterPropertiesSet方法，則會調用afterPropertiesSet方法，最后還會調用是否指定了init-method，可以通過標簽，或者@Bean注解的initMethod指定，最后再看一張applyBeanPostProcessorsAfterInitialization源碼圖

1.1.4.4 BeanPostProcessors接口后置方法

發現跟之前的postProcessBeforeInitialization方法類似，也是循環遍歷實現了BeanPostProcessor的接口實現類，執行postProcessAfterInitialization方法。整個bean的生命執行流程就如上面截圖所示，哪個接口的方法在哪里被調用，方法的執行流程。

1.1.5 bean生命周期總結

最后，對bean的生命流程進行一個流程圖的總結

或者看簡單版本：

1.2 三級緩存

1.2.1 引言

上面對bean的生命周期做了一個整體的流程分析，對spring如何去解決循環依賴的很有幫助。前面我們分析到填充屬性時，如果發現屬性還未在spring中生成，則會跑去生成屬性對象實例。

我們可以看到填充屬性的時候，spring會提前將已經實例化的bean通過ObjectFactory半成品暴露出去，為什么稱為半成品是因為這時候的bean對象實例化，但是未進行屬性填充，是一個不完整的bean實例對象
在實例化 Bean 之后，會往 singletonFactories 塞入一個工廠，而調用這個工廠的 getObject 方法，就能得到這個 Bean

spring利用singletonObjects, earlySingletonObjects, singletonFactories三級緩存去解決的，所說的緩存其實也就是三個Map

1.2.2 三級緩存各個存放對象

三級緩存各個存放對象：

• 一級緩存，singletonObjects，存儲所有已創建完畢的單例 Bean （完整的 Bean）
• 二級緩存，earlySingletonObjects，存儲所有僅完成實例化，但還未進行屬性注入和初始化的 Bean
• 三級緩存，singletonFactories，存儲能建立這個 Bean 的一個工廠，通過工廠能獲取這個 Bean，延遲化 Bean 的生成，工廠生成的 Bean 會塞入二級緩存

這三個 map 是如何獲取配合的：

1. 獲取單例 Bean 的時候會通過 BeanName 先去 singletonObjects（一級緩存） 查找完整的 Bean，如果找到則直接返回，否則進行步驟 2。
2. 看對應的 Bean 是否在創建中，如果不在直接返回找不到，如果是，則會去 earlySingletonObjects （二級緩存）查找 Bean，如果找到則返回，否則進行步驟 3
3. 去 singletonFactories （三級緩存）通過BeanName 查找到對應的工廠，如果存着工廠則通過工廠創建 Bean ，並且放置到 earlySingletonObjects 中。
4. 如果三個緩存都沒找到，則返回 null
   

可以看到三級緩存各自保存的對象，這里重點關注二級緩存earlySingletonObjects和三級緩存singletonFactory，一級緩存可以進行忽略。前面我們講過先實例化的bean會通過ObjectFactory半成品提前暴露在三級緩存中

singletonFactory是傳入的一個匿名內部類，調用ObjectFactory.getObject()最終會調用getEarlyBeanReference方法。再來看看循環依賴中是怎么拿其它半成品的實例對象的。

1.2.3 解決循環依賴條件

在 Spring 中，只有同時滿足以下兩點才能解決循環依賴的問題：

• 必須是單例
  依賴的 Bean 必須都是單例
  因為原型模式都需要創建新的對象，不能跟用以前的對象
• 不能全是構造器注入
  依賴注入的方式，必須不全是構造器注入，且 beanName 的字母順序在前的不能是構造器注入
  在 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 無法處理循環依賴
• 一個set注入，一個構造器注入能否成功
  假設我們 A 是通過 set 注入 B，B 通過構造函數注入 A，此時是成功的
  我們來分析下：實例化 A 之后，可以在 map 中存入 A，開始為 A 進行屬性注入，發現需要 B，此時 new B，發現構造器需要 A，此時從 map 中得到 A ，B 構造完畢。
  B 進行屬性注入，初始化，然后 A 注入 B 完成屬性注入，然后初始化 A。
  整個過程很順利，沒毛病
  假設 A 是通過構造器注入 B，B 通過 set 注入 A，此時是失敗的
  我們來分析下：實例化 A，發現構造函數需要 B， 此時去實例化 B。
  然后進行 B 的屬性注入，從 map 里面找不到 A，因為 A 還沒 new 成功，所以 B 也卡住了，然后就 失敗
  看到這里，仔細思考的小伙伴可能會說，可以先實例化 B 啊，往 map 里面塞入不完整的 B，這樣就能成功實例化 A 了啊
  確實，思路沒錯但是 Spring 容器是按照字母序創建 Bean 的，A 的創建永遠排在 B 前面

現在我們總結一下：

• 如果循環依賴都是構造器注入，則失敗
• 如果循環依賴不完全是構造器注入，則可能成功，可能失敗，具體跟BeanName的字母序有關系

1.2.4 循環依賴

我們假設現在有這樣的場景AService依賴BService，BService依賴AService

1. AService首先實例化，實例化通過ObjectFactory半成品暴露在三級緩存中
2. 填充屬性BService，發現BService還未進行過加載，就會先去加載BService
3. 再加載BService的過程中，實例化，也通過ObjectFactory半成品暴露在三級緩存
4. 填充屬性AService的時候，這時候能夠從三級緩存中拿到半成品的ObjectFactory

拿到ObjectFactory對象后，調用ObjectFactory.getObject()方法最終會調用getEarlyBeanReference()方法，getEarlyBeanReference這個方法主要邏輯大概描述下如果bean被AOP切面代理則返回的是beanProxy對象，如果未被代理則返回的是原bean實例。

這時我們會發現能夠拿到bean實例(屬性未填充)，然后從三級緩存移除，放到二級緩存earlySingletonObjects中，而此時B注入的是一個半成品的實例A對象，不過隨着B初始化完成后，A會繼續進行后續的初始化操作，最終B會注入的是一個完整的A實例，因為在內存中它們是同一個對象。

1.2.5 是否可以移除二級緩存

我們發現這個二級緩存好像顯得有點多余，好像可以去掉，只需要一級和三級緩存也可以做到解決循環依賴的問題

只要兩個緩存確實可以做到解決循環依賴的問題，但是有一個前提這個bean沒被AOP進行切面代理，如果這個bean被AOP進行了切面代理，那么只使用兩個緩存是無法解決問題，下面來看一下bean被AOP進行了切面代理的場景

我們發現AService的testAopProxy被AOP代理了，看看傳入的匿名內部類的getEarlyBeanReference返回的是什么對象。

發現singletonFactory.getObject()返回的是一個AService的代理對象，還是被CGLIB代理的。再看一張再執行一遍singletonFactory.getObject()返回的是否是同一個AService的代理對象

我們會發現再執行一遍singleFactory.getObject()方法又是一個新的代理對象，這就會有問題了，因為AService是單例的，每次執行singleFactory.getObject()方法又會產生新的代理對象。

假設這里只有一級和三級緩存的話，每次從三級緩存中拿到singleFactory對象，執行getObject()方法又會產生新的代理對象，這是不行的，因為AService是單例的，所有這里我們要借助二級緩存來解決這個問題，將執行了singleFactory.getObject()產生的對象放到二級緩存中去，后面去二級緩存中拿，沒必要再執行一遍singletonFactory.getObject()方法再產生一個新的代理對象，保證始終只有一個代理對象。還有一個注意的點

既然singleFactory.getObject()返回的是代理對象，那么注入的也應該是代理對象，我們可以看到注入的確實是經過CGLIB代理的AService對象。所以如果沒有AOP的話確實可以兩級緩存就可以解決循環依賴的問題，如果加上AOP，兩級緩存是無法解決的，不可能每次執行singleFactory.getObject()方法都給我產生一個新的代理對象，所以還要借助另外一個緩存來保存產生的代理對象

轉載於：
https://mp.weixin.qq.com/s/iCaBsXInpbNc8tiV-qRM4g
https://mp.weixin.qq.com/s/JVhRgiEcaNf6KLQehQwx1Q