Spring 動態代理時是如何解決迴圈依賴的？為什麼要使用三級快取？
阿新 • • 發佈：2021-01-31
### 前言
在研究 [『 Spring 是如何解決迴圈依賴的 』](https://mp.weixin.qq.com/s/UlUQ95gVt8I8wmVOEjn1aw) 的時候，瞭解到 Spring 是藉助*三級快取*來解決迴圈依賴的。
同樣在上一節留下了疑問：
1. 迴圈依賴為什麼要使用三級快取？而不是使用二級快取？
2. AOP 動態代理對迴圈依賴的有沒有什麼影響？
本篇文章也是圍繞上面的內容進行展開。
> 筆記也在不斷整理，之前可能會有點雜亂。
### 循序漸進，看一看什麼是迴圈依賴？
開始先簡單回顧一下 Bean 的建立過程，當然小夥伴也可以直接閱讀[『 單例 Bean 的建立 』](https://mp.weixin.qq.com/s/qZ4xXlqpNzsdHkvFm02Yuw)這篇文章。
不過考慮到閱讀本文前再閱讀上一篇文章、Debug 等等，會比較耗時，所以本篇文章前面一小部分會先對之前的文章內容做簡要概括，也相當於對我自己學習的知識進行一個總結。
先來回顧一下三級快取的概念。
>**singletonObjects：** 一級快取，儲存單例物件，Bean 已經例項化，初始化完成。
>
>**earlySingletonObjects：** 二級快取，儲存 singletonObject，這個 Bean 例項化了，還沒有初始化。
>
>**singletonFactories：** 三級快取，儲存 singletonFactory。
#### Bean 的建立過程
```java
@Service
public class CircularServiceA {
private String fieldA = "欄位 A";
}
```
通過上面的流程，可以看出 Spring 在建立 Bean 的過程中重點是在 AbstractAutowireCapableBeanFactory 中的以下三個步驟：
1. **例項化 createBeanInstance：** 其中例項化 Bean 並對 Bean 進行賦值，像例子中的 `fieldA` 欄位在這裡就會賦值。
2. **屬性注入 populateBean：** 可以理解為對 Bean 裡面的屬性進行賦值。(會依賴其他 Bean)
3. **初始化 initializeBean：** 執行初始化和 Bean 的後置處理器。
>例項化賦值原始碼可以閱讀：
>
>BeanUtils.instantiateClass(constructorToUse)
#### 如果要依賴其他 Bean 呢？
那如果 CircularServiceA 依賴了其他 Bean 呢？
```java
@Service
public class CircularServiceA {
private String fieldA = "欄位 A";
@Autowired
private CircularServiceB circularServiceB;
}
@Service
public class CircularServiceB {
}
```
當 A 依賴了 B 的時候，在 `createBeanInstance` 這一步，並不會對 B 進行屬性賦值。
而是在 `populatedBean` 這裡查詢依賴項，並建立 B。
#### 迴圈依賴下的建立過程
迴圈依賴的場景，在上一篇文章已經有所講解，這裡僅僅畫圖說明一下。
```java
@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 的建立過程
```java
@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 返回，以及後面放到一級快取中的都是代理物件。
#### 有迴圈依賴的動態代理
這一次把迴圈依賴開啟：
```java
@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 賦值時：
1. 無代理：getObject 直接返回原來的 Bean
2. 有代理：getObject 返回的是代理物件
然後都放到**二級快取**。
#### 為什麼要三級快取?
1. 假設去掉三級快取
去掉三級快取之後，Bean 直接建立 `earlySingletonObjects`， 看著好像也可以。
如果有代理的時候，在 `earlySingletonObjects` 直接放代理物件就行了。
但是會導致一個問題：**在例項化階段就得執行後置處理器，判斷有 AnnotationAwareAspectJAutoProxyCreator 並建立代理物件**。
這麼一想，是不是會對 Bean 的生命週期有影響。
同樣，先建立 `singletonFactory` 的好處就是：**在真正需要例項化的時候，再使用 singletonFactory.getObject() 獲取 Bean 或者 Bean 的代理**。相當於是延遲例項化。
2. 假設去掉二級快取
如果去掉了二級快取，則需要直接在 `singletonFactory.getObject()` 階段初始化完畢，並放到一級快取中。
那有這麼一種場景，B 和 C 都依賴了 A。
要知道在有代理的情況下 `singletonFactory.getObject()` 獲取的是代理物件。
而多次呼叫 `singletonFactory.getObject()` 返回的代理物件是不同的，就會導致 B 和 C 依賴了不同的 A。
那如果獲取 B 到之後直接放到一級快取，然後 C 再獲取呢？