Java面试题:Spring中的循环依赖,给程序员带来的心理阴影

循环依赖通常发生在两个或多个Spring Bean之间,它们通过构造器、字段(使用@Autowired)或setter方法相互依赖,从而形成一个闭环。下面是一个使用字段注入(即使用@Autowired)导致的循环依赖的示例:

示例代码:

假设我们有两个类,ClassA 和 ClassB,它们相互依赖:

复制代码
public class ClassA {  

    @Autowired  
    private ClassB classB;  

    // ... 其他代码 ...  
}  

@Component  
public class ClassB {  

    @Autowired  
    private ClassA classA;  

    // ... 其他代码 ...  
}

在上面的示例中,ClassA 依赖 ClassB,而 ClassB 又依赖 ClassA。当Spring容器启动时,它会尝试为这两个类创建bean的实例。但是,由于它们之间的循环依赖,这会导致问题。

问题说明:

当Spring容器创建ClassA的bean时,它会发现ClassA依赖于ClassB,所以它会尝试创建ClassB的bean。当Spring容器创建ClassB的bean时,它又会发现ClassB依赖于ClassA,但此时ClassA的bean还没有被完全初始化(因为它正在等待ClassB的bean),这就形成了一个死循环。

那么Spring是如何解决这种循环依赖问题的?

三级缓存机制:

Spring容器在创建bean的过程中,会维护三个缓存,分别是:singletonObjects(一级缓存)、earlySingletonObjects(二级缓存)和singletonFactories(三级缓存)。

当Spring容器开始实例化一个bean时,会先将其ObjectFactory(对象工厂)放入三级缓存中。如果在实例化过程中需要注入其他bean,并且这个bean也正在实例化中,Spring会先从一级缓存中查找该bean的实例。如果没有找到,会到二级缓存中查找。如果二级缓存中也没有,那么会到三级缓存中查找ObjectFactory,并调用ObjectFactory的getObject方法来获取bean的实例。

当获取到bean的实例后,会将其放入二级缓存中,并从三级缓存中移除ObjectFactory。

当bean的实例化过程完成后,会将其放入一级缓存中。

通过这种方式,Spring可以在bean的实例化过程中解决循环依赖问题。

@Lazy注解:

在Spring中,可以使用@Lazy注解来延迟bean的初始化。当一个bean被标记为@Lazy时,Spring容器在启动时不会立即实例化它,而是在第一次被使用时才进行实例化。

通过将循环依赖的bean声明为懒加载,可以延迟它们的初始化过程,从而避免在容器启动时发生循环依赖问题。

需要注意的是,@Lazy注解只能用于单例作用域的bean,并且要求依赖项必须是接口类型。

以下是使用@Lazy注解来解决循环依赖的示例代码:

复制代码
@Component  
public class ClassA {  

    private final ClassB classB;  

    // 使用@Autowired和@Lazy注解来延迟ClassB的注入  
    @Autowired  
    public ClassA(@Lazy ClassB classB) {  
        this.classB = classB;  
    }  

    // ... 其他代码 ...  
}  

@Component  
public class ClassB {  

    private final ClassA classA;  

    // 使用@Autowired和@Lazy注解来延迟ClassA的注入  
    @Autowired  
    public ClassB(@Lazy ClassA classA) {  
        this.classA = classA;  
    }  

    // ... 其他代码 ...  
}

在上面的示例中,@Lazy注解被用于ClassA和ClassB的构造器参数上,以延迟它们之间的依赖注入。这意味着在创建ClassA时,它不会立即尝试去初始化ClassB,而是会得到一个代理对象。同样,在创建ClassB时,它也不会立即初始化ClassA。

避免构造器循环依赖:

在Spring中,构造器循环依赖是无法解决的,因为构造器在实例化bean的过程中被调用,如果两个bean相互依赖对方的构造器,那么就会形成死锁。

因此,在设计bean的依赖关系时,应该尽量避免使用构造器注入来创建循环依赖。可以使用setter注入或字段注入来代替构造器注入。

下面是一个构造器循环依赖的错误代码示例:

复制代码
@Component  
public class ClassA {  

    private final ClassB classB;  

    // 通过构造器注入ClassB,形成循环依赖  
    @Autowired  
    public ClassA(ClassB classB) {  
        this.classB = classB;  
    }  

    // ... 其他代码 ...  
}  

@Component  
public class ClassB {  

    private final ClassA classA;  

    // 通过构造器注入ClassA,与ClassA形成循环依赖  
    @Autowired  
    public ClassB(ClassA classA) {  
        this.classA = classA;  
    }  

    // ... 其他代码 ...  
}

在上面的示例中,ClassA和ClassB各自在构造函数中依赖于对方,这就形成了构造器循环依赖。

当Spring容器尝试创建这两个bean的实例时,会遇到问题:

  • Spring首先尝试创建ClassA的实例,并发现它需要ClassB的实例。

  • 然后,Spring尝试创建ClassB的实例,但发现它需要ClassA的实例。

  • 由于ClassA的实例正在等待ClassB的实例,而ClassB的实例又正在等待ClassA的实例,这导致了一个死循环,无法继续创建bean的实例。

综上所述,Spring通过三级缓存机制、@Lazy注解以及避免构造器循环依赖等方式来解决循环依赖问题。这些机制使得Spring容器能够更加灵活地处理bean之间的依赖关系,提高系统的可维护性和可扩展性。

相关推荐
激流丶6 分钟前
【Kafka 实战】如何解决Kafka Topic数量过多带来的性能问题?
java·大数据·kafka·topic
Themberfue10 分钟前
Java多线程详解⑤(全程干货!!!)线程安全问题 || 锁 || synchronized
java·开发语言·线程·多线程·synchronized·
让学习成为一种生活方式27 分钟前
R包下载太慢安装中止的解决策略-R语言003
java·数据库·r语言
晨曦_子画32 分钟前
编程语言之战:AI 之后的 Kotlin 与 Java
android·java·开发语言·人工智能·kotlin
南宫生1 小时前
贪心算法习题其三【力扣】【算法学习day.20】
java·数据结构·学习·算法·leetcode·贪心算法
Heavydrink1 小时前
HTTP动词与状态码
java
ktkiko111 小时前
Java中的远程方法调用——RPC详解
java·开发语言·rpc
计算机-秋大田1 小时前
基于Spring Boot的船舶监造系统的设计与实现,LW+源码+讲解
java·论文阅读·spring boot·后端·vue
神里大人2 小时前
idea、pycharm等软件的文件名红色怎么变绿色
java·pycharm·intellij-idea
小冉在学习2 小时前
day53 图论章节刷题Part05(并查集理论基础、寻找存在的路径)
java·算法·图论