從一次啟動失敗深入剖析：Spring循環(huán)依賴的真相
一、背景
二、相關(guān)知識點簡介
1. 循環(huán)依賴
2.Spring創(chuàng)建Bean主要流程
三、案例分析
1. 代碼分析
2. 問題分析
3. 解決方案
四、總結(jié)
一、背 景
預(yù)發(fā)環(huán)境一個后臺服務(wù)admin突然啟動失敗，異常如下：
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'timeoutNotifyController': Injection of resource dependencies failed; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'spuCheckDomainServiceImpl': Bean with name 'spuCheckDomainServiceImpl' has been injected into other beans [...] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:598)
at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:376)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1404)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:592)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:515)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:847)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:877)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:549)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:141)
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:744)
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:391)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:312)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1215)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1204)
at com.shizhuang.duapp.commodity.interfaces.admin.CommodityAdminApplication.main(CommodityAdminApplication.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:51)
at org.springframework.boot.loader.PropertiesLauncher.main(PropertiesLauncher.java:578)錯誤日志中明確寫道：“Bean has been injected into other beans ... in its raw version as part of a circular reference, but has eventually been wrapped.”這不僅僅是一個簡單的循環(huán)依賴錯誤。它揭示了一個更深層次的問題：當(dāng)循環(huán)依賴遇上Spring的AOP代理（如@Transactional事務(wù)、自定義切面等），Spring在解決依賴的時，不得已將一個“半成品”（原始Bean）注入給了其他30多個Bean。而當(dāng)這個“半成品”最終被“包裝”（代理）成“成品”時，先前那些持有“半成品”引用的Bean們，使用的卻是一個錯誤的版本。
這就像在組裝一個精密機(jī)器時，你把一個未經(jīng)質(zhì)檢的零件提前裝了進(jìn)去，等質(zhì)檢完成后，機(jī)器里混用著新舊版本的零件，最終的崩潰也就不可避免。
本篇文章將帶你一起：
- 熟悉spring容器的循環(huán)依賴以及Spring容器如何解決循環(huán)依賴，創(chuàng)建bean相關(guān)的流程。
- 深入解讀這條復(fù)雜錯誤日志背后的每一個關(guān)鍵線索；
- 提供緊急止血方案；
- 分享如何從架構(gòu)設(shè)計上避免此類問題的實踐心得。
二、相關(guān)知識點簡介
循環(huán)依賴
什么是Bean循環(huán)依賴？
循環(huán)依賴：說白是一個或多個對象實例之間存在直接或間接的依賴關(guān)系，這種依賴關(guān)系構(gòu)成了構(gòu)成一個環(huán)形調(diào)用，主要有如下幾種情況。
第一種情況：自己依賴自己的直接依賴
圖片
第二種情況：兩個對象之間的直接依賴
圖片
前面兩種情況的直接循環(huán)依賴比較直觀，非常好識別，但是第三種間接循環(huán)依賴的情況有時候因為業(yè)務(wù)代碼調(diào)用層級很深，不容易識別出來。
循環(huán)依賴場景
構(gòu)造器注入循環(huán)依賴：
@Service
public class A {public A(B b) {}}
@Service
public class B {public B(A a) {}}結(jié)果：項目啟動失敗拋出異常BeanCurrentlyInCreationException
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference?
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java:339)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:215)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)構(gòu)造器注入構(gòu)成的循環(huán)依賴，此種循環(huán)依賴方式無論是Singleton模式還是prototype模式都是無法解決的，只能拋出BeanCurrentlyInCreationException異常表示循環(huán)依賴。原因是Spring解決循環(huán)依賴依靠的是Bean的“中間態(tài)”這個概念，而中間態(tài)指的是已經(jīng)實例化，但還沒初始化的狀態(tài)。而完成實例化需要調(diào)用構(gòu)造器，所以構(gòu)造器的循環(huán)依賴無法解決。
Singleton模式field屬性注入（setter方法注入）循環(huán)依賴：
這種方式是我們最為常用的依賴注入方式：
@Service
public class A {
@Autowired
private B b;
}
@Service
public class B {
@Autowired
private A a;
}結(jié)果：項目啟動成功，正常運(yùn)行
prototype field屬性注入循環(huán)依賴：
prototype在平時使用情況較少，但是也并不是不會使用到，因此此種方式也需要引起重視。
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class A {
@Autowired
private B b;
}
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class B {
@Autowired
private A a;
}結(jié)果：需要注意的是本例中啟動時是不會報錯的（因為非單例Bean默認(rèn)不會初始化，而是使用時才會初始化），所以很簡單咱們只需要手動getBean()或者在一個單例Bean內(nèi)@Autowired一下它即可。
// 在單例Bean內(nèi)注入
@Autowired
private A a;這樣子啟動就報錯：
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'mytest.TestSpringBean': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'b': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference?
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:596)
at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:374)如何解決？可能有的小伙伴看到網(wǎng)上有說使用@Lazy注解解決：
@Lazy
@Autowired
private A a;此處負(fù)責(zé)任的告訴你這樣是解決不了問題的(可能會掩蓋問題)，@Lazy只是延遲初始化而已，當(dāng)你真正使用到它（初始化）的時候，依舊會報如上異常。
對于Spring循環(huán)依賴的情況總結(jié)如下：
- 不能解決的情況：構(gòu)造器注入循環(huán)依賴，prototype field屬性注入循環(huán)依賴
- 能解決的情況：field屬性注入（setter方法注入）循環(huán)依賴
Spring如何解決循環(huán)依賴
Spring 是通過三級緩存和提前曝光的機(jī)制來解決循環(huán)依賴的問題。
三級緩存
三級緩存其實就是用三個 Map 來存儲不同階段 Bean 對象。
一級緩存
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
二級緩存
private final Map<String, ObjectearlySingletonObjects = new HashMap<>(16);
//三級緩存
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16)- singletonObjects：用于存放完全初始化好的 bean，從該緩存中取出的 bean 可以直接使用。
- earlySingletonObjects：提前曝光的單例對象的cache，存放原始的 bean 對象（尚未填充屬性），用于解決循環(huán)依賴。
- singletonFactories：單例對象工廠的cache，存放 bean 工廠對象，用于解決循環(huán)依賴。
三級緩存解決循環(huán)依賴過程
假設(shè)現(xiàn)在我們有ServiceA和ServiceB兩個類，這兩個類相互依賴，代碼如下：
@Service
public class ServiceA {
@Autowired
private ServiceB serviceB;
}
@Service
public class ServiceB {
@Autowired
private ServiceA serviceA ;
}下面的時序圖說明了spring用三級緩存解決循環(huán)依賴的主要流程：
圖片
為什么需要三級緩存？
這是一個理解Spring容器如何解決循環(huán)依賴的核心概念。三級緩存是Spring為了解決循環(huán)依賴的同時，又能保證AOP代理的正確性而設(shè)計的精妙機(jī)制。
為了理解為什么需要三級緩存，我們一步步來看。
如果沒有緩存（Level 0）
假設(shè)有兩個Bean：ServiceA 和 ServiceB，它們相互依賴。
Java
@Component
public class ServiceA {
@Autowired
private ServiceB serviceB;
}
@Component
public class ServiceB {
@Autowired
private ServiceA serviceA;
}創(chuàng)建過程（無緩存）：
- 開始創(chuàng)建 ServiceA -> 發(fā)現(xiàn) ServiceA 需要 ServiceB -> 開始創(chuàng)建 ServiceB
- 開始創(chuàng)建 ServiceB -> 發(fā)現(xiàn) ServiceB 需要 ServiceA -> 開始創(chuàng)建 ServiceA
- 開始創(chuàng)建 ServiceA -> 發(fā)現(xiàn) ServiceA 需要 ServiceB -> ... 無限循環(huán)，StackOverflowError
結(jié)論：無法解決循環(huán)依賴，直接死循環(huán)。
如果只有一級緩存（Singleton Objects）
一級緩存存放的是已經(jīng)完全創(chuàng)建好、初始化完畢的Bean。
問題：在Bean的創(chuàng)建過程中（比如在填充屬性 populateBean 時），ServiceA還沒創(chuàng)建完，它本身不應(yīng)該被放入"已完成"的一級緩存。但如果ServiceB需要ServiceA，而一級緩存里又沒有ServiceA的半成品，ServiceB就無法完成創(chuàng)建。這就回到了上面的死循環(huán)問題。
結(jié)論：一級緩存無法解決循環(huán)依賴。
如果使用二級緩存
二級緩存的核心思路是：將尚未完全初始化好的“早期引用”暴露出來。
現(xiàn)在我們有：
- 一級緩存（成品庫）：存放完全準(zhǔn)備好的Bean。
- 二級緩存（半成品庫）：存放剛剛實例化（調(diào)用了構(gòu)造方法），但還未填充屬性和初始化的Bean的早期引用。
創(chuàng)建過程（二級緩存）：
開始創(chuàng)建ServiceA：
- 實例化ServiceA（調(diào)用ServiceA的構(gòu)造方法），得到一個ServiceA的原始對象。
- 將ServiceA的原始對象放入二級緩存（半成品庫）。
- 開始為ServiceA填充屬性 -> 發(fā)現(xiàn)需要ServiceB。
開始創(chuàng)建ServiceB：
- 實例化ServiceB（調(diào)用B的構(gòu)造方法），得到一個ServiceB的原始對象。
- 將ServiceB的原始對象放入二級緩存。
- 開始為ServiceB填充屬性 -> 發(fā)現(xiàn)需要ServiceA。
ServiceB從二級緩存中獲取A：
- ServiceB成功從二級緩存中拿到了ServiceA的早期引用（原始對象）。
- ServiceB順利完成了屬性填充、初始化等后續(xù)步驟，成為一個完整的Bean。
- 將完整的ServiceB放入一級緩存（成品庫），并從二級緩存移除ServiceB。
ServiceA繼續(xù)創(chuàng)建：
- ServiceA拿到了創(chuàng)建好的ServiceB，完成了自己的屬性填充和初始化。
- 將完整的ServiceA放入一級緩存（成品庫），并從二級緩存移除ServiceA。
問題來了：如果ServiceA需要被AOP代理怎么辦？
如果A類上加了 @Transactional 等需要創(chuàng)建代理的注解，那么最終需要暴露給其他Bean的應(yīng)該是ServiceA的代理對象，而不是ServiceA的原始對象。
在二級緩存方案中，ServiceB拿到的是A的原始對象。但最終ServiceA完成后，放入一級緩存的是ServiceA的代理對象。這就導(dǎo)致了：
- ServiceB里面持有的ServiceA是原始對象。
- 而其他地方注入的ServiceA是代理對象。
- 這就造成了不一致！如果通過ServiceB的ServiceA去調(diào)用事務(wù)方法，事務(wù)會失效，因為那是一個沒有被代理的原始對象。
結(jié)論：二級緩存可以解決循環(huán)依賴問題，但無法正確處理需要AOP代理的Bean。
三級緩存的登場（Spring的終極方案）
為了解決代理問題，Spring引入了第三級緩存。它的核心不是一個直接存放對象（Object）的緩存，而是一個存放 ObjectFactory（對象工廠）的緩存。
三級緩存的結(jié)構(gòu)是：Map<String, ObjectFactory<?>> singletonFactories
創(chuàng)建過程（三級緩存，以ServiceA需要代理為例）：
- 開始創(chuàng)建ServiceA：
- 實例化ServiceA，得到ServiceA的原始對象。
- 向三級緩存添加一個ObjectFactory。這個工廠的getObject()方法有能力判斷ServiceA是否需要代理，并返回相應(yīng)的對象（原始對象或代理對象）。
- 開始為ServiceA填充屬性 -> 發(fā)現(xiàn)需要ServiceB。
- 開始創(chuàng)建B：
- 實例化ServiceB。
- 同樣向三級緩存添加一個ServiceB的ObjectFactory。
- 開始為ServiceB填充屬性 -> 發(fā)現(xiàn)需要ServiceA。
- ServiceB從緩存中獲取ServiceA：
- ServiceB發(fā)現(xiàn)一級緩存沒有ServiceA，二級緩存也沒有ServiceA。
- ServiceB發(fā)現(xiàn)三級緩存有A的ObjectFactory。
- B調(diào)用這個工廠的getObject()方法。此時，Spring會執(zhí)行一個關(guān)鍵邏輯：
如果ServiceA需要被代理，工廠會提前生成ServiceA的代理對象并返回。
如果ServiceA不需要代理，工廠則返回A的原始對象。
- 將這個早期引用（可能是原始對象，也可能是代理對象）放入二級緩存，同時從三級緩存移除A的工廠。
- ServiceB拿到了ServiceA的正確版本的早期引用。
后續(xù)步驟：
- ServiceB完成創(chuàng)建，放入一級緩存。
- ServiceA繼續(xù)用ServiceB完成創(chuàng)建。在ServiceA初始化的最后，Spring會再次檢查：如果ServiceA已經(jīng)被提前代理了（即在第3步中），那么就直接返回這個代理對象；如果沒有，則可能在此處創(chuàng)建代理（對于不需要解決循環(huán)依賴的Bean）。
- 最終，將完整的ServiceA（代理對象）放入一級緩存，并清理二級緩存。
總結(jié)：為什么需要三級緩存？
需要三級緩存，是因為Spring要解決一個復(fù)雜問題：在存在循環(huán)依賴的情況下，如何確保所有Bean都能拿到最終形態(tài)（可能被AOP代理）的依賴對象，而不是原始的、未代理的對象。 三級緩存通過一個ObjectFactory將代理的時機(jī)提前，完美地解決了這個問題。二級緩存主要是為了性能優(yōu)化而存在的。
spring三級緩存為什么不能解決
@Async注解的循環(huán)依賴問題
這觸及了 Spring 代理機(jī)制的一個深層次區(qū)別。@Async注解的循環(huán)依賴問題確實比@Transactional 更復(fù)雜，三級緩存無法完全解決。讓我們深入分析原因。
Spring創(chuàng)建Bean主要流程
為了容易理解 Spring 解決循環(huán)依賴過程，我們先簡單溫習(xí)下 Spring 容器創(chuàng)建 Bean 的主要流程。
從代碼看Spring對于Bean的生成過程，步驟還是很多的，我把一些擴(kuò)展業(yè)務(wù)代碼省略掉：
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
throws BeanCreationException {
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
// Bean初始化第一步：默認(rèn)調(diào)用無參構(gòu)造實例化Bean
// 如果是只有帶參數(shù)的構(gòu)造方法，構(gòu)造方法里的參數(shù)依賴注入，就是發(fā)生在這一步
if (instanceWrapper == null) {
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
//判斷Bean是否需要提前暴露對象用來解決循環(huán)依賴，需要則啟動spring三級緩存
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isTraceEnabled()) {
logger.trace("Eagerly caching bean '" + beanName +
"' to allow for resolving potential circular references");
}
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
// Initialize the bean instance.
Object exposedObject = bean;
try {
// bean創(chuàng)建第二步：填充屬性（DI依賴注入發(fā)生在此步驟）
populateBean(beanName, mbd, instanceWrapper);
// bean創(chuàng)建第三步：調(diào)用初始化方法，完成bean的初始化操作（AOP的第三個入口）
// AOP是通過自動代理創(chuàng)建器AbstractAutoProxyCreator的postProcessAfterInitialization()
//方法的執(zhí)行進(jìn)行代理對象的創(chuàng)建的,AbstractAutoProxyCreator是BeanPostProcessor接口的實現(xiàn)
exposedObject = initializeBean(beanName, exposedObject, mbd);
if (earlySingletonExposure) {
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
} catch (Throwable ex) {
// ...
}
// ...
return exposedObject;
}從上述代碼看出，整體脈絡(luò)可以歸納成 3 個核心步驟：
- 實例化Bean：主要是通過反射調(diào)用默認(rèn)構(gòu)造函數(shù)創(chuàng)建 Bean 實例，此時Bean的屬性都還是默認(rèn)值null。被注解@Bean標(biāo)記的方法就是此階段被調(diào)用的。
- 填充Bean屬性：這一步主要是對Bean的依賴屬性進(jìn)行填充，對@Value、@Autowired、@Resource注解標(biāo)注的屬性注入對象引用。
- 調(diào)用Bean初始化方法：調(diào)用配置指定中的init方法，如 xml文件指定Bean的init-method方法或注解 @Bean(initMethod = "initMethod")指定的方法。
三、案例分析
代碼分析
以下是我簡化后的類之間大體的依賴關(guān)系，工程內(nèi)實際的依賴情況會比這個簡化版本復(fù)雜一些。
@RestController
public class OldCenterSpuController {
@Resource
private NewSpuApplyCheckServiceImpl newSpuApplyCheckServiceImpl;
}
@RestController
public class TimeoutNotifyController {
@Resource
private SpuCheckDomainServiceImpl spuCheckDomainServiceImpl;
}
@Component
public class NewSpuApplyCheckServiceImpl {
@Resource
private SpuCheckDomainServiceImpl spuCheckDomainServiceImpl;
}
@Component
@Slf4j
@Validated
public class SpuCheckDomainServiceImpl {
@Resource
private NewSpuApplyCheckServiceImpl newSpuApplyCheckServiceImpl;
}從代碼看，主要是SpuCheckDomainServiceImpl和NewSpuApplyCheckServiceImpl 構(gòu)成了一個依賴環(huán)。而我們從正常啟動的bean加載順序發(fā)現(xiàn)首先是從OldCenterSpuController開始加載的，具體情況如下所示：
OldCenterSpuController
↓ (依賴)
NewSpuApplyCheckServiceImpl
↓ (依賴)
SpuCheckDomainServiceImpl
↓ (依賴)
NewSpuApplyCheckServiceImpl異常啟動的情況bean加載是從TimeoutNotifyController開始加載的，具體情況如下所示：
TimeoutNotifyController
↓ (依賴)
SpuCheckDomainServiceImpl
↓ (依賴)
NewSpuApplyCheckServiceImpl
↓ (依賴)
SpuCheckDomainServiceImpl同一個依賴環(huán)，為什么從OldCenterSpuController 開始加載就可以正常啟動，而從TimeoutNotifyController 啟動就會啟動異常呢？下面我們會從現(xiàn)場debug的角度來分析解釋這個問題。
問題分析
在相關(guān)知識點簡介里面知悉到spring用三級緩存解決了循環(huán)依賴問題。為什么后臺服務(wù)admin啟動還會報循環(huán)依賴的問題呢？
要得到問題的答案，還是需要回到源碼本身，前面我們分析了spring的創(chuàng)建Bean的主要流程，這里為了更好的分析問題，補(bǔ)充下通過容器獲取Bean的。
在通過spring容器獲取bean時，底層統(tǒng)一會調(diào)用doGetBean方法，大體如下：
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
@Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
final String beanName = transformedBeanName(name);
Object bean;
// 從三級緩存獲取bean
Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null) {
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
}else {
if (mbd.isSingleton()) {
sharedInstance = getSingleton(beanName, () -> {
try {
//如果是單例Bean，從三級緩存沒有獲取到bean，則執(zhí)行創(chuàng)建bean邏輯
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
}從doGetBean方法邏輯看，在spring從一二三級緩存獲取bean返回空時，會調(diào)用createBean方法去場景bean，createBean方法底層主要是調(diào)用前面我們提到的創(chuàng)建Bean流程的doCreateBean方法。
注意：doGetBean方法里面getSingleton方法的邏輯是先從一級緩存拿，拿到為空并且bean在創(chuàng)建中則又從二級緩存拿，二級緩存拿到為空 并且當(dāng)前容器允許有循環(huán)依賴則從三級緩存拿。并且將對象工廠移到二級緩存，刪除三級緩存
doCreateBean方法如下：
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
throws BeanCreationException {
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
// Bean初始化第一步：默認(rèn)調(diào)用無參構(gòu)造實例化Bean
// 如果是只有帶參數(shù)的構(gòu)造方法，構(gòu)造方法里的參數(shù)依賴注入，就是發(fā)生在這一步
if (instanceWrapper == null) {
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
//判斷Bean是否需要提前暴露對象用來解決循環(huán)依賴，需要則啟動spring三級緩存
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isTraceEnabled()) {
logger.trace("Eagerly caching bean '" + beanName +
"' to allow for resolving potential circular references");
}
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
// Initialize the bean instance.
Object exposedObject = bean;
try {
// bean創(chuàng)建第二步：填充屬性（DI依賴注入發(fā)生在此步驟）
populateBean(beanName, mbd, instanceWrapper);
// bean創(chuàng)建第三步：調(diào)用初始化方法，完成bean的初始化操作（AOP的第三個入口）
// AOP是通過自動代理創(chuàng)建器AbstractAutoProxyCreator的postProcessAfterInitialization()
//方法的執(zhí)行進(jìn)行代理對象的創(chuàng)建的,AbstractAutoProxyCreator是BeanPostProcessor接口的實現(xiàn)
exposedObject = initializeBean(beanName, exposedObject, mbd);
if (earlySingletonExposure) {
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
} catch (Throwable ex) {
// ...
}
// ...
return exposedObject;
}將doGetBean和doCreateBean的邏輯轉(zhuǎn)換成流程圖如下：
圖片
從流程圖可以看出，后臺服務(wù)admin啟動失敗拋出UnsatisfiedDependencyException異常的必要條件是存在循環(huán)依賴，因為不存在循環(huán)依賴的情況bean只會存在單次加載，單次加載的情況bean只會被放進(jìn)spring的第三級緩存。
而觸發(fā)UnsatisfiedDependencyException異常的先決條件是需要spring的第一二級緩存有當(dāng)前的bean。所以可以知道當(dāng)前bean肯定存在循環(huán)依賴。在存在循環(huán)依賴的情況下，當(dāng)前bean被第一次獲取（即調(diào)用doGetBean方法）會緩存進(jìn)spring的第三級緩存，然后會注入當(dāng)前bean的依賴（即調(diào)用populateBean方法），在當(dāng)前bean所在依賴環(huán)內(nèi)其他bean都不在一二級緩存的情況下，會觸發(fā)當(dāng)前bean的第二次獲?。凑{(diào)用doGetBean方法），由于第一次獲取已經(jīng)將Bean放進(jìn)了第三級緩存，spring會將Bean從第三級緩存移到二級緩存并刪除第三級緩存。
最終會回到第一次獲取的流程，調(diào)用初始化方法做初始化。最終在初始化有對當(dāng)前bean做代理增強(qiáng)的并且提前暴露到二級緩存的對象有被其他依賴引用到，而且allowRawInjectinotallow=false的情況下，會導(dǎo)致拋出UnsatisfiedDependencyException，進(jìn)而導(dǎo)致啟動異常。
注意：在注入當(dāng)前bean的依賴時，這里spring將Bean從第三級緩存移到二級緩存并刪除第三級緩存后，當(dāng)前bean的依賴的其他bean會從二級緩存拿到當(dāng)前bean做依賴。這也是后續(xù)拋異常的先決條件
結(jié)合admin有時候啟動正常，有時候啟動異常的情況，這里猜測啟動正常和啟動異常時bean加載順序不一致，進(jìn)而導(dǎo)致啟動正常時當(dāng)前Bean只會被獲取一次，啟動異常時當(dāng)前bean會被獲取兩次。為了驗證猜想，我們分別針對啟動異常和啟動正常的bean獲取做了debug。
debug分析
首先我們從啟動異常提取到以下關(guān)鍵信息，從這些信息可以知道是spuCheckDomainServiceImpl的加載觸發(fā)的啟動異常。所以我們這里以spuCheckDomainServiceImpl作為前面流程分析的當(dāng)前bean。
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'timeoutNotifyController': Injection of resource dependencies failed; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'spuCheckDomainServiceImpl': Bean with name 'spuCheckDomainServiceImpl' has been injected into other beans [...] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.然后提前我們在doCreateBean方法設(shè)置好spuCheckDomainServiceImpl加載時的條件斷點。我們先debug啟動異常的情況。最終斷點信息如下：
圖片
從紅框1里面的兩個引用看，很明顯調(diào)initializeBean方法時spring有對spuCheckDomainServiceImpl做代理增強(qiáng)。導(dǎo)致initializeBean后返回的引用和提前暴露到二級緩存的引用是不一致的。這里spuCheckDomainServiceImpl有二級緩存是跟我們前面分析的吻合，是因為spuCheckDomainServiceImpl被獲取了兩次，即調(diào)了兩次doGetBean。
從紅框2里面的actualDependentBeans的set集合知道提前暴露到二級緩存的引用有被其他33個bean引用到，也是跟異常提示的bean列表保持一致的。
這里spuCheckDomainServiceImpl的加載為什么會調(diào)用兩次doGetBean方法呢？
從調(diào)用棧分析到該加載鏈如下：
TimeoutNotifyController ->spuCheckDomainServiceImpl-> newSpuApplyCheckServiceImpl-> ... ->spuCheckDomainServiceImplTimeoutNotifyController注入依賴時第一次調(diào)用doGetBean獲取spuCheckDomainServiceImpl時，從一二三級緩存獲取不到，會調(diào)用doCreateBean方法創(chuàng)建spuCheckDomainServiceImpl。
首先會將spuDomainServiceImpl放進(jìn)spring的第三級緩存，然后開始調(diào)populateBean方法注入依賴，由于在循環(huán)中間的newSpuApplyCheckServiceImpl是第一次獲取，一二三級緩存都獲取不到，會調(diào)用doCreateBean去創(chuàng)建對應(yīng)的bean，然后會第二次調(diào)用doGetBean獲取spuCheckDomainServiceImpl，這時spuCheckDomainServiceImpl在第一次獲取已經(jīng)將bean加載到第三級緩存，所以這次spring會將bean從第三級緩存直接移到第二級緩存，并將第三級緩存里面的spuCheckDomainServiceImpl對應(yīng)的bean刪除，并直接返回二級緩存里面的bean，不會再調(diào)doCreateBean去創(chuàng)建spuCheckDomainServiceImpl。最終完成了循環(huán)中間的bean的初始化后（這里循環(huán)中間的bean初始化時依賴到的bean如果有引用到spuCheckDomainServiceImpl會調(diào)用doGetBean方法從二級緩存拿到spuCheckDomainServiceImpl提前暴露的引用），會回到第一次調(diào)用doGetBean獲取spuCheckDomainServiceImpl時調(diào)用的doCreateBean方法的流程。繼續(xù)調(diào)initializeBean方法完成初始化，然后將初始化完成的bean返回。最終拿初始化返回的bean引用跟二級緩存拿到的bean引用做對比，發(fā)現(xiàn)不一致，導(dǎo)致拋出UnsatisfiedDependencyException異常。
那么這里為什么spuCheckDomainServiceImpl調(diào)用initializeBean方法完成初始化后與提前暴露到二級緩存的bean會不一致呢？
看spuCheckDomainServiceImpl的代碼如下：
@Component
@Slf4j
@Validated
public class SpuCheckDomainServiceImpl {
@Resource
private NewSpuApplyCheckServiceImpl newSpuApplyCheckServiceImpl;
}發(fā)現(xiàn)SpuCheckDomainServiceImpl類有使用到@Validated注解。查閱資料發(fā)現(xiàn)@Validated的實現(xiàn)是通過在initializeBean方法里面執(zhí)行一個org.springframework.validation.beanvalidation.MethodValidationPostProcessor后置處理器實現(xiàn)的，MethodValidationPostProcessor會對SpuCheckDomainServiceImpl做一層代理。導(dǎo)致initializeBean方法返回的spuCheckDomainServiceImpl是一個新的代理對象，從而最終導(dǎo)致跟二級緩存的不一致。
debug視圖如下：
圖片
那為什么有時候能啟動成功呢？什么情況下能啟動成功？
我們繼續(xù)debug啟動成功的情況。最終觀察到spuCheckDomainServiceImpl只會調(diào)用一次doGetBean，而且從一二級緩存拿到的spuCheckDomainServiceImpl提前暴露的引用為null，如下圖：
圖片
這里為什么spuCheckDomainServiceImpl只會調(diào)用一次doGetBean呢？
首先我們根據(jù)調(diào)用棧整理到當(dāng)前加載的引用棧：
oldCenterSpuController-> newSpuApplyCheckServiceImpl-> ... ->spuCheckDomainServiceImpl -> newSpuApplyCheckServiceImpl根據(jù)前面啟動失敗的信息我們可以知道，spuCheckDomainServiceImpl處理依賴的環(huán)是：
spuCheckDomainServiceImpl ->newSpuApplyCommandServiceImpl-> ... ->spuCheckDomainServiceImpl失敗的情況我們發(fā)現(xiàn)是從spuCheckDomainServiceImpl開始創(chuàng)建的，現(xiàn)在啟動正常的情況是從newSpuApplyCheckServiceImpl開始創(chuàng)建的。
創(chuàng)建 newSpuApplyCheckServiceImpl時，發(fā)現(xiàn)它依賴環(huán)中間這些bean會依次調(diào)用doCreateBean方法去創(chuàng)建對應(yīng)的bean。
調(diào)用到spuCheckDomainServiceImpl時，由于是第一次獲取bean，也會調(diào)用doCreateBean方法創(chuàng)建bean，然后回到創(chuàng)建spuCheckDomainServiceImpl的doCreateBean流程，這里由于沒有將spuCheckDomainServiceImpl的三級緩存移到二級緩存，所以不會導(dǎo)致拋出UnsatisfiedDependencyException異常，最終回到newSpuApplyCheckServiceImpl的doCreateBean流程，由于newSpuApplyCheckServiceImpl在調(diào)用initializeBean方法沒有做代理增強(qiáng)，所以也不會導(dǎo)致拋出UnsatisfiedDependencyException異常。因此最后可以正常啟動。
這里我們會有疑問？類的創(chuàng)建順序由什么決定的呢？
通常不同環(huán)境下，代碼打包后的jar/war結(jié)構(gòu)、@ComponentScan的basePackages配置細(xì)微差別，都可能導(dǎo)致Spring掃描和注冊Bean定義的順序不同。Java ClassLoader加載類的順序本身也有一定不確定性。如果Bean定義是通過不同的配置類引入的，配置類的加載順序會影響其中所定義Bean的注冊順序。
那是不是所有的類增強(qiáng)在有循環(huán)依賴時都會觸發(fā)UnsatisfiedDependencyException異常呢？
并不是，比如@Transactional就不會導(dǎo)致觸發(fā)UnsatisfiedDependencyException異常。讓我們深入分析原因。
核心區(qū)別在于代理創(chuàng)建時機(jī)不同。
@Transactional的代理時機(jī)如下：
// Spring 為 @Transactional 創(chuàng)建代理的流程1. 實例化原始 Bean
2. 放入三級緩存（ObjectFactory）
3. 當(dāng)發(fā)生循環(huán)依賴時，調(diào)用 ObjectFactory.getObject()
4. 此時判斷是否需要事務(wù)代理，如果需要則提前創(chuàng)建代理
5. 將代理對象放入二級緩存，供其他 Bean 使用@Validated的代理時機(jī)：
// @Validated 的代理創(chuàng)建在生命周期更晚的階段1. 實例化原始 Bean
2. 放入三級緩存（ObjectFactory）
3. 當(dāng)發(fā)生循環(huán)依賴時，調(diào)用 ObjectFactory.getObject()
4. ? 問題：此時 @Validated 的代理還未創(chuàng)建！
5. 其他 Bean 拿到的是原始對象，而不是異步代理對象問題根源：@Transactional的代理增強(qiáng)是在三層緩存生成時觸發(fā)的， @Validated的增強(qiáng)是在初始化bean后通過后置處理器做的代理增強(qiáng)。
解決方案
短期方案
- 移除SpuCheckDomainServiceImpl類上的Validated注解
- @lazy 解耦
原理是發(fā)現(xiàn)有@lazy 注解的依賴為其生成代理類，依賴代理類，只有在真正需要用到對象時，再通過getBean的邏輯去獲取對象，從而實現(xiàn)了解耦。
長期方案
嚴(yán)格執(zhí)行DDD代碼規(guī)范
這里是違反DDD分層規(guī)范導(dǎo)致的循環(huán)依賴。
梳理解決歷史依賴環(huán)
通過梳理修改代碼解決歷史存在的依賴環(huán)。我們內(nèi)部實現(xiàn)了一個能檢測依賴環(huán)的工具，這里簡單介紹一下實現(xiàn)思路，詳情如下。
日常循環(huán)依賴環(huán)：實戰(zhàn)檢測工具類解析
在實際項目中，即使遵循了DDD分層規(guī)范和注入最佳實踐，仍有可能因業(yè)務(wù)復(fù)雜或團(tuán)隊協(xié)作不充分而引入循環(huán)依賴。為了在開發(fā)階段盡早發(fā)現(xiàn)這類問題，我們可以借助自定義的循環(huán)依賴檢測工具類，在Spring容器啟動后自動分析并報告依賴環(huán)。
功能概述：
- 條件啟用：通過配置circular.dependecy.analysis.enabled=true開啟檢測；
- 依賴圖構(gòu)建：掃描所有單例Bean，分析其構(gòu)造函數(shù)、字段、方法注入及depends-on聲明的依賴；
- 循環(huán)檢測算法：使用DFS遍歷依賴圖，識別所有循環(huán)依賴路徑；
- 通知上報：檢測結(jié)果通過飛書機(jī)器人發(fā)送至指定接收人（targetId）。
簡潔代碼結(jié)構(gòu)如下：
@Component
@ConditionalOnProperty(value = "circular.dependency.analysis.enabled", havingValue = "true")
public class TimingCircularDependencyHandler extends AbstractNotifyHandler<NotifyData>
implements ApplicationContextAware, BeanFactoryAware {
@Override
public Boolean handler(NotifyData data) {
dependencyGraph = new HashMap<>();
handleContextRefresh(); // 觸發(fā)依賴圖構(gòu)建與檢測
return Boolean.TRUE;
}
private void buildDependencyGraph() {
// 遍歷所有Bean，解析其依賴關(guān)系
// 支持：構(gòu)造器、字段、方法、depends-on
}
private void detectCircularDependencies() {
// 使用DFS檢測環(huán)，記錄所有循環(huán)路徑
// 輸出示例：循環(huán)依賴1: A -> B -> C -> A
}
}四、總結(jié)
循環(huán)依賴暴露了代碼結(jié)構(gòu)的設(shè)計缺陷。理論上應(yīng)通過分層和抽象來避免，但在復(fù)雜的業(yè)務(wù)交互中仍難以杜絕。雖然Spring利用三級緩存等機(jī)制默默解決了這一問題，使程序得以運(yùn)行，但這絕不應(yīng)是懈怠設(shè)計的借口。我們更應(yīng)恪守設(shè)計原則，從源頭規(guī)避循環(huán)依賴，構(gòu)建清晰、健康的架構(gòu)。
