当前位置：首页 > news >正文

【问题】容器部署场景Spring Bean偶尔循环依赖问题

news 来源：原创 2024/9/19 4:16:27

问题描述

在本地开发中不会发生循环依赖问题，但是在容器场景下，制作成镜像启动后异常出现Bean的循环依赖。

问题原因

开发者在代码中使用构造函数注入来引用依赖的 Bean，这种方式可能导致循环依赖问题。虽然 Spring 框架具备循环依赖的处理机制，但它仅适用于通过 @Resource 或 @Autowired 注解进行的 Setter 方法注入或字段注入。如果开发者使用构造函数注入，当Bean的初始化未发生循环依赖，则启动没问题，对应日常开发中不会有循环依赖问题，但是在一些Docker容器场景，则会偶发抛出循环依赖异常。

深入剖析原理

在这里插入图片描述

进一步深入分析为什么本地没有循环依赖问题，但是容器里或服务器里偶发会出现循环依赖问题，问题的根源在于 Spring Boot 在扫描和实例化 Bean 时的顺序并非固定，而是可能受到 Jar 包中文件列表顺序的影响。

Jar 包文件列表的顺序

在 Java 中，Jar 文件实际上是一个压缩包，内部包含了许多类文件和资源文件。当应用程序运行时，可能需要遍历这些文件。例如，Spring Boot 在启动时需要扫描特定路径下的类和资源，以识别需要创建的 Bean。
在 Java 中，可以使用 JarFile.entries() 方法获取 Jar 包中的所有条目。然而，需要注意的是：JarFile.entries() 返回的并非是一个稳定有序的列表。根据 Java 官方文档，entries() 返回一个 Enumeration，但并未保证返回的顺序。
不同的平台或工具在打包 Jar 文件时，可能导致文件列表的顺序不同。例如，在 Windows 和 Linux 上生成的 Jar 文件，即使内容完全相同，但内部文件的排列顺序可能不同。

Spring Boot 的资源匹配逻辑
Spring Boot 使用 PathMatchingResourcePatternResolver 类来处理资源的匹配和加载。其中，doFindPathMatchingJarResources() 方法负责在 Jar 文件中查找与指定模式匹配的资源。

protected Set<Resource> doFindPathMatchingJarResources(Resource rootDirResource, String subPattern) throws IOException {...JarFile jarFile = ((JarURLConnection) rootDirURL.openConnection()).getJarFile();Enumeration<JarEntry> entries = jarFile.entries();while (entries.hasMoreElements()) {JarEntry entry = entries.nextElement();String entryPath = entry.getName();// 资源匹配逻辑if (matcher.match(subPattern, entryPath)) {// 处理匹配的资源}}...
}

如上所示，jarFile.entries() 返回的文件列表顺序不定。这意味着，Spring Boot 在扫描资源并识别 Bean 时，可能因为文件顺序的不同而导致 Bean 的加载顺序发生变化。

Bean 加载顺序对循环依赖的影响
在大多数情况下，Bean 的加载顺序并不会影响应用程序的启动。然而，当存在循环依赖时，Bean 的加载顺序可能决定了 Spring 能否成功地解决这种依赖关系。

举个例子，假设存在两个 Bean：BeanA 和 BeanB，它们互相依赖。如果 BeanA 先被加载，Spring 可能能够通过代理或其他机制解决依赖。然而，如果 BeanB 先被加载，可能就会导致无法解决的循环依赖，进而抛出异常。

由于 Jar 包中文件列表的顺序不定，导致 Bean 的加载顺序在不同的环境或不同的启动中可能有所不同，这解释了为什么循环依赖问题会偶尔发生。

参考链接

解决方案

方案1:干掉循环依赖

最根本的解决方案是重新设计 Bean 的依赖关系，避免循环依赖的出现。

开发规范：默认禁用构造器注入的循环依赖
PS：在升级SpringBoot3.0后，对应Spring6.0 开始，默认情况下不再允许通过构造器注入的方式解决循环依赖。如果两个 Bean 之间通过构造器注入存在循环依赖，Spring 将会直接抛出 BeanCurrentlyInCreationException，而不再试图通过懒加载代理等方式来解决这个问题。

使用 @DependsOn 注解

Spring 提供了 @DependsOn 注解，允许我们显式地指定 Bean 的加载顺序。

@Component
@DependsOn("beanB")
public class BeanA {// ...
}@Component
public class BeanB {// ...
}

通过这种方式，可以确保 BeanB 在 BeanA 之前被初始化。然而，需要谨慎使用该注解，避免引入新的依赖问题。

代码中定义某个Bean延迟加载

@Component
public class BeanA {private final BeanB beanB;public BeanA(@Lazy BeanB beanB) {this.beanB = beanB;}// ...
}

方案3:启用延迟加载

spring.main.lazy-initialization=true 是 Spring Boot 应用中的一个配置选项，它用于启用 延迟初始化功能。
在 Spring Boot 2.2 及以上版本中，lazy-initialization 的默认值是 false。这意味着默认情况下，Spring Boot 应用中的所有 Bean 都是在应用启动时立即初始化的，而不是在第一次使用时才进行初始化。

延迟初始化 (Lazy Initialization) 的概念

在 Spring 应用中，默认情况下，所有的 @Bean 和组件（如 @Component, @Service, @Repository 等）在应用启动时都会被立即创建和初始化。这意味着在应用程序启动时，所有这些 Bean 都会被加载到 Spring 应用上下文中，无论它们何时在应用的生命周期中被使用。

启用延迟初始化 (lazy initialization) 后，**只有在第一次需要使用某个 Bean 的时候，该 Bean 才会被创建和初始化。**这可以加快应用启动的速度，尤其是在有许多不需要立即初始化的 Bean 时。