作者|光旦导语：本文主要梳理了Spring解决bean循环依赖的思路。
一 背景
有好几次线上发布老应用时，遭遇代码启动报错，具体错误如下：
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'xxxManageFacadeImpl': Bean with name 'xxxManageFacadeImpl' has been injected into other beans [xxxProductMaintenceFacadeImpl] in its raw version as part of a circular reference, but has eventually been wrap means thff, for expped. 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 'getBeanNamesallowEageOfType' with the 'allowEagerInit' flag turned off, for example
眨眼一看，这不就是Spring Bean循环依赖报错吗？脑海立马闪过那些年为了进阿里面试时被死亡N连问的场景，那时我们都知道Spring已经支持bean循环依赖，为啥我们的Springboot应用启动时还报这个错误？带着这个问题于是要重新温习下Spring如何解决bean循环依赖。
二 相关知识点简介
2.1 什么是Bean循环依赖?
循环依赖是指Bean对象循环引用,是两个或多个Bean之间相互持有对方的引用。循环依赖有2种表现形式：
第一种是相互依赖，也就是A依赖B，B又依赖A;
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); } // 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); } catch (Throwable ex) { // ... } // ...
从上述代码看出，整体脉络可以归纳成3个核心步骤：
1. 实例化Bean
主要是通过反射调用默认构造函数创建Bean实例，此时bean的属性都还是默认值null。被注解@Bean标注的方法就是此阶段被调用的。
2. 填充Bean属性
这一步主要是对bean的依赖属性进行填充,对@Value @Autowired @Resource注解标注的属性注入对象引用。
3. 调用Bean初始化方法
调用配置指定中的init 方法，如xml文件指定bean的init-method方法或注解@Bean(initMethod = "initMethod")指定的方法。
2.3 Bean创建过程BeanPostProcessor接口拓展点
在Bean创建的流程中Spring提供了多个BeanPostProcessor接口（下称BPP）方便开发者对Bean进行自定义调整和加工。有以下几种BPP接口比较常用：
postProcessMergedBeanDefinition：可对BeanDefinition添加额外的自定义配置
getEarlyBeanReference：返回早期暴露的bean引用，一个典型的例子是循环依赖时如果有动态代理，需要在此先返回代理实例
postProcessAfterInstantiation：在populateBean前用户可以手动注入一些属性
postProcessProperties：对属性进行注入，例如配置文件加密信息在此解密后注入
postProcessBeforeInitialization：属性注入后的一些额外操作
postProcessAfterInitialization：实例完成创建的最后一步，这里也是一些BPP进行AOP代理的时机.
最后，对bean的生命流程进行一个流程图的总结
图三 bean的生命流程图此处敲黑板划重点：Spring的动态代理（AOP）是通过BPP实现的（在图三中的3.4步实现），其中AbstractAutoProxyCreator是十分典型的自动代理类，它实现了SmartInstantiationAwareBeanPostProcessor接口，并重写了getEarlyBeanReference和postProcessAfterInitialization两个方法实现代理的逻辑，这样完成对原始Bean进行增强，生成新Bean对象，将增强后的新Bean对象注入到属性依赖中。
三 Spring如何解决循环依赖？
先说结论，Spring是通过三级缓存和提前曝光的机制来解决循环依赖的问题。
3.1 三级缓存作用
三级缓存其实就是用三个Map来存储不同阶段Bean对象。
一级缓存 singletonObjects: 主要存放的是已经完成实例化、属性填充和初始化所有步骤的单例Bean实例，这样的Bean能够直接提供给用户使用，我们称之为终态Bean或叫成熟Bean。
二级缓存 earlySingletonObjects: 主要存放的已经完成初始化但属性还没自动赋值的Bean，这些Bean还不能提供用户使用，只是用于提前暴露的Bean实例，我们把这样的Bean称之为临时Bean或早期的Bean（半成品Bean）
三级缓存 singletonFactories: 存放的是ObjectFactory的匿名内部类实例，调用ObjectFactory.getObject()最终会调用getEarlyBeanReference方法，该方法可以获取提前暴露的单例bean引用。
3.2 三级缓存解决循环依赖过程
现在通过源码分析，深入理解下Spring如何运用三级缓存解决循环依赖。Spring创建Bean的核心代码doGetBean中，在实例化bean之前，会先尝试从三级缓存获取bean，这也是Spring解决循环依赖的开始。
我们假设现在有这样的场景AService依赖BService，BService依赖AService
一开始加载AService Bean首先依次从一二三级缓存中查找是否存在beanName=AService的对象。
// AbstractBeanFactory.java protected
T doGetBean(final String name, @Nullable final Class
requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException { final String beanName = transformedBeanName(name); // 1.尝试从缓存中获取bean，AService还没创建三级缓存都没命中 Object sharedInstance = getSingleton(beanName); if (mbd.isSingleton()) { sharedInstance = getSingleton(beanName, () -> { //注意此处参数是一个lambda表达式即参数传入的是ObjectFactory类型一个匿名内部类对象 try { return createBean(beanName, mbd, args); // } catch (BeansException ex) {} }); beanInstance = getObjectForBeanInstance(sharedInstance, name, beanName, mbd); } }
因为AService还没创建三级缓存都没命中于是走到创建Bean代码逻辑。调用方法getSingleton(String beanName，ObjectFactory objectFactory)方法，第二个参数传入一个ObjectFactory接口的匿名内部类实例。
public Object getSingleton(String beanName, ObjectFactory singletonFactory) {//将当前beanName放到singletonsCurrentlyInCreation 集合中，标识该bean正在创建 beforeSingletonCreation(beanName); //通过回调getObject()方法触发AbstractAutowireCapableBeanFactory#createBean(String beanName, RootBeanDefinition mbd, Object[] args)的执行 singletonObject = singletonFactory.getObject(); afterSingletonCreation(beanName); addSingleton(beanName, singletonObject);}
该方法主要做四件事情：
将当前beanName放到singletonsCurrentlyInCreation集合中标识该bean正在创建；
调用匿名内部类实例对象的getObject()方法触发AbstractAutowireCapableBeanFactory#createBean方法的执行；
将当前beanName从singletonsCurrentlyInCreation集合中移除；
singletonFactory.getObject()方法触发回调AbstractAutowireCapableBeanFactory#createBean(String beanName, RootBeanDefinition mbd, Object[] args)的执行，走真正创建AService Bean流程。
//真正创建Bean的地方 AbstractAutowireCapableBeanFactory#doCreateBean protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException { // Instantiate the bean. BeanWrapper instanceWrapper = null; if (mbd.isSingleton()) { instanceWrapper = this.factoryBeanInstanceCache.remove(beanName); } // bean初始化第一步：默认调用无参构造实例化Bean // 构造参数依赖注入，就是发生在这一步 if (instanceWrapper == null) { instanceWrapper = createBeanInstance(beanName, mbd, args); } // 实例化后的Bean对象 final Object bean = instanceWrapper.getWrappedInstance(); // 将刚创建的bean放入三级缓存中singleFactories(key是beanName，value是ObjectFactory) //注意此处参数又是一个lambda表达式即参数传入的是ObjectFactory类型一个匿名内部类对象，在后续再缓存中查找Bean时会触发匿名内部类getEarlyBeanReference()方法回调 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); } catch (Throwable ex) { // ... } }
在上面创建AService Bean代码流程可以看出，AService实例化后调用addSingletonFactory(String beanName, ObjectFactory singletonFactory) 方法将以Key为AService，value是ObjectFactory类型一个匿名内部类对象放入三级缓存中，在后续使用AService时会依次在一二三级缓存中查找，最终三级缓存中查到这个匿名内部类对象，从而触发匿名内部类中getEarlyBeanReference()方法回调。
此处为什么不是AService实例直接放入三级缓存呢？因为我们上面说了AOP增强逻辑是在创建Bean第三步：调用初始化方法之后进行的，AOP增强后生成的新代理类AServiceProxy实例对象，假如此时直接把AService实例直接放入三级缓存，那么在对BService Bean依赖的aService属性赋值的就是AService实例，而不是增强后的AServiceProxy实例对象。
在以Key为AService，value为ObjectFactory类型一个匿名内部类对象放入三级缓存后，继续对AService进行属性填充（依赖注入），这时发现AService依赖BService。
于是又依次从一二三级缓存中查询BService Bean，没找到，于是又按照上述的流程实例化BService，将以Key为BService，value是ObjectFactory类型一个匿名内部类对象放入三级缓存中，继续对BService进行属性填充（依赖注入），这时发现BService又依赖AService。于是依次在一二三级缓存中查找AService。
//DefaultSingletonBeanRegistry.javapublic Object getSingleton(String beanName) { return getSingleton(beanName, true);}protected Object getSingleton(String beanName, boolean allowEarlyReference) { // 从一级缓存获取，key=AService Object singletonObject = this.singletonObjects.get(beanName); if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { synchronized (this.singletonObjects) { // 从二级缓存获取，key=AService singletonObject = this.earlySingletonObjects.get(beanName); // 是否允许循环引用 if (singletonObject == null && allowEarlyReference) { // 前面已经将以Key为AService，value是ObjectFactory类型一个匿名内部类对象放入三级缓存了 ObjectFactory> singletonFactory = this.singletonFactories.get(beanName); if (singletonFactory != null) { //singletonFactory是一个匿名内部类对象，此处触发匿名内部类中getEarlyBeanReference()方法回调。 singletonObject = singletonFactory.getObject(); // 将三级缓存生产的bean放入二级缓存中 this.earlySingletonObjects.put(beanName, singletonObject); // 删除三级缓存 this.singletonFactories.remove(beanName); } } } } return singletonObject; }
最终三级缓存中查到之前放入的以Key为AService，value为ObjectFactory类型一个匿名内部类对象，从而触发匿名内部类getEarlyBeanReference()方法回调。getEarlyBeanReference()方法决定返回AService实例到底是AService实例本身还是被AOP增强后的AServiceProxy实例对象。如果没AOP切面对AService进行拦截，这时返回的将是AService实例本身。接着将半成品AService Bean放入二级缓存并将Key为AService从三级缓存中删除，这样实现了提前将AService Bean曝光给BService完成属性依赖注入。继续走BService后续初始化逻辑，最后生产了成熟的BService Bean实例。
接着原路返回，AService也成功获取到依赖BService实例，完成后续的初始化工作，然后完美的解决了循环依赖的问题。
最后，来一张解决AService依赖BService，BService又依赖AService这样循环依赖的流程图对上述Spring代码逻辑进行总结。
图四 没有AOP的Bean循环依赖解决的流程图3.3 当AOP遇到循环依赖
从2.3、Bean创建过程BeanPostProcessor接口拓展点小节，我们知道Bean的AOP动态代理创建时在初始化之后通过回调postProcessAfterInitialization后置处理器进行的，但是出现循环依赖的Bean如果使用了AOP， 那就需要在getEarlyBeanReference()方法创建动态代理，将生成的代理Bean放在二级缓存提前曝光出来， 这样BService的属性aService注入的就是被代理后的AServiceProxy实例对象。
下面以AService依赖BService，BService依赖AService，AService被AOP切面拦截的场景进行代码分析循环依赖的Bean使用了AOP如何在getEarlyBeanReference()方法如何提前创建动态代理Bean。
// 将Aservice添加三级缓存addSingletonFactory(beanName,()->getEarlyBeanReference(beanName,mbd,bean));// 添加Bservice的aService属性时从三级中找Aservice的ObjectFactory类型一个匿名内部类对象，从而触发匿名内部类getEarlyBeanReference()方法回调，进入创建AService切面代理对象逻辑protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) { Object exposedObject = bean; if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { //判断后置处理器是否实现了SmartInstantiationAwareBeanPostProcessor接口 //调用SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) { exposedObject = bp.getEarlyBeanReference(exposedObject, beanName); } } return exposedObject;}
可以看出getEarlyBeanReference()方法判断后置处理器是否实现了SmartInstantiationAwareBeanPostProcessor后置处理器接口。
而我们演示代码通过@EnableAspectJAutoProxy注解导入的AOP核心业务处理AnnotationAwareAspectJAutoProxyCreator类，它继承了AbstractAutoProxyCreator了，在AbstractAutoProxyCreator类中实现了getEarlyBeanReference()方法。
//真正实现了该方法的类就是AbstractAutoProxyCreatorpublic abstract class AbstractAutoProxyCreator extends ProxyProcessorSupport implements SmartInstantiationAwareBeanPostProcessor, BeanFactoryAware { @Override public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { // 先获取beanName,主要是为FactoryBean类型添加&前缀 Object cacheKey = getCacheKey(bean.getClass(), beanName); // 判断是否已经在earlyProxyReferences集合中，不在则添加进去 if (!this.earlyProxyReferences.contains(cacheKey)) { this.earlyProxyReferences.add(cacheKey); } // 创建代理对象，如果必要的话 return wrapIfNecessary(bean, beanName, cacheKey); } /** * Wrap the given bean if necessary, i.e. if it is eligible for being proxied. * @param bean the raw bean instance * @param beanName the name of the bean * @param cacheKey the cache key for metadata access * @return a proxy wrapping the bean, or the raw bean instance as-is */ protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) { // 前面先做一些基本的判断 if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) { return bean; } if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) { return bean; } // Advice/Pointcut/Advisor/AopInfrastructureBean接口的beanClass不进行代理以及对beanName为aop内的切面名也不进行代理 // 此处可查看子类复写的shouldSkip()方法 if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) { this.advisedBeans.put(cacheKey, Boolean.FALSE); return bean; } // Create proxy if we have advice. // 查找对代理类相关的advisor对象集合，此处就与point-cut表达式有关了 Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null); // 对相应的advisor不为空才采取代理 if (specificInterceptors != DO_NOT_PROXY) { this.advisedBeans.put(cacheKey, Boolean.TRUE); // 通过jdk动态代理或者cglib动态代理，产生代理对象,这里传入的是SingletonTargetSource对象喔，对原始bean对象进行了包装 Object proxy = createProxy( bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean)); // 放入代理类型缓存 this.proxyTypes.put(cacheKey, proxy.getClass()); return proxy; } // 放入通知缓存 this.advisedBeans.put(cacheKey, Boolean.FALSE); return bean; }}
wrapIfNecessary 方法查找AService是否查找存在的advisor对象集合，此处就与point-cut表达式有关了，显然我们的切点 @Around("execution(* com.example.service.AService.helloA(..))")拦截了AService，因此需要创建AService的代理Bean。通过jdk动态代理或者cglib动态代理，产生代理对象,对原始AService对象进行了包装最后返回的是 AService的代理对象aServiceProxy，然后把 aServiceProxy 放入二级缓存里面，并删除三级缓存中的 AService的ObjectFactory。这样实现了提前为AService生成动态对象aServiceProxy并赋值给BService的aService属性依赖注入。这样BService完成了属性依赖注入，继续走BService后续初始化逻辑，最后生产了成熟的BService Bean实例。当 BService创建完了之后， AService在缓存BService Bean对象完成bService属性注入后，接着走到Bean创建流程的第三步：初始化AService，有上面知识我们知道初始化AService会回调postProcessAfterInitialization后置处理器又开始AOP逻辑。
而此时判断 AService已经存在getEarlyBeanReference()方法中放入earlyProxyReferences了，说明 原始对象已经经历过了AOP，因此就不用重复进行AOP逻辑。
这样AService也完成初始化工作，然后完美的解决了Aservice依赖BService,BService依赖Aservice这个循环依赖的问题。
最后，也来一张解决AService、BService相互依赖，且AService使用了AOP的循环依赖的流程图对上述Spring代码逻辑进行总结。红色部分主要与没有AOP情况AService、BService相互依赖流程区别内容。
图五 使用AOP且出现循环依赖的解决流程图四 为啥我们应用还会报错
前面章节已经详细讲了Spring通过三级缓存和提前曝光机制解决循环依赖问题。那我们的应用怎么还报此类错误呢？首先回顾下报错详情：
从错误描述看xxxProductMaintenanceFacadeImpl注入的xxxManageFacadeImpl对象与最终的xxxManageFacadeImpl对象不一致。从上面代码分析，我们知道Spring能改变单例Bean的对象只有在AOP情况下出现，而出现循环依赖且使用AOP的Bean有getEarlyBeanReference()方法和bean初始化步骤里后置处理器postProcessAfterInitialization两处时机进行AOP，如图五中第18步和第22步。如果是同一个AOP的织入类，那么在bean初始化步骤里后置处理器postProcessAfterInitialization处会判断Bean已经被代理过，不会再做AOP代理。但现在报错xxxManageFacadeImpl对象最终版本不一致，说明XxxManageFacadeImpl存在另一个AOP的织入类且是在后置处理器postProcessAfterInitialization处进行AOP的。
以下模拟我们的项目代码：
从示例代码看出AServiceImpl类被@Aspect和@Async两个切面注解拦截。
@Aspect注解的AOP核心业务处理由AnnotationAwareAspectJAutoProxyCreator类，它继承了AbstractAutoProxyCreator了，在AbstractAutoProxyCreator类中实现了getEarlyBeanReference()方法。
@Async注解的AOP核心业务处理由AsyncAnnotationBeanPostProcessor类，它只实现了postProcessAfterInitialization()方法,至于为什么@Async不实现提早暴露getEarlyBeanReference(),我还没有想明白。这样@Async注解是在AService初始化步骤里后置处理器postProcessAfterInitialization进行AOP，新生成了AServiceProxy2对象。
如下图所示@Aspect注解的AOP是在第18步实现的，这样二级缓存里的存放和BService对象的aService属性注入都是AServiceProxy实例对象；
而@Async注解的AOP是在第22步实现的，这是新生成AServiceProxy2实例对象；下图中蓝色部分就是进行两次AOP地方。
那么单例Bean AService存在两个AOP后的实例对象，这就违背单例的单一性原则，因此报错了；
图六 两个AOP代理时机不同导致生成两个代理Bean实例对象或许到此你还会疑问，这个循环依赖问题为什么日常或预发没出现，而都是线上部署时才遇到报错此错误？
这就跟Spring的Bean加载顺序有关系了， Spring容器载入bean顺序是不确定的,Spring框架没有约定特定顺序逻辑规范。在某些机器环境下是AService比BService先加载，但在某些环境下是BService比AService先加载。
还是拿上面示例分析，AServiceImpl类被@Aspect和@Async两个切面注解拦截，但是先加载BService再加载AService。
由图可以看出AService的@Aspect和@Async两个注解AOP在都是在后置处理器进行，因此只生成一个代理对象AServiceProxy实例，这种情况下应用启动就不会报错。
五 总结
总结下Spring解决循环依赖的思路：
在创建单例bean时，会把该bean的工厂函数的匿名类对象放入三级缓存中的singletonFactories中；
然后在填充属性时，如果出现循环依赖依赖本 bean，必然执行之前放入的工厂函数的匿名实现，如果该bean无需 AOP的话，工厂函数返回的就是原bean对象；如果该bean有 AOP 的话，也有可能是被某些BBP处理AOP 之后的代理对象，会放入二级缓存中的earlySingletonObjects中；
接着bean开始初始化，如果该bean无需 AOP的话，结果返回的原来创建的bean对象；如果该bean有 AOP 的话，检查AOP织入逻辑是否已经在提前曝光时已经执行了，如果已经执行AOP则返回提前曝光的代理bean对象；如果AOP织入逻辑未执行过，则进行后续的 BeanPostProcessor后置处理器进行AOP织入，生成AOP代理bean对象，并返回。
最后对于提前曝光的单例，就会去检查初始化后的bean对象与二级缓存中提前曝光的bean是不是同一个对象，只有不是的情况下才可能抛出异常。
深入阅读我们应用本身代码，发现项目中出现Bean的循环依赖，本质原因是代码架构设计不合理，某些facade类实现了本应在serivce层的业务逻辑，导致其他业务依赖地方反复应用facade层对象。SpringBoot 2.6.x以上的版本官方已经不推荐使用循环依赖，说不定今后某个最新版本的Spring会强制不能出现Bean循环依赖，因此需要我们开发者在平时编码时要重视代码架构设计。
图二 自我依赖示例图
对象引用循环依赖在某些业务场景上可能是合理存在的，但是由于Spring容器设计了依赖注入机制，即Spring容器在创建bean实例化以后就要给bean中的属性自动赋值，要全部自动赋值之后，才能交给用户使用。如果出现循环依赖的情况，以两个bean互相依赖的情况作为举例，假设有AService已经实例化（但未完成初始化），但是AService中需要自动赋值的BService并没有初始化，如果Spring立刻初始化BService，发现BService中需要自动赋值AService也没有初始化完成，这样就会出现相互等待，形成死循环，可能导致Spring容器都无法启动了。
由此可见，对Bean的填充属性是循环依赖源头的开始。
2.2 Spring创建Bean主要流程
为了容易理解Spring解决循环依赖过程，我们先简单温习下Spring容器创建Bena的主要流程。
从代码看Spring对于Bean的生成过程，步骤还是很多的，我把一些扩展业务代码省略掉，先上点开胃菜：
图一 相互依赖示例图
第二种是自我依赖，也就是A依赖自己形成自我依赖。
