Spring Boot 应用集成时的循环依赖问题与解决方案

本文详解 spring boot 多模块/多应用集成中因包扫描冲突与 bean 创建顺序引发的“requested bean is currently in creation”循环依赖错误,并提供基于 `@lazy`、精准包扫描、配置隔离等实战级修复方案。

在将独立的 Spring Boot 批处理应用(如 com.publicismedia.uniquebatchjava)集成进 Jmix 主应用时,常见的错误并非简单的类路径缺失,而是深层的 Bean 生命周期冲突 —— 典型表现为 BeanCurrentlyInCreationException,提示 “Requested bean is currently in creation: Is there an unresolvable circular reference?”。该异常本质是 Spring 容器在初始化过程中检测到无法解耦的依赖闭环,例如:

jmix_Liquibase → dataSource  
↓  
dataSource ← (via JmixLiquibaseAutoConfiguration)  
↓  
entityManagerFactory ← (required by BatchConfigRepository)  
↓  
batchConfigRepository ← (injected into batchExecuter)  
↓  
batchExecuter ← (injected into stellantisroiApplication)  
↓  
stellantisroiApplication ← (depends on tokenStore, which depends on jmix_Liquibase...)  
→ 循环闭合!

这种跨应用的强耦合往往源于过度宽泛的组件扫描自动配置未隔离。你当前的配置:

@SpringBootApplication(scanBasePackages = {"com.publicismedia.uniquebatchjava"})
@EnableJmixDataRepositories(basePackages = {})
@EnableJpaRepositories(basePackages = {"com.publicismedia.uniquebatchjava.repository"})

虽意图明确,但存在关键隐患:

  • scanBasePackages 会触发 com.publicismedia.uniquebatchjava 下所有 @Configuration、@Service、@Component 的加载,包括可能隐式依赖 Jmix 核心 Bean 的配置类;
  • @EnableJpaRepositories 虽限定了仓库包,但其底层仍需 EntityManagerFactory 和 DataSource —— 而 Jmix 的 jmix_Liquibase 和 dataSource 正在初始化中,形成死锁。

推荐解决方案(按优先级排序):

1. 精准控制扫描范围,避免“全局污染”

仅扫描业务逻辑层(@Service, @Repository),排除配置类与启动类

@SpringBootApplication(
    scanBasePackages = {
        "com.publicismedia.uniquebatchjava.service",
        "com.publicismedia.uniquebatchjava.repository",
        "com.publicismedia.uniquebatchjava.config" // 仅含非自动配置的纯配置类
    }
)
// 移除 @EnableJpaRepositories —— @SpringBootApplication 已隐式启用
public class JmixApplication { ... }
⚠️ 注意:确保 com.publicismedia.uniquebatchjava.config 中不包含 @EnableJpaRepositories、@EnableTransactionManagement 或任何依赖 dataSource/entityManagerFactory 的 @Bean 方法。如有,应迁移至 Jmix 主应用的 @Configuration 类中统一管理。

2. 对高风险依赖使用 @Lazy 延迟加载

当 batchExecuter 必须注入 BatchConfigRepository,而后者又间接依赖尚未就绪的

dataSource 时,在字段上添加 @Lazy 可打破初始化链:

@Service
public class BatchExecutor {

    @Lazy // 关键:延迟代理,绕过启动时依赖解析
    @Autowired
    private BatchConfigRepository batchConfigRepository;

    public void execute() {
        // 第一次调用时才真正初始化 repository 及其 EntityManager
        batchConfigRepository.findAll();
    }
}

3. 隔离数据源与 JPA 配置(高级场景)

若批处理应用自带 DataSource 或 JpaConfiguration,必须显式禁用其自动配置,防止与 Jmix 冲突:

# application.yml
spring:
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
      - org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration
      - io.jmix.autoconfigure.data.JmixLiquibaseAutoConfiguration # 若批处理无需 Liquibase

同时,在 Jmix 主应用中显式声明批处理专用的 EntityManagerFactory(使用 Jmix 的 DataSource):

@Configuration
public class BatchJpaConfig {

    @Bean
    @Primary // 确保批处理使用此 EMF,而非 Jmix 默认的
    public LocalContainerEntityManagerFactoryBean batchEntityManagerFactory(
            DataSource dataSource,
            JpaVendorAdapter jpaVendorAdapter) {
        LocalContainerEntityManagerFactoryBean em = new LocalContainerEntityManagerFactoryBean();
        em.setDataSource(dataSource);
        em.setJpaVendorAdapter(jpaVendorAdapter);
        em.setPackagesToScan("com.publicismedia.uniquebatchjava.entity");
        return em;
    }
}

总结:集成原则

  • ? 最小化扫描:永远只扫描必要包,绝不扫描对方的 Application 类或 autoconfig 包;
  • ? 延迟即解耦:对跨上下文注入的 Bean,优先考虑 @Lazy;
  • ? 配置即契约:明确约定“谁提供 DataSource、谁管理事务”,避免双方自动配置打架;
  • ? 验证依赖图:启动时添加 --debug 参数,查看 ConditionEvaluationReport,快速定位冲突自动配置。

遵循以上策略,即可安全复用 Spring Boot 批处理模块,彻底规避 BeanCurrentlyInCreationException。