三級緩存---解決 Spring 循環依賴

1. 循環依賴

1.1 什么是循環依賴

首先，什么是循環依賴？這個其實好理解，就是兩個 Bean 互相依賴，類似下面這樣：

"""

@Service
public class AService {
	@Autowired
	BService bService;
}
@Service
public class BService {
	@Autowired
	AService aService;
}

"""

AService 和 BService 互相依賴：

1.2 循環依賴的類型

一般來說，循環依賴有三種不同的形態，上面就是其中一種。

另外兩種分別是三者依賴，如下圖：

這種循環依賴一般隱藏比較深，不易發覺。

還有自我依賴，如下圖：

一般來說，如果我們的代碼中出現了循環依賴，則說明我們的代碼在設計的過程中可能存在問題，我們應該盡量避免循環依賴的發生。不過一旦發生了循環依賴，Spring 默認也幫我們處理好了，當然這并不能說明循環依賴這種代碼就沒問題。實際上在目前最新版的 Spring 中，循環依賴是要額外開啟的，如果不額外配置，發生了循環依賴就直接報錯了。

2. 循環依賴解決思路

2.1 解決思路

那么對于循環依賴該如何解決呢？其實很簡單，中加加入一個緩存就可以了，小伙伴們來看下面這張圖：

我們在這里引入了一個緩存池。

當我們需要創建 AService 的實例的時候，會首先通過 Java 反射創建出來一個原始的 AService，這個原始 AService 可以簡單理解為剛剛 new 出來（實際是剛剛通過反射創建出來）還沒設置任何屬性的 AService，此時，我們把這個 AService 先存入到一個緩存池中。

接下來我們就需要給 AService 的屬性設置值了，同時還要處理 AService 的依賴，這時我們發現 AService 依賴 BService，那么就去創建 BService 對象，結果創建 BService 的時候，發現 BService 依賴 AService，那么此時就先從緩存池中取出來 AService 先用著，然后繼續 BService 創建的后續流程，直到 BService 創建完成后，將之賦值給 AService，此時 AService 和 BService 就都創建完成了。

BService 從緩存池中拿到的 AService 是一個半成品，并不是真正的最終的 AService，但是我們要知道，咱們 Java 是引用傳遞（也可以認為是值傳遞，只不過這個值是內存地址），BService 當時拿到的是 AService 的引用，說白了就是一塊內存地址而已，根據這個地址找到的就是 AService，所以，后續如果 AService 創建完成后，BService 所拿到的 AService 就是完整的 AService 了。

上面提到的這個緩存池，在 Spring 容器中有一個專門的名字，就叫做 earlySingletonObjects，這是 Spring 三級緩存中的二級緩存，這里保存的是剛剛通過反射創建出來的 Bean，這些 Bean 還沒有經歷過完整生命周期，Bean 的屬性可能都還沒有設置，Bean 需要的依賴都還沒有注入進來。另外兩級緩存分別是：

singletonObjects：這是一級緩存，一級緩存中保存的是所有經歷了完整生命周期的 Bean，即一個 Bean 從創建、到屬性賦值、到各種處理器的執行等等，都經歷過了，就存到 singletonObjects 中，當我們需要獲取一個 Bean 的時候，首先會去一級緩存中查找，當一級緩存中沒有的時候，才會考慮去二級緩存。

singletonFactories：這是三級緩存。在一級緩存和二級緩存中，緩存的 key 是 beanName，緩存的 value 則是一個 Bean 對象，但是在三級緩存中，緩存的 value 是一個 Lambda 表達式，通過這個 Lambda 表達式可以創建出來目標對象的一個代理對象。

可能有的人會覺得奇怪，按照上文的介紹，一級緩存和二級緩存就足以解決循環依賴了，為什么還冒出來一個三級緩存？那就得考慮 AOP 的情況了！

2.2 存在 AOP 怎么辦

上面給大家介紹的是普通的 Bean 創建，那確實沒有問題。但是 Spring 中還有一個非常重要的能力，那就是 AOP。

AOP 在 Spring中的創建流程

正常來說是我們首先通過反射獲取到一個 Bean 的實例，然后就是給這個 Bean 填充屬性，屬性填充完畢之后，接下來就是執行各種 BeanPostProcessor 了，如果這個 Bean 中有需要代理的方法，那么系統就會自動配置對應的后置處理器，松哥舉一個簡單例子，假設我有如下一個 Service：

"""

@Service
public class UserService {

	@Async
	public void hello() {
		System.out.println("hello>>>"+Thread.currentThread().getName());
	}
}

"""

那么系統就會自動提供一個名為 AsyncAnnotationBeanPostProcessor 的處理器，在這個處理器中，系統會生成一個代理的 UserService 對象，并用這個對象代替原本的 UserService。

要搞清楚的是，原本的 UserService 和新生成的代理的 UserService 是兩個不同的對象，占兩塊不同的內存地址！

請看下面這張圖：

如果 AService 最終是要生成一個代理對象的話，那么 AService 存到緩存池的其實還是原本的 AService，因為此時還沒到處理 AOP 那一步（要先給各個屬性賦值，然后才是 AOP 處理），這就導致 BService 從緩存池里拿到的 AService 是原本的 AService，等到 BService 創建完畢之后，AService 的屬性賦值才完成，接下來在 AService 后續的創建流程中，AService 會變成了一個代理對象了，不是緩存池里的 AService 了，最終就導致 BService 所依賴的 AService 和最終創建出來的 AService 不是同一個。

為了解決這個問題，Spring 引入了三級緩存 singletonFactories。

singletonFactories 的工作機制是這樣的（假設 AService 最終是一個代理對象）：

當我們創建一個 AService 的時候，通過反射剛把原始的 AService 創建出來之后，先去判斷當前一級緩存中是否存在當前 Bean，如果不存在，則：

首先向三級緩存中添加一條記錄，記錄的 key 就是當前 Bean 的 beanName，value 則是一個 Lambda 表達式 ObjectFactory，通過執行這個 Lambda 可以給當前 AService 生成代理對象。
然后如果二級緩存中存在當前 AService Bean，則移除掉。

現在繼續去給 AService 各個屬性賦值，結果發現 AService 需要 BService，然后就去創建 BService，創建 BService 的時候，發現 BService 又需要用到 AService，于是就先去一級緩存中查找是否有 AService，如果有，就使用，如果沒有，則去二級緩存中查找是否有 AService，如果有，就使用，如果沒有，則去三級緩存中找出來那個 ObjectFactory，然后執行這里的 getObject 方法，這個方法在執行的過程中，會去判斷是否需要生成一個代理對象，如果需要就生成代理對象返回，如果不需要生成代理對象，則將原始對象返回即可。最后，把拿到手的對象存入到二級緩存中以備下次使用，同時刪除掉三級緩存中對應的數據。這樣 AService 所依賴的 BService 就創建好了。

接下來繼續去完善 AService，去執行各種后置的處理器，此時，有的后置處理器想給 AService 生成代理對象，發現 AService 已經是代理對象了，就不用生成了，直接用已有的代理對象去代替 AService 即可。

在這里，AService 和 BService 都搞定。

本質上，singletonFactories 是把 AOP 的過程提前了。

3. 小結

綜上所述，Spring 解決循環依賴把握住兩個關鍵點：

提前暴露： 剛剛創建好的對象還沒有進行任何賦值的時候，將之暴露出來放到緩存中，供其他 Bean 提前引用（二級緩存）。

提前 AOP： A 依賴 B 的時候，去檢查是否發生了循環依賴（檢查的方式就是將正在創建的 A 標記出來，然后 B 需要 A，B 去創建 A 的時候，發現 A 正在創建，就說明發生了循環依賴），如果發生了循環依賴，就提前進行 AOP 處理，處理完成后再使用（三級緩存）。

原本 AOP 這個過程是屬性賦完值之后，再由各種后置處理器去處理 AOP 的（AbstractAutoProxyCreator），但是如果發生了循環依賴，就先 AOP，然后屬性賦值，最后等到后置處理器執行的時候，就不再做 AOP 的處理了。

不過需要注意，三級緩存并不能解決所有的循環依賴

posted @ 2023-07-17 19:56 二價亞鐵閱讀(2220) 評論(1) 收藏舉報

刷新頁面返回頂部

二價亞鐵.