從一次啟動失敗深入剖析：Spring循環依賴的真相
一、背景
二、相關知識點簡介
1. 循環依賴
2.Spring創建Bean主要流程
三、案例分析
1. 代碼分析
2. 問題分析
3. 解決方案
四、總結
一、背 景
預發環境一個后臺服務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.”這不僅僅是一個簡單的循環依賴錯誤。它揭示了一個更深層次的問題：當循環依賴遇上Spring的AOP代理（如@Transactional事務、自定義切面等），Spring在解決依賴的時，不得已將一個“半成品”（原始Bean）注入給了其他30多個Bean。而當這個“半成品”最終被“包裝”（代理）成“成品”時，先前那些持有“半成品”引用的Bean們，使用的卻是一個錯誤的版本。
這就像在組裝一個精密機器時，你把一個未經質檢的零件提前裝了進去，等質檢完成后，機器里混用著新舊版本的零件，最終的崩潰也就不可避免。
本篇文章將帶你一起：
- 熟悉spring容器的循環依賴以及Spring容器如何解決循環依賴，創建bean相關的流程。
- 深入解讀這條復雜錯誤日志背后的每一個關鍵線索；
- 提供緊急止血方案；
- 分享如何從架構設計上避免此類問題的實踐心得。
二、相關知識點簡介
循環依賴
什么是Bean循環依賴？
循環依賴：說白是一個或多個對象實例之間存在直接或間接的依賴關系，這種依賴關系構成了構成一個環形調用，主要有如下幾種情況。
第一種情況：自己依賴自己的直接依賴
圖片
第二種情況：兩個對象之間的直接依賴
圖片
前面兩種情況的直接循環依賴比較直觀，非常好識別，但是第三種間接循環依賴的情況有時候因為業務代碼調用層級很深，不容易識別出來。
循環依賴場景
構造器注入循環依賴：
@Service
public class A {public A(B b) {}}
@Service
public class B {public B(A a) {}}結果：項目啟動失敗拋出異常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)構造器注入構成的循環依賴，此種循環依賴方式無論是Singleton模式還是prototype模式都是無法解決的，只能拋出BeanCurrentlyInCreationException異常表示循環依賴。原因是Spring解決循環依賴依靠的是Bean的“中間態”這個概念，而中間態指的是已經實例化，但還沒初始化的狀態。而完成實例化需要調用構造器，所以構造器的循環依賴無法解決。
Singleton模式field屬性注入（setter方法注入）循環依賴：
這種方式是我們最為常用的依賴注入方式：
@Service
public class A {
@Autowired
private B b;
}
@Service
public class B {
@Autowired
private A a;
}結果：項目啟動成功，正常運行
prototype field屬性注入循環依賴：
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;
}結果：需要注意的是本例中啟動時是不會報錯的（因為非單例Bean默認不會初始化，而是使用時才會初始化），所以很簡單咱們只需要手動getBean()或者在一個單例Bean內@Autowired一下它即可。
// 在單例Bean內注入
@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)如何解決？可能有的小伙伴看到網上有說使用@Lazy注解解決：
@Lazy
@Autowired
private A a;此處負責任的告訴你這樣是解決不了問題的(可能會掩蓋問題)，@Lazy只是延遲初始化而已，當你真正使用到它（初始化）的時候，依舊會報如上異常。
對于Spring循環依賴的情況總結如下：
- 不能解決的情況：構造器注入循環依賴，prototype field屬性注入循環依賴
- 能解決的情況：field屬性注入（setter方法注入）循環依賴
Spring如何解決循環依賴
Spring 是通過三級緩存和提前曝光的機制來解決循環依賴的問題。
三級緩存
三級緩存其實就是用三個 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 對象（尚未填充屬性），用于解決循環依賴。
- singletonFactories：單例對象工廠的cache，存放 bean 工廠對象，用于解決循環依賴。
三級緩存解決循環依賴過程
假設現在我們有ServiceA和ServiceB兩個類，這兩個類相互依賴，代碼如下：
@Service
public class ServiceA {
@Autowired
private ServiceB serviceB;
}
@Service
public class ServiceB {
@Autowired
private ServiceA serviceA ;
}下面的時序圖說明了spring用三級緩存解決循環依賴的主要流程：
圖片
為什么需要三級緩存？
這是一個理解Spring容器如何解決循環依賴的核心概念。三級緩存是Spring為了解決循環依賴的同時，又能保證AOP代理的正確性而設計的精妙機制。
為了理解為什么需要三級緩存，我們一步步來看。
如果沒有緩存（Level 0）
假設有兩個Bean：ServiceA 和 ServiceB，它們相互依賴。
Java
@Component
public class ServiceA {
@Autowired
private ServiceB serviceB;
}
@Component
public class ServiceB {
@Autowired
private ServiceA serviceA;
}創建過程（無緩存）：
- 開始創建 ServiceA -> 發現 ServiceA 需要 ServiceB -> 開始創建 ServiceB
- 開始創建 ServiceB -> 發現 ServiceB 需要 ServiceA -> 開始創建 ServiceA
- 開始創建 ServiceA -> 發現 ServiceA 需要 ServiceB -> ... 無限循環，StackOverflowError
結論：無法解決循環依賴，直接死循環。
如果只有一級緩存（Singleton Objects）
一級緩存存放的是已經完全創建好、初始化完畢的Bean。
問題：在Bean的創建過程中（比如在填充屬性 populateBean 時），ServiceA還沒創建完，它本身不應該被放入"已完成"的一級緩存。但如果ServiceB需要ServiceA，而一級緩存里又沒有ServiceA的半成品，ServiceB就無法完成創建。這就回到了上面的死循環問題。
結論：一級緩存無法解決循環依賴。
如果使用二級緩存
二級緩存的核心思路是：將尚未完全初始化好的“早期引用”暴露出來。
現在我們有：
- 一級緩存（成品庫）：存放完全準備好的Bean。
- 二級緩存（半成品庫）：存放剛剛實例化（調用了構造方法），但還未填充屬性和初始化的Bean的早期引用。
創建過程（二級緩存）：
開始創建ServiceA：
- 實例化ServiceA（調用ServiceA的構造方法），得到一個ServiceA的原始對象。
- 將ServiceA的原始對象放入二級緩存（半成品庫）。
- 開始為ServiceA填充屬性 -> 發現需要ServiceB。
開始創建ServiceB：
- 實例化ServiceB（調用B的構造方法），得到一個ServiceB的原始對象。
- 將ServiceB的原始對象放入二級緩存。
- 開始為ServiceB填充屬性 -> 發現需要ServiceA。
ServiceB從二級緩存中獲取A：
- ServiceB成功從二級緩存中拿到了ServiceA的早期引用（原始對象）。
- ServiceB順利完成了屬性填充、初始化等后續步驟，成為一個完整的Bean。
- 將完整的ServiceB放入一級緩存（成品庫），并從二級緩存移除ServiceB。
ServiceA繼續創建：
- ServiceA拿到了創建好的ServiceB，完成了自己的屬性填充和初始化。
- 將完整的ServiceA放入一級緩存（成品庫），并從二級緩存移除ServiceA。
問題來了：如果ServiceA需要被AOP代理怎么辦？
如果A類上加了 @Transactional 等需要創建代理的注解，那么最終需要暴露給其他Bean的應該是ServiceA的代理對象，而不是ServiceA的原始對象。
在二級緩存方案中，ServiceB拿到的是A的原始對象。但最終ServiceA完成后，放入一級緩存的是ServiceA的代理對象。這就導致了：
- ServiceB里面持有的ServiceA是原始對象。
- 而其他地方注入的ServiceA是代理對象。
- 這就造成了不一致！如果通過ServiceB的ServiceA去調用事務方法，事務會失效，因為那是一個沒有被代理的原始對象。
結論：二級緩存可以解決循環依賴問題，但無法正確處理需要AOP代理的Bean。
三級緩存的登場（Spring的終極方案）
為了解決代理問題，Spring引入了第三級緩存。它的核心不是一個直接存放對象（Object）的緩存，而是一個存放 ObjectFactory（對象工廠）的緩存。
三級緩存的結構是：Map<String, ObjectFactory<?>> singletonFactories
創建過程（三級緩存，以ServiceA需要代理為例）：
- 開始創建ServiceA：
- 實例化ServiceA，得到ServiceA的原始對象。
- 向三級緩存添加一個ObjectFactory。這個工廠的getObject()方法有能力判斷ServiceA是否需要代理，并返回相應的對象（原始對象或代理對象）。
- 開始為ServiceA填充屬性 -> 發現需要ServiceB。
- 開始創建B：
- 實例化ServiceB。
- 同樣向三級緩存添加一個ServiceB的ObjectFactory。
- 開始為ServiceB填充屬性 -> 發現需要ServiceA。
- ServiceB從緩存中獲取ServiceA：
- ServiceB發現一級緩存沒有ServiceA，二級緩存也沒有ServiceA。
- ServiceB發現三級緩存有A的ObjectFactory。
- B調用這個工廠的getObject()方法。此時，Spring會執行一個關鍵邏輯：
如果ServiceA需要被代理，工廠會提前生成ServiceA的代理對象并返回。
如果ServiceA不需要代理，工廠則返回A的原始對象。
- 將這個早期引用（可能是原始對象，也可能是代理對象）放入二級緩存，同時從三級緩存移除A的工廠。
- ServiceB拿到了ServiceA的正確版本的早期引用。
后續步驟：
- ServiceB完成創建，放入一級緩存。
- ServiceA繼續用ServiceB完成創建。在ServiceA初始化的最后，Spring會再次檢查：如果ServiceA已經被提前代理了（即在第3步中），那么就直接返回這個代理對象；如果沒有，則可能在此處創建代理（對于不需要解決循環依賴的Bean）。
- 最終，將完整的ServiceA（代理對象）放入一級緩存，并清理二級緩存。
總結：為什么需要三級緩存？
需要三級緩存，是因為Spring要解決一個復雜問題：在存在循環依賴的情況下，如何確保所有Bean都能拿到最終形態（可能被AOP代理）的依賴對象，而不是原始的、未代理的對象。 三級緩存通過一個ObjectFactory將代理的時機提前，完美地解決了這個問題。二級緩存主要是為了性能優化而存在的。
spring三級緩存為什么不能解決
@Async注解的循環依賴問題
這觸及了 Spring 代理機制的一個深層次區別。@Async注解的循環依賴問題確實比@Transactional 更復雜，三級緩存無法完全解決。讓我們深入分析原因。
Spring創建Bean主要流程
為了容易理解 Spring 解決循環依賴過程，我們先簡單溫習下 Spring 容器創建 Bean 的主要流程。
從代碼看Spring對于Bean的生成過程，步驟還是很多的，我把一些擴展業務代碼省略掉：
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
throws BeanCreationException {
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
// Bean初始化第一步：默認調用無參構造實例化Bean
// 如果是只有帶參數的構造方法，構造方法里的參數依賴注入，就是發生在這一步
if (instanceWrapper == null) {
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
//判斷Bean是否需要提前暴露對象用來解決循環依賴，需要則啟動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創建第二步：填充屬性（DI依賴注入發生在此步驟）
populateBean(beanName, mbd, instanceWrapper);
// bean創建第三步：調用初始化方法，完成bean的初始化操作（AOP的第三個入口）
// AOP是通過自動代理創建器AbstractAutoProxyCreator的postProcessAfterInitialization()
//方法的執行進行代理對象的創建的,AbstractAutoProxyCreator是BeanPostProcessor接口的實現
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;
}從上述代碼看出，整體脈絡可以歸納成 3 個核心步驟：
- 實例化Bean：主要是通過反射調用默認構造函數創建 Bean 實例，此時Bean的屬性都還是默認值null。被注解@Bean標記的方法就是此階段被調用的。
- 填充Bean屬性：這一步主要是對Bean的依賴屬性進行填充，對@Value、@Autowired、@Resource注解標注的屬性注入對象引用。
- 調用Bean初始化方法：調用配置指定中的init方法，如 xml文件指定Bean的init-method方法或注解 @Bean(initMethod = "initMethod")指定的方法。
三、案例分析
代碼分析
以下是我簡化后的類之間大體的依賴關系，工程內實際的依賴情況會比這個簡化版本復雜一些。
@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 構成了一個依賴環。而我們從正常啟動的bean加載順序發現首先是從OldCenterSpuController開始加載的，具體情況如下所示：
OldCenterSpuController
↓ (依賴)
NewSpuApplyCheckServiceImpl
↓ (依賴)
SpuCheckDomainServiceImpl
↓ (依賴)
NewSpuApplyCheckServiceImpl異常啟動的情況bean加載是從TimeoutNotifyController開始加載的，具體情況如下所示：
TimeoutNotifyController
↓ (依賴)
SpuCheckDomainServiceImpl
↓ (依賴)
NewSpuApplyCheckServiceImpl
↓ (依賴)
SpuCheckDomainServiceImpl同一個依賴環，為什么從OldCenterSpuController 開始加載就可以正常啟動，而從TimeoutNotifyController 啟動就會啟動異常呢？下面我們會從現場debug的角度來分析解釋這個問題。
問題分析
在相關知識點簡介里面知悉到spring用三級緩存解決了循環依賴問題。為什么后臺服務admin啟動還會報循環依賴的問題呢？
要得到問題的答案，還是需要回到源碼本身，前面我們分析了spring的創建Bean的主要流程，這里為了更好的分析問題，補充下通過容器獲取Bean的。
在通過spring容器獲取bean時，底層統一會調用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，則執行創建bean邏輯
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
}從doGetBean方法邏輯看，在spring從一二三級緩存獲取bean返回空時，會調用createBean方法去場景bean，createBean方法底層主要是調用前面我們提到的創建Bean流程的doCreateBean方法。
注意：doGetBean方法里面getSingleton方法的邏輯是先從一級緩存拿，拿到為空并且bean在創建中則又從二級緩存拿，二級緩存拿到為空 并且當前容器允許有循環依賴則從三級緩存拿。并且將對象工廠移到二級緩存，刪除三級緩存
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初始化第一步：默認調用無參構造實例化Bean
// 如果是只有帶參數的構造方法，構造方法里的參數依賴注入，就是發生在這一步
if (instanceWrapper == null) {
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
//判斷Bean是否需要提前暴露對象用來解決循環依賴，需要則啟動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創建第二步：填充屬性（DI依賴注入發生在此步驟）
populateBean(beanName, mbd, instanceWrapper);
// bean創建第三步：調用初始化方法，完成bean的初始化操作（AOP的第三個入口）
// AOP是通過自動代理創建器AbstractAutoProxyCreator的postProcessAfterInitialization()
//方法的執行進行代理對象的創建的,AbstractAutoProxyCreator是BeanPostProcessor接口的實現
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的邏輯轉換成流程圖如下：
圖片
從流程圖可以看出，后臺服務admin啟動失敗拋出UnsatisfiedDependencyException異常的必要條件是存在循環依賴，因為不存在循環依賴的情況bean只會存在單次加載，單次加載的情況bean只會被放進spring的第三級緩存。
而觸發UnsatisfiedDependencyException異常的先決條件是需要spring的第一二級緩存有當前的bean。所以可以知道當前bean肯定存在循環依賴。在存在循環依賴的情況下，當前bean被第一次獲取（即調用doGetBean方法）會緩存進spring的第三級緩存，然后會注入當前bean的依賴（即調用populateBean方法），在當前bean所在依賴環內其他bean都不在一二級緩存的情況下，會觸發當前bean的第二次獲取（即調用doGetBean方法），由于第一次獲取已經將Bean放進了第三級緩存，spring會將Bean從第三級緩存移到二級緩存并刪除第三級緩存。
最終會回到第一次獲取的流程，調用初始化方法做初始化。最終在初始化有對當前bean做代理增強的并且提前暴露到二級緩存的對象有被其他依賴引用到，而且allowRawInjectinotallow=false的情況下，會導致拋出UnsatisfiedDependencyException，進而導致啟動異常。
注意：在注入當前bean的依賴時，這里spring將Bean從第三級緩存移到二級緩存并刪除第三級緩存后，當前bean的依賴的其他bean會從二級緩存拿到當前bean做依賴。這也是后續拋異常的先決條件
結合admin有時候啟動正常，有時候啟動異常的情況，這里猜測啟動正常和啟動異常時bean加載順序不一致，進而導致啟動正常時當前Bean只會被獲取一次，啟動異常時當前bean會被獲取兩次。為了驗證猜想，我們分別針對啟動異常和啟動正常的bean獲取做了debug。
debug分析
首先我們從啟動異常提取到以下關鍵信息，從這些信息可以知道是spuCheckDomainServiceImpl的加載觸發的啟動異常。所以我們這里以spuCheckDomainServiceImpl作為前面流程分析的當前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方法設置好spuCheckDomainServiceImpl加載時的條件斷點。我們先debug啟動異常的情況。最終斷點信息如下：
圖片
從紅框1里面的兩個引用看，很明顯調initializeBean方法時spring有對spuCheckDomainServiceImpl做代理增強。導致initializeBean后返回的引用和提前暴露到二級緩存的引用是不一致的。這里spuCheckDomainServiceImpl有二級緩存是跟我們前面分析的吻合，是因為spuCheckDomainServiceImpl被獲取了兩次，即調了兩次doGetBean。
從紅框2里面的actualDependentBeans的set集合知道提前暴露到二級緩存的引用有被其他33個bean引用到，也是跟異常提示的bean列表保持一致的。
這里spuCheckDomainServiceImpl的加載為什么會調用兩次doGetBean方法呢？
從調用棧分析到該加載鏈如下：
TimeoutNotifyController ->spuCheckDomainServiceImpl-> newSpuApplyCheckServiceImpl-> ... ->spuCheckDomainServiceImplTimeoutNotifyController注入依賴時第一次調用doGetBean獲取spuCheckDomainServiceImpl時，從一二三級緩存獲取不到，會調用doCreateBean方法創建spuCheckDomainServiceImpl。
首先會將spuDomainServiceImpl放進spring的第三級緩存，然后開始調populateBean方法注入依賴，由于在循環中間的newSpuApplyCheckServiceImpl是第一次獲取，一二三級緩存都獲取不到，會調用doCreateBean去創建對應的bean，然后會第二次調用doGetBean獲取spuCheckDomainServiceImpl，這時spuCheckDomainServiceImpl在第一次獲取已經將bean加載到第三級緩存，所以這次spring會將bean從第三級緩存直接移到第二級緩存，并將第三級緩存里面的spuCheckDomainServiceImpl對應的bean刪除，并直接返回二級緩存里面的bean，不會再調doCreateBean去創建spuCheckDomainServiceImpl。最終完成了循環中間的bean的初始化后（這里循環中間的bean初始化時依賴到的bean如果有引用到spuCheckDomainServiceImpl會調用doGetBean方法從二級緩存拿到spuCheckDomainServiceImpl提前暴露的引用），會回到第一次調用doGetBean獲取spuCheckDomainServiceImpl時調用的doCreateBean方法的流程。繼續調initializeBean方法完成初始化，然后將初始化完成的bean返回。最終拿初始化返回的bean引用跟二級緩存拿到的bean引用做對比，發現不一致，導致拋出UnsatisfiedDependencyException異常。
那么這里為什么spuCheckDomainServiceImpl調用initializeBean方法完成初始化后與提前暴露到二級緩存的bean會不一致呢？
看spuCheckDomainServiceImpl的代碼如下：
@Component
@Slf4j
@Validated
public class SpuCheckDomainServiceImpl {
@Resource
private NewSpuApplyCheckServiceImpl newSpuApplyCheckServiceImpl;
}發現SpuCheckDomainServiceImpl類有使用到@Validated注解。查閱資料發現@Validated的實現是通過在initializeBean方法里面執行一個org.springframework.validation.beanvalidation.MethodValidationPostProcessor后置處理器實現的，MethodValidationPostProcessor會對SpuCheckDomainServiceImpl做一層代理。導致initializeBean方法返回的spuCheckDomainServiceImpl是一個新的代理對象，從而最終導致跟二級緩存的不一致。
debug視圖如下：
圖片
那為什么有時候能啟動成功呢？什么情況下能啟動成功？
我們繼續debug啟動成功的情況。最終觀察到spuCheckDomainServiceImpl只會調用一次doGetBean，而且從一二級緩存拿到的spuCheckDomainServiceImpl提前暴露的引用為null，如下圖：
圖片
這里為什么spuCheckDomainServiceImpl只會調用一次doGetBean呢？
首先我們根據調用棧整理到當前加載的引用棧：
oldCenterSpuController-> newSpuApplyCheckServiceImpl-> ... ->spuCheckDomainServiceImpl -> newSpuApplyCheckServiceImpl根據前面啟動失敗的信息我們可以知道，spuCheckDomainServiceImpl處理依賴的環是：
spuCheckDomainServiceImpl ->newSpuApplyCommandServiceImpl-> ... ->spuCheckDomainServiceImpl失敗的情況我們發現是從spuCheckDomainServiceImpl開始創建的，現在啟動正常的情況是從newSpuApplyCheckServiceImpl開始創建的。
創建 newSpuApplyCheckServiceImpl時，發現它依賴環中間這些bean會依次調用doCreateBean方法去創建對應的bean。
調用到spuCheckDomainServiceImpl時，由于是第一次獲取bean，也會調用doCreateBean方法創建bean，然后回到創建spuCheckDomainServiceImpl的doCreateBean流程，這里由于沒有將spuCheckDomainServiceImpl的三級緩存移到二級緩存，所以不會導致拋出UnsatisfiedDependencyException異常，最終回到newSpuApplyCheckServiceImpl的doCreateBean流程，由于newSpuApplyCheckServiceImpl在調用initializeBean方法沒有做代理增強，所以也不會導致拋出UnsatisfiedDependencyException異常。因此最后可以正常啟動。
這里我們會有疑問？類的創建順序由什么決定的呢？
通常不同環境下，代碼打包后的jar/war結構、@ComponentScan的basePackages配置細微差別，都可能導致Spring掃描和注冊Bean定義的順序不同。Java ClassLoader加載類的順序本身也有一定不確定性。如果Bean定義是通過不同的配置類引入的，配置類的加載順序會影響其中所定義Bean的注冊順序。
那是不是所有的類增強在有循環依賴時都會觸發UnsatisfiedDependencyException異常呢？
并不是，比如@Transactional就不會導致觸發UnsatisfiedDependencyException異常。讓我們深入分析原因。
核心區別在于代理創建時機不同。
@Transactional的代理時機如下：
// Spring 為 @Transactional 創建代理的流程1. 實例化原始 Bean
2. 放入三級緩存（ObjectFactory）
3. 當發生循環依賴時，調用 ObjectFactory.getObject()
4. 此時判斷是否需要事務代理，如果需要則提前創建代理
5. 將代理對象放入二級緩存，供其他 Bean 使用@Validated的代理時機：
// @Validated 的代理創建在生命周期更晚的階段1. 實例化原始 Bean
2. 放入三級緩存（ObjectFactory）
3. 當發生循環依賴時，調用 ObjectFactory.getObject()
4. ? 問題：此時 @Validated 的代理還未創建！
5. 其他 Bean 拿到的是原始對象，而不是異步代理對象問題根源：@Transactional的代理增強是在三層緩存生成時觸發的， @Validated的增強是在初始化bean后通過后置處理器做的代理增強。
解決方案
短期方案
- 移除SpuCheckDomainServiceImpl類上的Validated注解
- @lazy 解耦
原理是發現有@lazy 注解的依賴為其生成代理類，依賴代理類，只有在真正需要用到對象時，再通過getBean的邏輯去獲取對象，從而實現了解耦。
長期方案
嚴格執行DDD代碼規范
這里是違反DDD分層規范導致的循環依賴。
梳理解決歷史依賴環
通過梳理修改代碼解決歷史存在的依賴環。我們內部實現了一個能檢測依賴環的工具，這里簡單介紹一下實現思路，詳情如下。
日常循環依賴環：實戰檢測工具類解析
在實際項目中，即使遵循了DDD分層規范和注入最佳實踐，仍有可能因業務復雜或團隊協作不充分而引入循環依賴。為了在開發階段盡早發現這類問題，我們可以借助自定義的循環依賴檢測工具類，在Spring容器啟動后自動分析并報告依賴環。
功能概述：
- 條件啟用：通過配置circular.dependecy.analysis.enabled=true開啟檢測；
- 依賴圖構建：掃描所有單例Bean，分析其構造函數、字段、方法注入及depends-on聲明的依賴；
- 循環檢測算法：使用DFS遍歷依賴圖，識別所有循環依賴路徑；
- 通知上報：檢測結果通過飛書機器人發送至指定接收人（targetId）。
簡潔代碼結構如下：
@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(); // 觸發依賴圖構建與檢測
return Boolean.TRUE;
}
private void buildDependencyGraph() {
// 遍歷所有Bean，解析其依賴關系
// 支持：構造器、字段、方法、depends-on
}
private void detectCircularDependencies() {
// 使用DFS檢測環，記錄所有循環路徑
// 輸出示例：循環依賴1: A -> B -> C -> A
}
}四、總結
循環依賴暴露了代碼結構的設計缺陷。理論上應通過分層和抽象來避免，但在復雜的業務交互中仍難以杜絕。雖然Spring利用三級緩存等機制默默解決了這一問題，使程序得以運行，但這絕不應是懈怠設計的借口。我們更應恪守設計原則，從源頭規避循環依賴，構建清晰、健康的架構。
