Spring循环依赖：原理、解决方案与最佳实践-代码聚汇网

Spring循环依赖：原理、解决方案与最佳实践

用户甲·2026-07-15·阅读 38 GEO检测（免费）

Spring循环依赖三级缓存机制构造器注入

|难度：普通|阅读约 12 分钟

1. 循环依赖的本质与Spring的应对机制

循环依赖问题在Spring框架中是一个经典的设计难题。当两个或多个Bean相互引用时，就会形成依赖闭环。比如Bean A的初始化需要Bean B，而Bean B的初始化又需要Bean A，这就构成了典型的循环依赖场景。

Spring通过三级缓存机制巧妙地解决了大部分循环依赖问题：

一级缓存（singletonObjects）：存放完全初始化好的Bean
二级缓存（earlySingletonObjects）：存放提前暴露的原始Bean对象
三级缓存（singletonFactories）：存放Bean工厂对象

这个机制的核心在于允许"提前暴露"未完全初始化的Bean引用。当Bean A正在初始化时，Spring会先将其工厂对象放入三级缓存，这样当Bean B需要引用Bean A时，就能通过这个工厂获取到A的早期引用。

重要提示：这种解决方案仅适用于字段注入(Field Injection)和setter方法注入(Setter Injection)场景。对于构造器注入(Constructor Injection)，Spring的三级缓存机制无法生效。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 构造器注入为何无法解决循环依赖

构造器注入的循环依赖之所以无法解决，是因为Spring创建Bean的流程决定的。构造器注入发生在Bean实例化阶段，此时Bean的完整生命周期尚未开始：

创建Bean A实例 → 需要先注入Bean B
创建Bean B实例 → 需要先注入Bean A
又回到创建Bean A实例...

这种死锁状态导致Spring无法通过提前暴露引用的方式打破循环。Spring官方文档明确说明："循环依赖如果涉及构造器注入，是无法解决的，会抛出BeanCurrentlyInCreationException异常"。

在实际项目中，我遇到过这样的典型错误场景：

java复制@Service
public class ServiceA {
    private final ServiceB serviceB;
    
    @Autowired
    public ServiceA(ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

@Service 
public class ServiceB {
    private final ServiceA serviceA;
    
    @Autowired
    public ServiceB(ServiceA serviceA) {
        this.serviceA = serviceA;
    }
}

启动应用时会直接报错：

code复制Error creating bean with name 'serviceA'...
Requested bean is currently in creation: Is there an unresolvable circular reference?

3. 解决构造器注入循环依赖的实践方案

3.1 代码重构方案

最根本的解决方案是重新设计代码结构，消除循环依赖。根据我的经验，可以采用以下方法：

提取公共逻辑到第三方类：

java复制public class CommonService {
    // 将A和B都需要的方法提取到这里
}

@Service
public class ServiceA {
    private final CommonService commonService;
    // 移除对ServiceB的直接依赖
}

@Service
public class ServiceB {
    private final CommonService commonService;
    // 移除对ServiceA的直接依赖
}

使用接口抽象：

java复制public interface IService {
    void commonMethod();
}

@Service 
public class ServiceA implements IService {
    // 实现接口方法
}

@Service
public class ServiceB {
    private final IService service; // 依赖接口而非具体实现
    
    @Autowired
    public ServiceB(IService service) {
        this.service = service;
    }
}

3.2 技术变通方案

如果短期内无法重构代码，可以考虑以下临时解决方案：

改用setter注入：

java复制@Service
public class ServiceA {
    private ServiceB serviceB;
    
    @Autowired
    public void setServiceB(ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

使用@Lazy注解延迟初始化：

java复制@Service
public class ServiceA {
    private final ServiceB serviceB;
    
    @Autowired
    public ServiceA(@Lazy ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

ApplicationContext手动获取（不推荐，破坏IoC原则）：

java复制@Service
public class ServiceA {
    private final ApplicationContext context;
    
    @Autowired
    public ServiceA(ApplicationContext context) {
        this.context = context;
    }
    
    public void someMethod() {
        ServiceB serviceB = context.getBean(ServiceB.class);
        // 使用serviceB
    }
}

4. 生产环境中的最佳实践

根据我在多个Spring项目中的实践经验，总结出以下建议：

优先使用构造器注入：虽然它不能解决循环依赖，但它能保证依赖不可变、便于测试，是Spring官方推荐的方式。
尽早发现循环依赖：在开发阶段就应当通过单元测试和集成测试发现循环依赖问题，而不是等到部署时才发现。
使用架构检测工具：SonarQube、ArchUnit等工具可以帮助在早期识别出循环依赖问题。
分层清晰的设计：遵循单一职责原则，保持各层的单向依赖关系：
- Controller → Service → Repository
- 避免跨层反向依赖
监控与告警：在生产环境中配置对循环依赖的监控，可以使用Spring的BeanPostProcessor自定义检测逻辑。

5. 常见问题排查与解决

5.1 典型错误场景分析

场景一：启动时报BeanCurrentlyInCreationException

检查是否有构造器注入的循环依赖
使用--debug启动参数查看Spring的Bean创建日志

场景二：字段注入看似工作正常，但某些场景下NPE

可能是循环依赖导致某些Bean未完全初始化就被使用
检查是否有@PostConstruct方法依赖了其他Bean

5.2 调试技巧

在application.properties中添加：

properties复制logging.level.org.springframework.beans=DEBUG

使用Spring Boot Actuator的/beans端点查看Bean依赖关系
在IDE中设置断点：

AbstractAutowireCapableBeanFactory#doCreateBean
DefaultSingletonBeanRegistry#getSingleton

5.3 性能考量

循环依赖虽然能被Spring解决，但会带来额外的性能开销：

增加了Bean的创建时间
可能导致更多的内存占用
影响应用启动速度

在性能敏感的场景中，应当尽量避免任何形式的循环依赖。

6. 高级话题：Spring新版本的变化

从Spring 5.2.3开始，新增了一个配置项来显式允许循环引用：

properties复制spring.main.allow-circular-references=true

但这个配置有几个限制：

仅适用于字段注入和setter注入
可能掩盖设计问题
不推荐在生产环境使用

在Spring 6.0中，对循环依赖的处理机制有进一步优化，但基本原则保持不变——构造器注入的循环依赖仍然无法解决。

在实际项目中，与其依赖框架的特性来解决循环依赖，不如从设计层面避免这种情况的发生。良好的分层设计和接口抽象不仅能避免循环依赖，还能使代码更易于维护和测试。