Spring 動態代理時是如何解決循環依賴的？為什麼要使用三級緩存？
前言
在研究 『 Spring 是如何解決循環依賴的 』 的時候，了解到 Spring 是藉助三級緩存來解決循環依賴的。
同樣在上一節留下了疑問：
- 循環依賴為什麼要使用三級緩存？而不是使用二級緩存？
- AOP 動態代理對循環依賴的有沒有什麼影響？
本篇文章也是圍繞上面的內容進行展開。
筆記也在不斷整理，之前可能會有點雜亂。
循序漸進，看一看什麼是循環依賴？
開始先簡單回顧一下 Bean 的創建過程，當然小夥伴也可以直接閱讀『 單例 Bean 的創建 』這篇文章。
不過考慮到閱讀本文前再閱讀上一篇文章、Debug 等等，會比較耗時，所以本篇文章前面一小部分會先對之前的文章內容做簡要概括，也相當於對我自己學習的知識進行一個總結。
先來回顧一下三級緩存的概念。
singletonObjects： 一級緩存，存儲單例對象，Bean 已經實例化，初始化完成。
earlySingletonObjects： 二級緩存，存儲 singletonObject，這個 Bean 實例化了，還沒有初始化。
singletonFactories： 三級緩存，存儲 singletonFactory。
Bean 的創建過程
@Service
public class CircularServiceA {
private String fieldA = "字段 A";
}
通過上面的流程，可以看出 Spring 在創建 Bean 的過程中重點是在 AbstractAutowireCapableBeanFactory 中的以下三個步驟：
- 實例化 createBeanInstance： 其中實例化 Bean 並對 Bean 進行賦值，像例子中的
fieldA字段在這裡就會賦值。 - 屬性注入 populateBean： 可以理解為對 Bean 裏面的屬性進行賦值。(會依賴其他 Bean)
- 初始化 initializeBean： 執行初始化和 Bean 的後置處理器。
實例化賦值源碼可以閱讀：
BeanUtils.instantiateClass(constructorToUse)
如果要依賴其他 Bean 呢？
那如果 CircularServiceA 依賴了其他 Bean 呢？
@Service
public class CircularServiceA {
private String fieldA = "字段 A";
@Autowired
private CircularServiceB circularServiceB;
}
@Service
public class CircularServiceB {
}
當 A 依賴了 B 的時候，在 createBeanInstance 這一步，並不會對 B 進行屬性賦值。
而是在 populatedBean 這裡查找依賴項，並創建 B。
循環依賴下的創建過程
循環依賴的場景，在上一篇文章已經有所講解，這裡僅僅畫圖說明一下。
@Service
public class CircularServiceA {
private String fieldA = "字段 A";
@Autowired
private CircularServiceB circularServiceB;
}
@Service
public class CircularServiceB {
@Autowired
private CircularServiceA circularServiceA;
}
在 A 和 B 循環依賴的場景中：
B populatedBean 查找依賴項 A 的時候，從一級緩存中雖然未獲取到 A，但是發現 A 在創建中。
此時，從三級緩存中獲取 A 的 singletonFactory 調用工廠方法，創建 getEarlyBeanReference A 的早期引用並返回。
B 引用到 A ，B 就可以初始化完畢，然後 A 同樣也可以初始化完畢了。
二級緩存能否解決循環依賴
通過上面的圖，仔細分析一下，其實把二級緩存拿掉，在 B 嘗試獲取 A 的時候直接返回 A 的實例，是不是也是可以的？
答案是：可以的！
但是為什麼還是用三級緩存呢？
網上的很多資料說是和動態代理有關係，那就從動態代理的方面繼續往下分析分析。
動態代理的場景
在 JavaConfig（配置類） 上添加 @EnableAspectJAutoProxy 註解，開啟 AOP ，通過 Debug 循序漸進看一看動態代理對循環依賴的影響。
動態代理下，Bean 的創建過程
@Service
public class CircularServiceA {
private String fieldA = "字段 A";
public void methodA() {
System.out.println("方法 A 執行");
}
}
@Aspect
@Component
public class AspectA {
@Before("execution(public void com.liuzhihang.circular.CircularServiceA.methodA())")
public void beforeA() {
System.out.println("beforeA 執行");
}
}
只有 A 的情況下，給 A 添加切面，開始 Debug。
前面的流程都相同，在 initializeBean 開始出現差異。
這一步需要初始化 Bean 並執行 Bean 的後置處理器。
其中有一個處理器為： AnnotationAwareAspectJAutoProxyCreator 其實就是加的註解切面，會跳轉到 AbstractAutoProxyCreator 類的 postProcessAfterInitialization 方法
如圖所示：wrapIfNecessary 方法會判斷是否滿足代理條件，是的話返回一個代理對象，否則返回當前 Bean。
後續調用 getProxy 、createAopProxy 等等，最終執行到下面一部分。
最終會執行到這裡，AOP 代理相關的就不細看了。
一路放行，直到 initializeBean 執行結束。
此時發現：A 被替換為了代理對象。
所以 doCreateBean 返回，以及後面放到一級緩存中的都是代理對象。
有循環依賴的動態代理
這一次把循環依賴打開：
@Service
public class CircularServiceA {
private String fieldA = "字段 A";
@Autowired
private CircularServiceB circularServiceB;
public void methodA() {
System.out.println("方法 A 執行");
}
}
@Aspect
@Component
public class AspectA {
@Before("execution(public void com.liuzhihang.circular.CircularServiceA.methodA())")
public void beforeA() {
System.out.println("beforeA 執行");
}
}
@Service
public class CircularServiceB {
@Autowired
private CircularServiceA circularServiceA;
public void methodB() {
}
}
@Aspect
@Component
public class AspectB {
@Before("execution(public void com.liuzhihang.circular.CircularServiceB.methodB())")
public void beforeB() {
System.out.println("beforeB 執行");
}
}
開始 Debug，前面的一些列流程，都和正常的沒有什麼區別。而唯一的區別在於，創建 B 的時候，需要從三級緩存獲取 A。
此時在 getSingleton 方法中會調用：singletonObject = singletonFactory.getObject();
有時會比較疑惑 singletonFactory.getObject() 調用的是哪裡？
所以這一塊調用的是 getEarlyBeanReference，開始遍歷執行 BeanPostProcessor。
看到 wrapIfNecessary 就明白了吧！這塊會獲取一個代理對象。
也就是說此時返回，並放到二級緩存的是一個 A 的代理對象。
這樣 B 就創建完畢了！
到 A 開始初始化並執行後置處理器了！因為 A 也有代理，所以 A 也會執行到 postProcessAfterInitialization 這一部分！
但是在執行 wrapIfNecessary 之前，會先判斷代理對象緩存是否有 A 了。
this.earlyProxyReferences.remove(cacheKey) != bean
但是這塊獲取到的是 A 的代理對象。肯定是 false 。 所以不會再生成一次 A 的代理對象。
總結
可以看到，循環依賴下，有沒有代理情況下的區別就在：
singletonObject = singletonFactory.getObject();
在循環依賴發生的情況下 B 中的 A 賦值時：
- 無代理：getObject 直接返回原來的 Bean
- 有代理：getObject 返回的是代理對象
然後都放到二級緩存。
為什麼要三級緩存?
- 假設去掉三級緩存
去掉三級緩存之後，Bean 直接創建 earlySingletonObjects， 看着好像也可以。
如果有代理的時候，在 earlySingletonObjects 直接放代理對象就行了。
但是會導致一個問題：在實例化階段就得執行後置處理器，判斷有 AnnotationAwareAspectJAutoProxyCreator 並創建代理對象。
這麼一想，是不是會對 Bean 的生命周期有影響。
同樣，先創建 singletonFactory 的好處就是：在真正需要實例化的時候，再使用 singletonFactory.getObject() 獲取 Bean 或者 Bean 的代理。相當於是延遲實例化。
- 假設去掉二級緩存
如果去掉了二級緩存，則需要直接在 singletonFactory.getObject() 階段初始化完畢，並放到一級緩存中。
那有這麼一種場景，B 和 C 都依賴了 A。
要知道在有代理的情況下 singletonFactory.getObject() 獲取的是代理對象。
而多次調用 singletonFactory.getObject() 返回的代理對象是不同的，就會導致 B 和 C 依賴了不同的 A。
那如果獲取 B 到之後直接放到一級緩存，然後 C 再獲取呢？
😳 ……
一級緩存放的是已經初始化完畢的 Bean，要知道 A 依賴了 B 和 C ，A 這時候還沒有初始化完畢。
小結
循環依賴的場景有很多，本文只是通過 Debug ，來了解到循環依賴和 AOP 之間的關係，以及了解到為什麼要用三級緩存。
當然，Spring 設計之初是什麼樣子的？如何一步一步發展成現在這種的？
肯定是不能慢慢去研究了，所以只能以現在的版本，去揣測作者的意圖。
不足之處，多多指正。
