1. 從一次詭異的Bean創(chuàng)建異常說起那天下午我正在調(diào)試一個(gè)看起來平平無奇的Spring Boot服務(wù)。服務(wù)啟動(dòng)時(shí)控制臺(tái)突然拋出了一個(gè)異常不是常見的BeanCreationException而是一個(gè)更底層的、關(guān)于BeanCurrentlyInCreationException的錯(cuò)誤錯(cuò)誤信息里反復(fù)提到了“循環(huán)依賴”和“正在創(chuàng)建中”。這讓我有點(diǎn)意外因?yàn)轫?xiàng)目結(jié)構(gòu)并不復(fù)雜理論上不應(yīng)該出現(xiàn)這么明顯的循環(huán)依賴問題。我檢查了Bean的定義發(fā)現(xiàn)是兩個(gè)Service之間互相Autowired了對(duì)方這確實(shí)是教科書式的循環(huán)依賴場景。但奇怪的是這個(gè)項(xiàng)目之前一直運(yùn)行得好好的直到我引入了一個(gè)Async注解在其中一個(gè)Service的方法上問題才暴露出來。這個(gè)經(jīng)歷讓我重新審視Spring處理循環(huán)依賴的機(jī)制。我們都知道Spring通過“三級(jí)緩存”解決了單例Bean的循環(huán)依賴問題這幾乎是面試八股文的必考題。但當(dāng)你真的在復(fù)雜場景下比如結(jié)合了AOP、Async、Transactional遇到問題時(shí)僅僅背出“一級(jí)緩存放成品Bean二級(jí)緩存放早期暴露對(duì)象三級(jí)緩存放ObjectFactory”是遠(yuǎn)遠(yuǎn)不夠的。你需要真正理解每一級(jí)緩存存在的必要性、它們協(xié)同工作的時(shí)序以及這個(gè)精巧設(shè)計(jì)背后的權(quán)衡與邊界。這次我們就拋開那些籠統(tǒng)的概念直接深入到DefaultSingletonBeanRegistry的源碼里看看這三級(jí)緩存到底是如何在Bean的生命周期中“輾轉(zhuǎn)騰挪”化險(xiǎn)為夷的。2. 三級(jí)緩存的廬山真面目源碼中的三個(gè)Map要理解三級(jí)緩存首先得找到它們藏在哪。在Spring IoC容器的核心——DefaultSingletonBeanRegistry類中定義了三個(gè)至關(guān)重要的Map這就是我們常說的三級(jí)緩存。它們不是任何配置而是Spring框架為解決單例Bean循環(huán)依賴而設(shè)計(jì)的內(nèi)部數(shù)據(jù)結(jié)構(gòu)。2.1 一級(jí)緩存singletonObjects– 成品的歸宿/** Cache of singleton objects: bean name to bean instance. */ private final MapString, Object singletonObjects new ConcurrentHashMap(256);這是大家最熟悉的一級(jí)緩存也叫“單例池”。它的角色非常明確存放已經(jīng)完全初始化好的、可供直接使用的成品Bean。當(dāng)一個(gè)Bean走完了完整的生命周期實(shí)例化、屬性填充、初始化它就會(huì)被放入這個(gè)singletonObjects中。之后任何地方通過getBean()方法請(qǐng)求這個(gè)Bean時(shí)容器會(huì)首先來這里查找。如果找到了直接返回這是性能最高、最直接的路徑。你可以把它想象成一個(gè)餐廳的“出菜口”做好的菜都放在這里服務(wù)員直接從這里端給客人。2.2 二級(jí)緩存earlySingletonObjects– 半成品的臨時(shí)驛站/** Cache of early singleton objects: bean name to bean instance. */ private final MapString, Object earlySingletonObjects new ConcurrentHashMap(16);二級(jí)緩存的存在是解決循環(huán)依賴的關(guān)鍵一環(huán)。它存放的是**“早期暴露”的Bean引用**。什么是早期暴露在Bean的生命周期中通常是在“實(shí)例化”調(diào)用構(gòu)造方法創(chuàng)建出對(duì)象之后但在“屬性填充”和“初始化”之前Spring會(huì)嘗試將這個(gè)剛創(chuàng)建出來、還是個(gè)“空殼”的對(duì)象提前暴露出去。這個(gè)對(duì)象可能還沒有注入依賴也沒有執(zhí)行PostConstruct方法但它已經(jīng)是一個(gè)Java對(duì)象了。二級(jí)緩存就是這個(gè)提前暴露的對(duì)象的臨時(shí)存放點(diǎn)。它的生命周期很短主要服務(wù)于解決循環(huán)依賴的場景。一旦Bean完全初始化完畢它會(huì)被從earlySingletonObjects移動(dòng)到singletonObjects然后在這里被清理掉。它就像一個(gè)餐廳的“備餐區(qū)”菜只進(jìn)行了一半的加工比如肉切好了但還沒下鍋炒但因?yàn)橄乱坏啦思毙柽@個(gè)原料所以先把它拿出來應(yīng)急。2.3 三級(jí)緩存singletonFactories– 生產(chǎn)半成品的工廠/** Cache of singleton factories: bean name to ObjectFactory. */ private final MapString, ObjectFactory? singletonFactories new HashMap(16);三級(jí)緩存是最特殊、也最容易被誤解的一級(jí)。它存放的不是Bean對(duì)象本身而是一個(gè)ObjectFactory?對(duì)象工廠。這個(gè)工廠的作用是當(dāng)需要獲取某個(gè)Bean的早期引用時(shí)能夠動(dòng)態(tài)地創(chuàng)建或返回一個(gè)處理過的對(duì)象。為什么需要工廠而不是直接放對(duì)象這涉及到Spring AOP以及通過Async、Transactional等注解實(shí)現(xiàn)的代理。如果一個(gè)Bean需要被代理例如被AOP切面增強(qiáng)那么最終暴露給其他Bean使用的不應(yīng)該是原始對(duì)象而應(yīng)該是它的代理對(duì)象。這個(gè)代理對(duì)象何時(shí)創(chuàng)建是在Bean初始化后由BeanPostProcessor處理的。但在循環(huán)依賴的場景下其他Bean在屬性注入階段就需要引用這個(gè)Bean此時(shí)它的代理可能還沒生成。ObjectFactory就是為了解決這個(gè)“時(shí)機(jī)”問題。它封裝了一段邏輯當(dāng)被調(diào)用時(shí)它可以判斷當(dāng)前情況決定是返回原始對(duì)象還是返回一個(gè)提前創(chuàng)建好的代理對(duì)象通過SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference方法。這給了Spring極大的靈活性。你可以把它理解為一張“菜品加工券”憑此券可以到后廚要求對(duì)半成品早期對(duì)象進(jìn)行特定的加工如代理然后得到最終可用的形態(tài)。注意三級(jí)緩存singletonFactories在Bean的早期引用被獲取一次后通常就會(huì)被移除。其對(duì)應(yīng)的ObjectFactory是一次性的執(zhí)行完就失效了。這是為了確保Bean引用的唯一性和一致性。3. 循環(huán)依賴的破局三級(jí)緩存協(xié)同作戰(zhàn)全流程理論總是抽象的我們通過一個(gè)經(jīng)典的Setter注入循環(huán)依賴場景來還原三級(jí)緩存是如何一步步配合打破僵局的。假設(shè)有AService和BService互相依賴。Service public class AService { Autowired private BService bService; // ... } Service public class BService { Autowired private AService aService; // ... }Spring容器啟動(dòng)開始創(chuàng)建AService這個(gè)Bean。這個(gè)過程發(fā)生在AbstractAutowireCapableBeanFactory.doCreateBean()方法中。3.1 第一步創(chuàng)建A實(shí)例并提前暴露工廠實(shí)例化Spring調(diào)用AService的構(gòu)造方法創(chuàng)建出一個(gè)原始對(duì)象a。此時(shí)a里面的bService字段是null。暴露工廠關(guān)鍵操作在屬性填充之前Spring會(huì)執(zhí)行一個(gè)至關(guān)重要的操作——addSingletonFactory。// AbstractAutowireCapableBeanFactory.doCreateBean boolean earlySingletonExposure (mbd.isSingleton() this.allowCircularReferences isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { // 將BeanName和對(duì)應(yīng)的ObjectFactory放入三級(jí)緩存 addSingletonFactory(beanName, () - getEarlyBeanReference(beanName, mbd, bean)); }此時(shí)AService對(duì)應(yīng)的ObjectFactory被放入了三級(jí)緩存singletonFactories。這個(gè)工廠封裝了獲取AService早期引用的邏輯其中包含了處理AOP代理的可能性。注意此時(shí)一級(jí)和二級(jí)緩存都沒有AService。3.2 第二步填充A的屬性觸發(fā)B的創(chuàng)建屬性填充Spring開始為AService的實(shí)例a填充屬性Autowired BService bService。獲取B為了得到BService容器調(diào)用getBean(“bService”)。創(chuàng)建B實(shí)例和A一樣Spring開始創(chuàng)建BService。先調(diào)用構(gòu)造方法創(chuàng)建出原始對(duì)象b然后將BService的ObjectFactory也放入三級(jí)緩存。3.3 第三步填充B的屬性向A求助B的屬性填充Spring開始為BService的實(shí)例b填充屬性Autowired AService aService。獲取A循環(huán)點(diǎn)容器再次調(diào)用getBean(“aService”)來獲取AService。三級(jí)緩存的第一次立功這次getBean不會(huì)從頭創(chuàng)建A而是會(huì)觸發(fā)緩存查找邏輯。在DefaultSingletonBeanRegistry.getSingleton(String, boolean)方法中查找順序是一級(jí)緩存singletonObjects沒有A還沒初始化完。二級(jí)緩存earlySingletonObjects沒有。三級(jí)緩存singletonFactories找到了之前存放的AService的ObjectFactory。執(zhí)行工廠Spring調(diào)用這個(gè)ObjectFactory.getObject()。這個(gè)方法會(huì)執(zhí)行g(shù)etEarlyBeanReference如果AService需要被代理比如有AOP切面這里就會(huì)提前生成代理對(duì)象如果不需要?jiǎng)t直接返回原始對(duì)象a。我們假設(shè)這里不需要代理返回了原始對(duì)象a。升級(jí)緩存從三級(jí)緩存獲取到對(duì)象a后Spring會(huì)做兩件事將對(duì)象a放入二級(jí)緩存earlySingletonObjects。將AService對(duì)應(yīng)的ObjectFactory從三級(jí)緩存中移除。 現(xiàn)在AService的早期引用a存在于二級(jí)緩存中。這個(gè)a被成功注入到了BService的實(shí)例b中。3.4 第四步B完成初始化回歸一級(jí)緩存B完成生命周期BService的屬性aService已經(jīng)注入完畢注入了A的早期引用a接著Spring完成BService的后續(xù)初始化執(zhí)行PostConstruct等得到一個(gè)完全體b。B入駐一級(jí)緩存完全體b被放入一級(jí)緩存singletonObjects。同時(shí)BService相關(guān)的ObjectFactory從三級(jí)緩存移除早期引用從二級(jí)緩存移除如果之前有的話。3.5 第五步A完成初始化閉環(huán)A繼續(xù)未竟之事此時(shí)AService的屬性填充步驟之前在等getBean(“bService”)返回終于收到了返回值——?jiǎng)倓倓?chuàng)建好的完全體b。于是b被注入到a的bService字段中。A完成生命周期AService接著完成自己的初始化過程。A入駐一級(jí)緩存清理二級(jí)緩存完全體的a被放入一級(jí)緩存。同時(shí)Spring會(huì)發(fā)現(xiàn)AService在二級(jí)緩存中還有一個(gè)早期引用于是將其從二級(jí)緩存中移除。至此循環(huán)依賴完美解決。AService和BService的成品Bean都安靜地待在一級(jí)緩存里可供隨時(shí)使用。整個(gè)過程中三級(jí)緩存提供了獲取早期引用的能力二級(jí)緩存作為臨時(shí)存儲(chǔ)避免了工廠的重復(fù)執(zhí)行一級(jí)緩存則是最終的歸宿。實(shí)操心得理解這個(gè)流程后你就能解釋很多現(xiàn)象。比如為什么構(gòu)造器注入無法解決循環(huán)依賴因?yàn)闃?gòu)造器注入發(fā)生在實(shí)例化階段此時(shí)對(duì)象還沒創(chuàng)建出來更無法提前暴露ObjectFactory到三級(jí)緩存死鎖必然發(fā)生。Setter/字段注入之所以可以是因?yàn)樽⑷氚l(fā)生在實(shí)例化之后、初始化之前那時(shí)已經(jīng)有對(duì)象和工廠可以提前暴露了。4. 為什么必須是三級(jí)兩級(jí)或一級(jí)不行嗎這是一個(gè)經(jīng)典的面試題也是理解Spring設(shè)計(jì)精妙之處的關(guān)鍵。我們分別來分析如果只有一級(jí)或兩級(jí)緩存會(huì)怎樣。4.1 假設(shè)只有一級(jí)緩存singletonObjects如果只有成品緩存那么流程根本無法進(jìn)行。當(dāng)創(chuàng)建A到一半需要B而創(chuàng)建B又需要A時(shí)由于A還沒有成為“成品”未完成屬性填充和初始化它不會(huì)被放入一級(jí)緩存。B在獲取A時(shí)直接返回null或拋出異常循環(huán)依賴無解。所以必須有一個(gè)空間來存放“半成品”。4.2 假設(shè)只有兩級(jí)緩存成品緩存半成品緩存這是我們思考的重點(diǎn)。很多初學(xué)者會(huì)想既然二級(jí)緩存earlySingletonObjects已經(jīng)能存放早期對(duì)象了為什么還要三級(jí)緩存singletonFactories這個(gè)工廠直接把早期對(duì)象放進(jìn)二級(jí)緩存不行嗎理論上對(duì)于沒有AOP的普通Bean是可行的。在A實(shí)例化后直接把原始對(duì)象a扔進(jìn)二級(jí)緩存。B創(chuàng)建時(shí)需要A直接從二級(jí)緩存拿到a注入然后B完成初始化A再完成初始化。似乎也能跑通。但一旦引入AOP或任何需要?jiǎng)?chuàng)建代理的BeanPostProcessor問題就來了。核心矛盾在于代理對(duì)象創(chuàng)建的時(shí)機(jī)與循環(huán)依賴的需求時(shí)機(jī)存在沖突。正常的、無循環(huán)依賴的Bean創(chuàng)建流程實(shí)例化 - 屬性填充 - 初始化 - (AOP)創(chuàng)建代理 - 放入一級(jí)緩存。代理是在初始化之后才創(chuàng)建的。循環(huán)依賴下的需求B在屬性填充階段就需要A的引用。如果此時(shí)A還在創(chuàng)建中它應(yīng)該給B一個(gè)什么給原始對(duì)象但最終B注入的應(yīng)該是A的代理對(duì)象否則AOP增強(qiáng)會(huì)失效例如Transactional注解的方法調(diào)用同類其他方法時(shí)如果注入的是原始對(duì)象事務(wù)會(huì)失效。給代理對(duì)象但A的初始化還沒完成代理對(duì)象按理說還無法生成。三級(jí)緩存中的ObjectFactory正是為了解決這個(gè)“時(shí)機(jī)悖論”而設(shè)計(jì)的。它不是一個(gè)簡單的對(duì)象存儲(chǔ)而是一個(gè)延遲決策和處理的機(jī)制。當(dāng)B通過getSingleton(“aService”)請(qǐng)求A時(shí)會(huì)調(diào)用三級(jí)緩存中的ObjectFactory.getObject()。這個(gè)方法內(nèi)部會(huì)調(diào)用SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference()。Spring內(nèi)置的AOP代理創(chuàng)建器AbstractAutoProxyCreator就實(shí)現(xiàn)了這個(gè)接口。如果A最終需要代理在getEarlyBeanReference()方法中AOP框架會(huì)判斷是否已經(jīng)為這個(gè)Bean創(chuàng)建過早期代理。如果是第一次被索取早期引用它會(huì)提前為A創(chuàng)建代理對(duì)象并返回。這個(gè)代理對(duì)象會(huì)被放入二級(jí)緩存后續(xù)所有需要A早期引用的地方雖然通常只有一個(gè)都從這個(gè)二級(jí)緩存獲取保證了引用的一致性。如果A最終不需要代理getEarlyBeanReference()方法直接返回原始對(duì)象。所以三級(jí)緩存的核心價(jià)值在于將“早期引用”的生成邏輯封裝成一個(gè)可延遲執(zhí)行的工廠。它把“是否要?jiǎng)?chuàng)建代理”以及“如何創(chuàng)建代理”的決策推遲到真正有其他Bean需要注入它的那一刻從而完美適配了AOP代理的創(chuàng)建流程保證了在循環(huán)依賴場景下注入的引用與最終成品Bean無論是原始對(duì)象還是代理對(duì)象在類型和行為上的一致性。踩坑記錄這就是為什么在我的開篇案例中給一個(gè)Service方法加上Async會(huì)引發(fā)循環(huán)依賴異常。Async也是通過BeanPostProcessor創(chuàng)建代理來實(shí)現(xiàn)的。在某些復(fù)雜的代理創(chuàng)建場景或代理處理器順序問題下三級(jí)緩存的協(xié)調(diào)過程可能出現(xiàn)意外導(dǎo)致早期引用獲取失敗從而拋出BeanCurrentlyInCreationException。解決方法通常是調(diào)整Bean的依賴關(guān)系或者使用Lazy注解進(jìn)行延遲注入打破即時(shí)的依賴索取。5. 三級(jí)緩存的邊界與失效場景三級(jí)緩存機(jī)制雖然強(qiáng)大但它不是萬能的。理解它的邊界能幫助我們在設(shè)計(jì)時(shí)避免陷阱。5.1 非單例BeanPrototype三級(jí)緩存只針對(duì)單例SingletonBean。對(duì)于原型Prototype作用域的BeanSpring容器根本不會(huì)緩存它們每次getBean()都會(huì)創(chuàng)建一個(gè)新的實(shí)例。因此原型Bean之間的循環(huán)依賴Spring會(huì)直接拋出BeanCurrentlyInCreationException因?yàn)樗鼰o法也不應(yīng)該去解決這種每次請(qǐng)求都產(chǎn)生新對(duì)象的依賴閉環(huán)。5.2 構(gòu)造器注入Constructor Injection如前所述這是三級(jí)緩存機(jī)制無法解決的硬傷。因?yàn)闃?gòu)造器調(diào)用發(fā)生在實(shí)例化階段的第一步此時(shí)Bean的實(shí)例尚未創(chuàng)建更談不上將ObjectFactory加入三級(jí)緩存。當(dāng)兩個(gè)Bean都通過構(gòu)造器相互依賴時(shí)Spring在啟動(dòng)時(shí)就會(huì)檢測到并拋出異常。這是Spring官方明確聲明不支持的情況。解決方法是改用Setter或字段注入或者重構(gòu)設(shè)計(jì)消除循環(huán)依賴。5.3 某些特殊的BeanPostProcessor處理順序Spring允許我們自定義BeanPostProcessor并且可以通過實(shí)現(xiàn)Ordered接口或使用Order注解來指定執(zhí)行順序。如果某個(gè)BeanPostProcessor在SmartInstantiationAwareBeanPostProcessor負(fù)責(zé)getEarlyBeanReference之前執(zhí)行并且它試圖去獲取一個(gè)正在創(chuàng)建中的Bean的最終形態(tài)可能會(huì)遇到問題。因?yàn)榇藭r(shí)可能連早期引用都還沒生成。5.4allowCircularReferences配置在AbstractApplicationContext中有一個(gè)setAllowCircularReferences(boolean)方法默認(rèn)是true。如果將其設(shè)置為falseSpring將完全禁止循環(huán)依賴三級(jí)緩存的循環(huán)依賴解決機(jī)制將被關(guān)閉。任何形式的循環(huán)依賴都會(huì)導(dǎo)致啟動(dòng)失敗。這個(gè)配置在某些對(duì)代碼質(zhì)量要求極高、強(qiáng)制要求消除所有循環(huán)依賴的項(xiàng)目中可能會(huì)被使用。6. 從源碼角度驗(yàn)證getSingleton方法逐行解析讓我們聚焦到最核心的DefaultSingletonBeanRegistry.getSingleton(String, boolean)方法看看代碼是如何實(shí)現(xiàn)上述邏輯的。這個(gè)方法清晰地展示了三級(jí)緩存的查詢順序和升級(jí)邏輯。// DefaultSingletonBeanRegistry.java protected Object getSingleton(String beanName, boolean allowEarlyReference) { // 1. 首先嘗試從一級(jí)緩存成品緩存獲取 Object singletonObject this.singletonObjects.get(beanName); // 如果沒找到并且該Bean正在創(chuàng)建中說明可能存在循環(huán)依賴 if (singletonObject null isSingletonCurrentlyInCreation(beanName)) { synchronized (this.singletonObjects) { // 2. 嘗試從二級(jí)緩存早期引用緩存獲取 singletonObject this.earlySingletonObjects.get(beanName); if (singletonObject null allowEarlyReference) { // 3. 嘗試從三級(jí)緩存工廠緩存獲取工廠 ObjectFactory? singletonFactory this.singletonFactories.get(beanName); if (singletonFactory ! null) { // 4. 執(zhí)行工廠獲取早期對(duì)象 singletonObject singletonFactory.getObject(); // 5. 將獲取到的對(duì)象放入二級(jí)緩存并從三級(jí)緩存移除工廠 this.earlySingletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName); } } } } return singletonObject; }這段代碼是三級(jí)緩存協(xié)同工作的核心算法先查一級(jí)最快路徑直接返回成品。再查二級(jí)如果Bean正在創(chuàng)建中說明它可能是個(gè)“半成品”去二級(jí)緩存找找看有沒有提前放進(jìn)去的早期引用。最后查三級(jí)如果二級(jí)也沒有但允許早期引用allowEarlyReference通常為true就去三級(jí)緩存找工廠。工廠生產(chǎn)與緩存升級(jí)找到工廠后調(diào)用getObject()生產(chǎn)出早期對(duì)象可能是原始對(duì)象也可能是提前創(chuàng)建的代理。然后將這個(gè)對(duì)象升級(jí)到二級(jí)緩存同時(shí)刪除三級(jí)緩存中的工廠。這個(gè)“升級(jí)”操作確保了同一個(gè)Bean的早期引用只會(huì)通過工廠創(chuàng)建一次后續(xù)的索取都直接走二級(jí)緩存保證了效率與一致性。7. 設(shè)計(jì)啟示與最佳實(shí)踐探究Spring三級(jí)緩存機(jī)制不僅能幫助我們解決實(shí)際問題更能獲得一些深刻的設(shè)計(jì)啟示。1. 空間換時(shí)間與延遲決策三級(jí)緩存本質(zhì)上是“空間換時(shí)間”和“延遲決策”的經(jīng)典結(jié)合。通過引入額外的存儲(chǔ)結(jié)構(gòu)二級(jí)、三級(jí)緩存避免了循環(huán)依賴導(dǎo)致的死鎖。更重要的是通過ObjectFactory將代理對(duì)象的創(chuàng)建決策延遲到真正被需要的那一刻優(yōu)雅地解決了代理時(shí)機(jī)問題。這在軟件設(shè)計(jì)中是一個(gè)常用思路當(dāng)面臨不確定或成本較高的操作時(shí)先提供一個(gè)輕量的“承諾”或“工廠”等到必須執(zhí)行時(shí)再兌現(xiàn)。2. 狀態(tài)遷移的清晰界定從三級(jí)緩存工廠- 二級(jí)緩存半成品- 一級(jí)緩存成品Bean的狀態(tài)遷移路徑非常清晰。每一級(jí)緩存都代表了Bean生命周期的不同階段。這種明確的狀態(tài)劃分使得代碼邏輯如getSingleton方法可以有條不紊地處理各種邊界情況。在我們的業(yè)務(wù)代碼設(shè)計(jì)中明確對(duì)象的狀態(tài)并為之設(shè)計(jì)相應(yīng)的處理邏輯同樣能減少Bug。3. 對(duì)Spring使用者的建議優(yōu)先使用構(gòu)造器注入雖然它不能解決循環(huán)依賴但它是一種更安全的依賴注入方式能明確聲明Bean的必需依賴并使Bean在構(gòu)造完成后就處于完全初始化的狀態(tài)。很多現(xiàn)代Spring實(shí)踐如Spring官方指南都推薦構(gòu)造器注入作為首選。警惕循環(huán)依賴盡管Spring提供了三級(jí)緩存機(jī)制來救場但循環(huán)依賴本身是代碼結(jié)構(gòu)上的一個(gè)“壞味道”Code Smell它通常意味著類的職責(zé)邊界不清晰耦合度過高。應(yīng)當(dāng)將其視為重構(gòu)的提示考慮使用“引入第三方”、“事件驅(qū)動(dòng)”、“方法參數(shù)傳遞”等方式來解耦。理解Lazy注解Lazy注解是解決某些復(fù)雜循環(huán)依賴場景的利器。它告訴Spring延遲初始化Bean或者在注入時(shí)先注入一個(gè)代理等到第一次真正調(diào)用時(shí)再初始化真實(shí)對(duì)象。這相當(dāng)于在依賴鏈中插入了一個(gè)“緩沖”打破了即時(shí)的循環(huán)。但濫用Lazy可能會(huì)掩蓋設(shè)計(jì)問題并帶來運(yùn)行時(shí)性能開銷和調(diào)試復(fù)雜性。復(fù)雜AOP場景下的測試當(dāng)你的服務(wù)層大量使用Transactional,Async,Cacheable等基于AOP的注解時(shí)在涉及循環(huán)依賴的Bean上進(jìn)行集成測試尤為重要以確保代理被正確創(chuàng)建且行為符合預(yù)期。回過頭看最初那個(gè)因Async引發(fā)的異常根本原因是在那個(gè)特定場景下代理創(chuàng)建鏈與三級(jí)緩存的交互出現(xiàn)了預(yù)期之外的情況。最終的解決方案并不是調(diào)整緩存而是通過代碼重構(gòu)將AService中一個(gè)獨(dú)立的方法抽離到一個(gè)新的TaskService中由這個(gè)新Service來承載Async方法從而徹底消除了AService和BService之間的直接循環(huán)依賴。這再次印證了那句話框架提供的復(fù)雜機(jī)制是我們的安全網(wǎng)但清晰簡潔的代碼設(shè)計(jì)才是最好的保障。