【SpringBoot】一文详解 Spring Bean 循环依赖

奥特迦

于 2023-11-25 14:59:19 发布

阅读量525

点赞数 1

分类专栏： Spring Boot 文章标签： spring boot spring java

原文链接：https://mp.weixin.qq.com/s/d9Ya1gMY2DDH4Cfps73Fog

版权

Spring Boot 专栏收录该内容

16 篇文章 3 订阅

订阅专栏

1. 背景

有好几次线上发布老应用时，遭遇代码启动报错，具体错误如下：

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. 相关知识点简介

2.1 什么是Bean循环依赖?

循环依赖是指 Bean 对象循环引用，是两个或多个Bean之间相互持有对方的引用。循环依赖有2种表现形式：

第一种是相互依赖，也就是A依赖B，B又依赖A：

在这里插入图片描述

第二种是自我依赖，也就是A依赖自己形成自我依赖：

在这里插入图片描述

对象引用循环依赖在某些业务场景上可能是合理存在的，但是由于 Spring 容器设计了依赖注入机制，即 Spring 容器在创建 bean 实例化以后就要给 bean 中的属性自动赋值，要全部自动赋值之后，才能交给用户使用。

如果出现循环依赖的情况，以两个 bean 互相依赖的情况作为举例，假设有 AService 已经实例化（但未完成初始化），但是 AService 中需要自动赋值的 BService 并没有初始化，如果 Spring 立刻初始化 BService，发现 BService 中需要自动赋值 AService 也没有初始化完成，这样就会出现相互等待，形成死循环，可能导致 Spring 容器都无法启动了。

由此可见，对 Bean 的填充属性是循环依赖源头的开始。

2.2 Spring 创建 Bean 主要流程

为了容易理解 Spring 解决循环依赖过程，我们先简单温习下 Spring 容器创建 Bena 的主要流程。

从代码看 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);
    }
    // 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个核心步骤：

实例化 Bean

主要是通过反射调用默认构造函数创建 Bean 实例，此时 bean 的属性都还是默认值 null。被注解 @Bean 标注的方法就是此阶段被调用的。

填充 Bean 属性

这一步主要是对 bean 的依赖属性进行填充，对 @Value @Autowired @Resource 注解标注的属性注入对象引用。

调用 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 的生命流程进行一个流程图的总结：

在这里插入图片描述

此处敲黑板划重点：Spring 的动态代理（AOP）是通过BPP实现的（在图中的3.4步实现），其中 AbstractAutoProxyCreator 是十分典型的自动代理类，它实现了 SmartInstantiationAwareBeanPostProcessor 接口，并重写了 getEarlyBeanReference 和 postProcessAfterInitialization 两个方法实现代理的逻辑，这样完成对原始 Bean 进行增强，生成新 Bean 对象，将增强后的新 Bean 对象注入到属性依赖中。

3. 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> T doGetBean(final String name, @Nullable final Class<T> 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.java
public 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代码逻辑进行总结。

在这里插入图片描述

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()方法。

//真正实现了该方法的类就是AbstractAutoProxyCreator
public 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相互依赖流程区别内容。

在这里插入图片描述

4. 为啥我们应用还会报错

前面章节已经详细讲了 Spring 通过三级缓存和提前曝光机制解决循环依赖问题。那我们的应用怎么还报此类错误呢？首先回顾下报错详情：

在这里插入图片描述

从错误描述看 xxxProductMaintenanceFacadeImpl 注入的 xxxManageFacadeImpl 对象与最终的 xxxManageFacadeImpl 对象不一致。

从上面代码分析，我们知道 Spring 能改变单例 Bean 的对象只有在 AOP 情况下出现，而出现循环依赖且使用 AOP 的 Bean 有 getEarlyBeanReference() 方法和 bean 初始化步骤里后置处理器 postProcessAfterInitialization 两处时机进行 AOP，如 3.3 图中第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后的实例对象，这就违背单例的单一性原则，因此报错了。

在这里插入图片描述

或许到此你还会疑问，这个循环依赖问题为什么日常或预发没出现，而都是线上部署时才遇到报错此错误？

这就跟Spring的Bean加载顺序有关系了， Spring容器载入bean顺序是不确定的，Spring框架没有约定特定顺序逻辑规范。在某些机器环境下是AService比BService先加载，但在某些环境下是BService比AService先加载。

还是拿上面示例分析，AServiceImpl类被@Aspect和@Async两个切面注解拦截，但是先加载BService再加载AService。

在这里插入图片描述

由图可以看出AService的@Aspect和@Async两个注解AOP在都是在后置处理器进行，因此只生成一个代理对象AServiceProxy实例，这种情况下应用启动就不会报错。

5. 总结

总结下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循环依赖，因此需要我们开发者在平时编码时要重视代码架构设计。

奥特迦

关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
1
评论
【SpringBoot】一文详解 Spring Bean 循环依赖

循环依赖是指 Bean 对象循环引用，是两个或多个Bean之间相互持有对方的引用。循环依赖有2种表现形式：第一种是相互依赖，也就是A依赖B，B又依赖A：第二种是自我依赖，也就是A依赖自己形成自我依赖：对象引用循环依赖在某些业务场景上可能是合理存在的，但是由于 Spring 容器设计了依赖注入机制，即Spring 容器在创建 bean 实例化以后就要给 bean 中的属性自动赋值，要全部自动赋值之后，才能交给用户使用。
复制链接

扫一扫