Spring循环依赖解决核心思想

原创 已于 2023-03-27 16:46:11 修改 · 531 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #开发语言

于 2023-03-27 13:54:19 首次发布
文章详细阐述了Spring框架如何处理循环依赖问题，包括普通解决方法、Spring的特殊处理以及AOP下的循环依赖解决方案。通过数据结构如单例池、早期对象和对象工厂，Spring能够在bean创建过程中打破循环并确保AOP的正确应用。同时，文章提到了Spring无法解决的特定循环依赖场景，如原型bean的循环依赖和构造器依赖。

前言

循环依赖基本是一个会必然出现的问题，所以spring是必须解决的，初看起来很复杂，但是如果分开理解就不会过于复杂了，本篇文章主要是讲解spring中循环依赖的解决方案

循环依赖

比如有以下的两个类，如下

public class A {
    @Autowire
    private B b;
}

public class B {
    @Autowire
    private A a;
}

普通的循环依赖解决

如果不是在spring中，我们可以很容易的解决这个问题，如下


B b = new B();
A a = new A();

b.a = a;
a.b = b;

只需要进行如此的设置就可以解决了，但是如果在spring中那么这个流程就会变得复杂，主要是spring中bean都是有生命周期的，如下

spring中的循环依赖

解设A先创建的，有如下的过程

1. 初始化A
2. 填充A的属性，从单例池获取B
3. bean后置处理器的前置方法
4. bean后置处理器的后置方法
5. 放到单例池

当在添加A中的b属性时又会触发B的创建

2.1. 初始化B
2.2. 填充B的属性，从单例池获取A
2.3. bean后置处理器的前置方法
2.4. bean后置处理器的后置方法
2.5. 放到单例池

如上面所示，如果不进行任何处理，那么就会陷入死循环，spring肯定是需要进行处理的，那么是如何处理的，我们就一步步往下面看

spring循环依赖解决

首先，可以先说下解决的核心点，主要有以下的数据结构与作用

Map<String, Object> singletonObjects： 单例池，存储了成熟的bean
Map<String, Object> earlySingletonObjects： 早期未经过完整bean周期的bean
Map<String, ObjectFactory<?>> singletonFactories：用于解决是否需要aop返回对应的对象的
Set<String> singletonsCurrentlyInCreation：当前正在创建的bean集合
Map<Object, Object> earlyProxyReferences：是否已经提前进行aop了

下面就慢慢进行分析整个过程了

打破循环依赖

在上面的问题中，就是出现了死循环的依赖，那么最简单的方法就是加入一个map打破这个循环即可，如下

解设A先创建的，有如下的过程

1. 初始化A->zxcMap<a,A的原始对象>
2. 填充A的属性，从单例池获取B
3. bean后置处理器的前置方法
4. bean后置处理器的后置方法
5. 放到单例池

当在添加A中的b属性时又会触发B的创建

2.1. 初始化B
2.2. 填充B的属性，从单例池获取a->zxcMap获取到了
2.3. bean后置处理器的前置方法
2.4. bean后置处理器的后置方法
2.5. 放到单例池

如上，只要添加一个zxcMap就可以打破这个循环了，那么是不是就解决这个问题了呢？如果不考虑aop的话，确实是已经解决了，但是如果出现了aop就有可能出现问题了

aop下循环的问题

解设在实例化A到第4. bean后置处理器的后置方法的时候，A需要进行aop，那么最后放到单列池的就是AOP的代理对象，但B从zxcMap获取的对象是原始对象，那么很明显就有问题了

aop循环解决方案一

可以直接这样 1. 初始化A->aop-> zxcMap<a,A的代理对象>，这样就可以解决了，但是如果这样bean的生命周期就有问题了，因为不是所有bean都需要提前进行aop的，所以就有问题了

aop循环解决方案二

那么就不能这样做，我们需要确认是否发生了循环依赖以后再提前aop，那么如何弄，只需要进行下面的操作

解设A先创建的，有如下的过程

0. createset放置a正在创建中
1. 初始化A->zxcMap<a,A的原始对象>
2. 填充A的属性，从单例池获取B
3. bean后置处理器的前置方法
4. bean后置处理器的后置方法
5. 放到单例池

当在添加A中的b属性时又会触发B的创建

2.0  createset放置b正在创建中
2.1. 初始化B                                     ->a原始对象    
2.2. 填充B的属性，从单例池获取a->createset是否在创建a->提前aop->a的代理对象
2.3. bean后置处理器的前置方法
2.4. bean后置处理器的后置方法
2.5. 放到单例池

如上，只要在a创建的时候放到一个set，在b获取a的时候就可以判断是否需要提前进行aop了，但是这里又引出了新的问题，假设此时A还和C进行了相互依赖，如下

public class A {
    @Autowire
    private B b;
    @Autowire
    private C c;
}

public class B {
    @Autowire
    private A a;
}
public class C {
    @Autowire
    private A a;
}

那么过程会变为如下

解设A先创建的，有如下的过程

0. createset放置a正在创建中
1. 初始化A->zxcMap<a,A的原始对象>
2. 填充A的属性，从单例池获取B
3. 填充A的属性，从单例池获取C
4. bean后置处理器的前置方法
5. bean后置处理器的后置方法
6. 放到单例池

当在添加A中的b属性时又会触发B的创建

2.0  createset放置b正在创建中
2.1. 初始化B                                     ->a原始对象    
2.2. 填充B的属性，从单例池获取a->createset是否在创建a->提前aop->a的代理对象
2.3. bean后置处理器的前置方法
2.4. bean后置处理器的后置方法
2.5. 放到单例池

当在添加A中的c属性时又会触发C的创建

3.0  createset放置C正在创建中
3.1. 初始化C                                    ->a原始对象    
3.2. 填充C的属性，从单例池获取a->createset是否在创建a->提前aop->a的代理对象
3.3. bean后置处理器的前置方法
3.4. bean后置处理器的后置方法
3.5. 放到单例池

这种情况下会发生了a的代理对象创建了两个，所以这里也是二级缓存出现的原因，逻辑就应该变为如下

解设A先创建的，有如下的过程

0. createset放置a正在创建中
1. 初始化A->zxcMap<a,A的原始对象>
2. 填充A的属性，从单例池获取B
3. 填充A的属性，从单例池获取C
4. bean后置处理器的前置方法
5. bean后置处理器的后置方法
6. 放到单例池

当在添加A中的b属性时又会触发B的创建

2.0  createset放置b正在创建中
2.1. 初始化B                                     ->a原始对象    
2.2. 填充B的属性，从单例池获取a->createset是否在创建a->从earlySingletonObjects获取->提前aop->a的代理对象->放到earlySingletonObjects中
2.3. bean后置处理器的前置方法
2.4. bean后置处理器的后置方法
2.5. 放到单例池

当在添加A中的c属性时又会触发C的创建

3.0  createset放置C正在创建中
3.1. 初始化C                                    ->a原始对象    
3.2. 填充C的属性，从单例池获取a->createset是否在创建a->earlySingletonObjects获取到直接返回->提前aop->a的代理对象
3.3. bean后置处理器的前置方法
3.4. bean后置处理器的后置方法
3.5. 放到单例池

所以earlySingletonObjects的作用就出来了，他是为了解决当bean发生aop的时候代理对象不会创建多个，那么实际上这样就解决这个问题了吗，为啥需要三级map，这是因earlySingletonObjects存的不一定是代理对象因为不一定要进行aop，也有可能是原始对象，那么原始对象如何返回呢，就需要三级map的帮助

三级map存在的原因

三级map其实是一串表达式，逻辑如下

解设A先创建的，有如下的过程

0. createset放置a正在创建中
1. 初始化A->zxcMap<a,lambame>
2. 填充A的属性，从单例池获取B
3. 填充A的属性，从单例池获取C
4. bean后置处理器的前置方法
5. bean后置处理器的后置方法
6. 放到单例池

当在添加A中的b属性时又会触发B的创建

2.0  createset放置b正在创建中
2.1. 初始化B                                        
2.2. 填充B的属性，从单例池获取a->createset是否在创建a->从earlySingletonObjects->zxcMap<a,lambame>->放到earlySingletonObjects中
2.3. bean后置处理器的前置方法
2.4. bean后置处理器的后置方法
2.5. 放到单例池

zxcMap<a,lambame>的表达式逻辑如下

lambame逻辑如下

if(a需要aop) 则返回a的代理对象
else 则返回a的原始对象

所以Map<String, ObjectFactory<?>> singletonFactories就提现出三级map的作用了，而二级map的earlySingletonObjects的内容就来源于三级singletonFactories的判定，这样就清晰多了，那么最后的数据结构earlyProxyReferences有什么作用呢？如下

earlyProxyReferences的作用

正常bean的aop逻辑是在bean后置处理器的后置方法进行实现的，如果在发生循环依赖的时候进行了aop

lambame逻辑如下

if(a需要aop) 则返回a的代理对象，earlyProxyReferences.add(对象)
else 则返回a的原始对象

那么在

bean后置处理器的时候，如果earlyProxyReferences.contains(对象)，那么就不需要进行再次aop
防止对同一个对象进行了多次aop处理

这样一来，spring的循环依赖就解决了

spring中的getSingle方法

这是5.2.8的源码，不同版本可能有不同的实现

@Nullable
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        //先从单例池获取
        Object singletonObject = this.singletonObjects.get(beanName);
        //如果单例池没有并且bean正在创建
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            //加锁
            synchronized (this.singletonObjects) {
                //再次从单例池获取对象
                singletonObject = this.earlySingletonObjects.get(beanName);
                //如果还是为空并且支持循环依赖
                if (singletonObject == null && allowEarlyReference) {
                    //从三级缓存中获取表达式
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                        //调用方法，这里返回的可能是原始对象也可能是经过aop的代理对象
                        singletonObject = singletonFactory.getObject();
                        //放到二级缓存中。以便于上面说到C的对象中进行使用
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        //使用完了就进行移除，防止出现bug或者内存占用
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return singletonObject;
    }

spring解决不了的情况

有以下几种情况spring没有办法直接解决循环依赖问题

如果a和b都是原型的，那么是无法解决的

如果a和b只有一个原型，一个单例那么是可以解决的

如果a和b的构造器相互依赖对方，那只能通过@Lazy注解来解决，标记在任何一个上面即可

如果a自依赖自己那么也是可以解决的

总结

至此spring的循环依赖就说完了，其实也不能说很复杂，核心的点就是那几个东西，多看几遍就记住了

【微服务】spring 循环依赖问题深入解析
congge_study的博客
09-05 3821
spring 循环依赖问题深入解析
【微服务】spring循环依赖深度解析
congge
12-06 7737
spring循环依赖解决详解
Spring框架(四) 三级缓存与循环依赖
热门推荐
刘跃辉的博客
04-26 10万+
1.循环依赖 首先我们需要明白什么是循环依赖 ， 打个比方 ， 就是说A对象在创建的过程中 ， 需要依赖注入B对象 ， 但是B对象没有 ， 就需要去创建 ， 而在创建B对象的过程中又需要注入A对象 ， A对象此时还在创建中，所以就构成了一个死循环 ， A，B相互依赖 这样的关系被成为循环依赖（当然 ， 可能还会有其他的情况），下面我们就来看看Spring是如何让解决循环依赖的 2.一二三级缓存 三个缓存对应着三个不同的Map 一级：singletonObjects 这个缓存也就是单例池 ， 它存放
Spring之AOP代理对象的产生（二）
桐花思雨
02-01 1189
前言 我们接着 spring aop代理对象的产生（一） 来分析 aop 代理对象的产生，上篇文章解读到了 AbstractAutowireCapableBeanFactory 的 initializeBean 方法，我们继续 aop 代理对象的产生 initializeBean 方法重点关注 applyBeanPostProcessorsAfterInitialization 方法 AOP 的原理和实现就在其中，来到了AbstractAutowireCapableBeanFactory的applyBean
Spring 5.x 源码之旅四十六AOP代理细节一wrapIfNecessary
王伟王胖胖的博客
03-31 3447
Spring 5.x 源码之旅四十六AOP代理细节一wrapIfNecessarypostProcessAfterInitialization初始化之后进行代理earlyProxyReferences是什么AbstractAutoProxyCreator的getEarlyBeanReferencewrapIfNecessary代理getAdvicesAndAdvisorsForBeanfindEl...
Spring源码学习14
大脸猫的博客
07-25 324
1.AnnotationAwareAspectJAutoProxyCreator.java Ordered：{@code Ordered}是一个可以由<em> 可排序 </ em>的对象实现的接口，例如在{@code Collection}中，方法order()获取对象的优先级较高的值被解释为较低的优先级。 作为结果，具有最低值的对象具有最高优先级 ProxyCon...
Spring源码最难问题：当Spring AOP遇上循环依赖
Java知音
06-10 398
点击关注公众号，实用技术文章及时了解前言问：Spring如何解决循环依赖？答：Spring通过提前曝光机制，利用三级缓存解决循环依赖。再问：Spring通过提前曝光，直接曝光到二级缓存已经可以解决循环依赖问题了，为什么一定要三级缓存？再细问：如果循环依赖的时候，所有类又都需要Spring AOP自动代理，那Spring如何提前曝光？曝光的是原始bean还是代理后的bean...
万字长文带你吃透Spring是怎样解决循环依赖的
愿万事胜意
03-20 2万+
循环依赖其实就是循环引用，也就是一个或多个以上的对象互相持有对方，最终形成闭环，形成一个无限循环的依赖关系。比如 A依赖于A本身(左图)，A依赖于B，B也依赖与A(中)，A依赖B，B依赖C，C又依赖A(右图)。a.b = b;b.a = a;然而，Spring的循环依赖通常被单独拎出来谈论，也经常在面试中被提及。这是因为 Spring 中对象的创建和管理是由 IOC 控制的，一个对象的创建不仅仅是简单地调用 new，而是经过了一系列 Bean 的生命周期。因此，循环依赖问题也就会随之而来。
解放代码：识别与消除循环依赖的实战指南
张彦峰的博客
11-20 8万+
本文讨论软件开发中常见的循环依赖问题及其解决方法。首先介绍了循环依赖在代码中的形成原因，并提出了避免循环依赖的基本原则。其次，详细介绍了使用工具如JDepend来识别项目中的循环依赖，并通过具体案例分析了三种消除循环依赖的方法：提取中介者、转移业务逻辑和采用回调接口。每种方法都结合了实际的代码改造示例和测试用例，帮助读者理解和应用这些技术以优化自己的软件架构和设计。主要思想的编排思路来自极客时间《如何有效识别和解决代码中存在的循环依赖问题？》，当然也有其他的参考和自身的一些思考和优化。
Spring Boot 系统学习第四天：Spring循环依赖案例分析
geminigoth的博客
06-03 1118
在前面介绍三种不同的依赖注入类型时，引出了使用Spring IoC容器时一个常见问题，即循环依赖。同时也明确了在单例作用域下，Setter方法注入能够解决循环依赖问题，而构造器注入则不能。对于单例作用域来说，Spring容器在整个生命周期内，有且只有一个Bean对象，所以很容易想到这个对象应该存在于缓存中。Spring为了解决单例Bean的循环依赖问题，使用了三级缓存。这是Spring在设计和实现上的一大特色。
细致又通透：spring如何解决循环依赖
weixin_45365220的博客
05-15 827
Spring Bean生命周期 Spring Bean Scope 作用域 以上流程是大致的流程，真正的好代码是需要亲自去看去理解的。当然Spring解决循环依赖的方法可以解决大多数循环依赖，但是还是会存在依赖深度较复杂，Spring无法解决，这个时候可以在导致循环依赖的地方加上@Lazy注解，对改依赖进行懒加载，只有使用到改依赖时才会进行加载。
spring 循环依赖碰到的问题
xjk201的博客
12-07 1020
在项目中 orderFormService的 而不配置shiro里面的aop 仅仅配置spring的aop的话
面试——Spring中的循环依赖
weixin_45565886的博客
05-05 3082
面试高频——Spring循环依赖
Spring中的循环依赖
SuZhan0711
02-09 3万+
目录一、什么是循环依赖？二、Bean的生命周期2.1 Spring Bean 的生命周期2.2 Bean 的生成步骤三、三级缓存3.1三个缓存分别有什么作用四、思路分析4.1 为什么 Spring 中还需要 singletonFactories 呢？五、Spring解决了哪种情况下的循环依赖5.1 ObjectFactory六、getEarlyBeanReference方法七、总结 一、什么是循环依赖？ 例如，就是A对象依赖了B对象，B对象依赖了A对象。 // A依赖了B class A{ pub
earlyProxyReferences 的核心作用
m0_59539752的博客
02-18 825
代理一致性保障，这一机制在循环依赖与 AOP 代理协同场景中尤为关键。通过这种设计，Spring 在保持高扩展性的同时，确保了代理生成的高效与一致性。当 Bean A 被其他 Bean 依赖时，会通过三级缓存触发。早期版本中，循环依赖场景下可能生成两个不同的代理对象（通过。集合，用于跟踪哪些 Bean 的代理对象已在。CGLIB 与 JDK 代理可能混合出现，导致。在 Spring 最新版本（5.3.x+）中，未清理的早期代理引用可能导致无法垃圾回收。在 Bean 初始化完成后，执行。
Spring IOC---AOP代理对象生成的时机
gongsenlin341的博客
12-15 1万+
文章目录1.概述2.前置知识3.Spring AOP代理对象生成的时机3.1非提前生成代理对象3.2 提前生成代理对象4. 为什么需要两种动态代理的时机 1.概述 Spring AOP可以采用注解或者xml配置的方式实现，那么在spring的生命周期当中，是在什么时候生成的代理对象呢？本文就AOP代理对象生成的时机进行介绍。不清楚spring生命周期的读者可以先阅读另一篇博客《Spring IOC—Bean的生命周期》。 2.前置知识 BeanPostProcessor接口的作用 简单的讲就是在一个对象
Spring AOP源码解析
Tyella的博客
10-24 209
创建AOP代理 上面讲解了通过自定义配置完成了对AnnotationAwareAspectJAutoProxyCreator类型的自动注册，这个类到底做了什么工作来完成AOP的操作呢，首先我们看看AnnotationAwareAspectJAutoProxyCreator的类层次结构。 在类的层级中，我们可以看到AnnotationAwareAspectJAutoProxyCreator实现了BeaPostProcessor接口，而实现BeanPostProcessor接口后，当Spring加载这个Bea
Spring中Bean的循环依赖以及处理原理
weixin_45046474的博客
03-08 345
Spring中Bean的循环依赖以及处理原理 什么是循环依赖 //下面是简单的Spring循环依赖示例 @Component public class A { @Autowired private B b; } @Component public class B { @Autowired private B b; } ​ 以上代码如果在类上面没有加上@Component就是普通的java类,在加上这个注解后就会交给Spring来管理,那么此时这些类就不需要我
Spring源码面试最难问题——循环依赖
LoveSummer
03-27 6万+
问：Spring 如何解决循环依赖？答：Spring 通过提前曝光机制，利用三级缓存解决循环依赖（这原理还是挺简单的，参考：三级缓存、图解循环依赖原理）再问：Spring 通过提前曝光，直接曝光到二级缓存已经可以解决循环依赖问题了，为什么一定要三级缓存？再细问：如果循环依赖的时候，所有类又都需要 Spring AOP 自动代理，那 Spring 如何提前曝光？曝光的是原始 bean 还是代理后的 bean？
Spring循环依赖问题
最新发布
09-17
<think> 首先，用户查询的是“Spring循环依赖问题的产生原因及解决方案”。我需要基于提供的站内引用信息来回答。 回顾系统级指令： - 所有行内数学表达式使用$...$格式（但在这个主题中，可能没有数学表达式）。 - 独立公式使用$$...$$格式（同样，可能不需要）。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识，例如[^1]。 用户提供了多个引用： - [^1]: 讨论了Spring bean的完整生命周期，以及循环依赖问题。 - [^2]: Spring通过三级缓存解决单例Bean属性注入的循环依赖问题。 - [^3]: 循环依赖的产生与业务场景相关，例如用户服务和订单服务之间的依赖。 - [^4]: 详细解释了三级缓存：一级缓存存储完整的Bean，二级缓存存储实例化但未初始化的Bean，三级缓存存储工厂。 - [^5]: 提到在populateBean阶段注入循环依赖的bean可能会导致问题。 我的回答需要结构化： - 逐步解决问题：先解释原因，再讨论解决方案。 - 保证真实可靠，基于引用信息。 关键点： 1. **产生原因**： - 循环依赖是指两个或多个Bean相互依赖对方的实例。 - 引用[^3]提到，常见于业务场景，如用户服务和订单服务：用户服务依赖订单服务查询订单，订单服务依赖用户服务获取用户信息。 - 在Spring中，当Bean在创建过程中需要注入另一个Bean，而那个Bean又需要第一个Bean时，就会发生循环依赖。 2. **解决方案**： - Spring通过三级缓存机制解决单例Bean的属性注入循环依赖。 - 引用[^2]和[^4]详细描述了这个机制： - 一级缓存 (singletonObjects)：存储完全初始化的Bean。 - 二级缓存 (earlySingletonObjects)：存储已实例化但未初始化的Bean（尚未属性注入）。 - 三级缓存 (singletonFactories)：存储Bean工厂，用于创建Bean的早期引用。 - 过程：当创建Bean A时，它需要注入Bean B。Spring先创建A的早期版本（放入三级缓存），然后尝试注入B。如果B也需要A，Spring可以从三级缓存获取A的早期版本注入到B中，避免无限循环。 - 引用[^4]解释了缓存如何配合：工厂生成的Bean放入二级缓存，最终完成初始化后放入一级缓存。 - 引用[^5]提醒，在populateBean阶段注入依赖时，如果缓存中没有，可能会导致重新创建实例，但三级缓存机制防止了这一点。 结构化回答： - 引言：简述Spring循环依赖及其重要性。 - 产生原因： - 解释什么是循环依赖。 - 举例业务场景。 - 基于引用[^3]。 - 解决方案： - 介绍三级缓存机制。 - 详细描述每个缓存的作用。 - 解释解决过程。 - 基于引用[^2]、[^4]。 - 注意事项：引用[^2]提到，尽管Spring可以解决，但应通过设计避免循环依赖。 生成相关问题： - 在回答末尾，添加相关问题，如指令要求。 - 示例问题： 1. 三级缓存机制的具体工作流程是怎样的？ 2. Spring如何处理非单例Bean的循环依赖？ 3. 在实际开发中，如何避免循环依赖？ 4. 循环依赖对性能有什么影响？ 添加引用标识： - 在回答中，当引用具体信息时，自然地添加[^n]在句子末尾。 - 例如：“循环依赖的产生通常与具体业务场景有关[^3]。” 最终回答结构： 1. 介绍Spring循环依赖问题。 2. 产生原因。 3. 解决方案（三级缓存机制）。 4. 结论和建议。 5. 相关问题。 </think> ### Spring循环依赖问题的产生原因及解决方案 Spring框架中的循环依赖问题是指两个或多个Bean在创建过程中相互依赖对方的实例，导致初始化陷入死循环的情况。理解其原因和解决方案有助于优化应用设计和避免运行时错误。下面我将基于Spring的工作原理，逐步解释。 #### 1. **产生原因** - **核心原因**：循环依赖源于Bean之间的直接或间接相互引用。在Spring IoC容器初始化Bean时，如果Bean A依赖Bean B，而Bean B又依赖Bean A，容器在实例化过程中无法完成依赖注入，形成无限递归。这通常发生在： - **属性注入（Setter或Field注入）**：当Bean通过属性注入方式引用另一个Bean时，如果两个Bean互相引用，Spring在创建阶段就会卡住。 - **构造函数注入**：构造函数注入的循环依赖无法被Spring自动解决（因为容器必须在实例化时完成所有依赖注入）。 - **业务场景驱动**：循环依赖的产生常与具体业务逻辑相关。例如，在电商系统中： - 用户服务（UserService）需要调用订单服务（OrderService）来查询用户订单列表。 - 订单服务（OrderService）需要调用用户服务（UserService）来获取用户详细信息进行订单分类处理\[^3]。 - 根本原因在于Spring的Bean生命周期：Bean的创建分为实例化、属性注入和初始化三个阶段。如果Bean在属性注入阶段需要另一个尚未创建完毕的Bean，而那个Bean又回指回来，就会触发循环依赖问题\[^1][^5]。 #### 2. **解决方案** Spring通过**三级缓存机制**巧妙解决单例Bean（Singleton Scope）的属性注入循环依赖问题。核心思想是“提前暴露Bean的早期引用”，即在Bean尚未初始化完成时，就提供一个可用的引用供其他Bean使用。三级缓存的具体结构和工作流程如下： - **三级缓存的定义**： - **一级缓存（singletonObjects）**：存储完全初始化的Bean（已完成实例化、属性注入和初始化）。这是最终可用的Bean\[^4]。 - **二级缓存（earlySingletonObjects）**：存储仅完成实例化但未进行属性注入的Bean（即“半成品”Bean）。这些Bean可以被其他Bean临时引用\[^4]。 - **三级缓存（singletonFactories）**：存储一个工厂对象（ObjectFactory），该工厂可以生成Bean的早期引用。这样做的目的是延迟Bean的创建过程，避免直接暴露未完成的Bean\[^2][^4]。 - **解决流程**（以Bean A和Bean B相互依赖为例）： 1. **创建Bean A**：Spring先实例化Bean A（但未注入属性和初始化），并将其工厂放入三级缓存。 2. **发现依赖**：在Bean A的属性注入阶段，它需要Bean B。 3. **创建Bean B**：Spring尝试创建Bean B，实例化后放入三级缓存。 4. **Bean B的依赖**：Bean B在属性注入阶段需要Bean A。 5. **获取早期引用**：Spring从三级缓存中获取Bean A的工厂，生成一个早期引用（此时Bean A还未初始化），并将该引用放入二级缓存。然后注入到Bean B中。 6. **完成Bean B**：Bean B完成属性注入和初始化后，放入一级缓存。 7. **完成Bean A**：Spring将Bean B注入Bean A，Bean A完成初始化，移入一级缓存\[^2][^4]。 - 这个过程确保即使Bean未完全初始化，也能通过二级缓存提供引用，打破循环链条。 - **关键优势**： - **只适用于单例Bean**：三级缓存机制专为Singleton Bean设计，确保在整个应用中只有一个实例。 - **避免重新创建**：通过提前暴露引用，防止在`populateBean`（属性注入阶段）时因依赖缺失而重新创建Bean实例（这可能导致额外开销或不一致）\[^5]。 - **不支持构造函数注入**：如果循环依赖发生在构造函数中，Spring无法解决（推荐改用Setter注入或重构设计）\[^2]。 - **实际代码示例**（简化版说明）： ```java // Bean A 依赖 Bean B public class BeanA { private BeanB beanB; // Setter注入 public void setBeanB(BeanB beanB) { this.beanB = beanB; } } // Bean B 依赖 Bean A public class BeanB { private BeanA beanA; // Setter注入 public void setBeanA(BeanA beanA) { this.beanA = beanA; } } ``` Spring的三级缓存会在`BeanA`实例化后提供一个早期引用给`BeanB`，从而解决依赖\[^4]。 #### 3. **注意事项与最佳实践** - **局限性**：三级缓存只解决属性注入的单例循环依赖。对于原型（Prototype）Bean或多线程环境，Spring无法自动解决循环依赖，开发者需通过设计重构避免。 - **设计建议**：尽管Spring提供了解决方案，但过度依赖三级缓存可能导致代码可维护性下降。推荐通过以下方式预防循环依赖： - 重构业务逻辑，例如使用接口解耦或引入第三方服务类。 - 优先使用Setter注入而非构造函数注入\[^2][^3]。 - 监控工具检测：在开发阶段使用Spring工具（如`@Lazy`注解延迟加载）来识别潜在循环\[^1]。 - 总之，Spring的三级缓存是其IoC容器的核心智慧，但良好的设计始终是首选解决方案\[^2][^3]。 ####
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值