从一次启动失败深入剖析：Spring 循环依赖的真相
一、背 景
预发环境一个后台服务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相关的流程。
- 深入解读这条复杂错误日志背后的每一个关键线索；
- 提供紧急止血方案；
- 分享如何从架构设计上避免此类问题的实践心得。
二、相关知识点简介
2.1 循环依赖
什么是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 更复杂，三级缓存无法完全解决。让我们深入分析原因。
2.2 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")指定的方法。
三、案例分析
3.1 代码分析
以下是我简化后的类之间大体的依赖关系，工程内实际的依赖情况会比这个简化版本复杂一些。
@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的角度来分析解释这个问题。
3.2 问题分析
在相关知识点简介里面知悉到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做代理增强的并且提前暴露到二级缓存的对象有被其他依赖引用到，而且allowRawInjectionDespiteWrapping=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后通过后置处理器做的代理增强。
3.3 解决方案
短期方案
- 移除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利用三级缓存等机制默默解决了这一问题，使程序得以运行，但这绝不应是懈怠设计的借口。我们更应恪守设计原则，从源头规避循环依赖，构建清晰、健康的架构。
往期回顾
1. Apex AI辅助编码助手的设计和实践｜得物技术
2. 从 JSON 字符串到 Java 对象：Fastjson 1.2.83 全程解析｜得物技术
3. 用好 TTL Agent 不踩雷：避开内存泄露与CPU 100%两大核心坑｜得物技术
4. 线程池ThreadPoolExecutor源码深度解析｜得物技术
5. 基于浏览器扩展 API Mock 工具开发探索｜得物技术
文 /鲁班
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
