SpringBoot这个循环依赖坑我连踩三次才爬出来-CFANZ编程社区

SpringBoot这个循环依赖坑我连踩三次才爬出来*

引言

在SpringBoot开发中，循环依赖（Circular Dependency）是一个老生常谈却又极易踩坑的问题。作为一个经验丰富的开发者，我本以为对这个问题早已了然于胸，然而现实却给了我当头一棒——在三个不同的项目中，我连续三次栽在了循环依赖的坑里。每次看似简单的依赖关系，背后却隐藏着Spring容器的复杂机制。本文将详细剖析循环依赖的成因、Spring的解决机制，以及如何避免和解决这一问题，希望能帮助读者少走弯路。

什么是循环依赖？

循环依赖指的是两个或多个Bean相互依赖，形成一个闭环。例如：

Bean A 依赖 Bean B
Bean B 依赖 Bean C
Bean C 又依赖 Bean A

这种情况下，Spring容器在初始化这些Bean时会陷入死循环，无法正常完成依赖注入。Spring通过三级缓存（早期曝光机制）部分解决了单例Bean的循环依赖问题，但并非所有场景都能完美处理。

Spring如何解决循环依赖？

Spring的循环依赖解决机制基于三级缓存：

一级缓存（Singleton Objects）：存放完全初始化好的Bean。
二级缓存（Early Singleton Objects）：存放尚未完成属性注入的半成品Bean。
三级缓存（Singleton Factories）：存放Bean的工厂对象，用于生成半成品Bean。

以下是Spring解决循环依赖的核心流程：

创建Bean A时，先将A的工厂对象放入三级缓存。
对A进行属性注入时发现需要Bean B，于是开始创建Bean B。
创建Bean B时，同样将B的工厂对象放入三级缓存。
对B进行属性注入时发现需要Bean A，此时从三级缓存中拿到A的工厂对象，生成半成品A并注入到B中。
B初始化完成后，A继续完成属性注入和初始化。

这种机制看似完美，但实际上有严格的限制：

仅适用于单例Bean。
依赖的注入方式必须是属性注入（Field Injection）或Setter注入。构造器注入无法解决循环依赖。
如果Bean涉及AOP代理，情况会更加复杂。

我踩过的三个坑

坑一：构造器注入引发的循环依赖

场景*：在第一个项目中，我遵循“推荐使用构造器注入”的最佳实践，结果遇到了循环依赖问题。

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

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

问题*：Spring无法通过构造器注入解决循环依赖，直接抛出BeanCurrentlyInCreationException。
解决*：改为Setter注入或字段注入，或者重新设计代码消除循环依赖。

坑二：@Async注解导致的循环依赖

场景*：在第二个项目中，我为Service添加了@Async注解，结果引发了循环依赖。

@Service
public class AsyncService {
    @Async
    public void asyncMethod() {
        // 异步逻辑
    }
}

@Service
public class CallerService {
    @Autowired
    private AsyncService asyncService;
}

问题*：@Async会通过AOP生成代理对象，而代理对象的创建时机与普通Bean不同，导致三级缓存机制失效。
解决*：将@Async移到单独的Bean中，或使用@Lazy延迟注入。

坑三：多线程环境下循环依赖的隐性爆发

场景*：在第三个项目中，循环依赖问题在测试环境从未出现，但在高并发生产环境中频繁报错。
问题*：Spring的三级缓存机制并非线程安全，在高并发场景下可能出现竞争条件，导致BeanCurrentlyInCreationException。
解决*：彻底重构代码，消除循环依赖，或者使用@Lazy作为临时解决方案。

如何避免和解决循环依赖？

1. 代码设计层面

遵循单一职责原则：减少Bean之间的耦合。
提取公共逻辑：将共享逻辑提取到第三方Bean中。
接口抽象：通过接口隔离直接依赖。

2. 技术手段

使用@Lazy：延迟加载打破循环。

@Service
public class ServiceA {
    @Lazy
    @Autowired
    private ServiceB serviceB;
}

改用Setter/字段注入：避免构造器注入的循环依赖问题。
ApplicationContext.getBean()：手动获取Bean（不推荐，破坏IOC原则）。

3. 工具检测

使用IDE插件（如IntelliJ IDEA的Circular Dependencies检测）。
Spring Boot启动时添加-Ddebug参数查看依赖关系。

为什么Spring不彻底解决循环依赖？

设计原则：循环依赖通常是代码设计问题的表现，Spring鼓励良好的设计。
性能开销：完全解决循环依赖需要复杂的机制，影响启动性能。
技术限制：构造器注入的循环依赖无法在不破坏对象完整性的前提下解决。

总结

循环依赖是SpringBoot开发中的高频陷阱，看似简单的背后是Spring容器的复杂运行机制。通过本文的分析，我们可以看到：

Spring的三级缓存机制能解决部分场景的循环依赖，但并非万能。
构造器注入、AOP代理、高并发场景会放大循环依赖的问题。
最佳实践是从代码设计层面避免循环依赖，而非依赖技术手段绕开。

作为开发者，我们应当将循环依赖视为代码设计的“坏味道”，而不是一个可以通过技巧忽略的问题。只有深入理解原理，才能在复杂场景中游刃有余。