Setter注入导致循环依赖时如何解决？

Question

在使用Spring框架时，若两个Bean（如A和B）通过Setter方法相互依赖注入，即A依赖B且B依赖A，将导致循环依赖问题。虽然Spring通过三级缓存机制可解决单例下的构造器循环依赖，但Setter注入虽能缓解部分场景，仍可能因初始化顺序不当引发Bean提前暴露或依赖未完全装配的问题。如何合理设计Bean依赖关系，避免循环引用？常见解决方案包括：重构业务逻辑消除循环依赖、采用@Lazy延迟加载、或结合@Autowired与@PostConstruct分阶段注入。

Answer 1

Spring框架中循环依赖问题的深度解析与解决方案

1. 循环依赖的基本概念与表现形式

在Spring容器管理Bean的过程中，当两个或多个Bean相互持有对方的引用时，就形成了循环依赖（Circular Dependency）。最常见的情形是：Bean A通过Setter方法注入Bean B，而Bean B又反过来依赖Bean A。

例如：

@Component
public class BeanA {
    private BeanB beanB;

    @Autowired
    public void setBeanB(BeanB beanB) {
        this.beanB = beanB;
    }
}

@Component
public class BeanB {
    private BeanA beanA;

    @Autowired
    public void setBeanA(BeanA beanA) {
        this.beanA = beanA;
    }
}
    

虽然Spring支持单例模式下的Setter循环依赖（借助三级缓存），但这种设计仍存在隐患，尤其是在初始化顺序、代理创建或AOP增强场景下可能引发异常。

2. Spring三级缓存机制简要剖析

Spring通过三级缓存解决单例Bean的循环依赖问题，其核心结构如下表所示：

缓存层级	名称	作用
一级缓存	singletonObjects	存放完全初始化完成的单例Bean实例
二级缓存	earlySingletonObjects	存放提前暴露的原始Bean（未完成属性填充）
三级缓存	singletonFactories	存放ObjectFactory，用于创建早期引用

当Bean A创建过程中发现需要注入Bean B，而Bean B也正在创建中时，Spring会从三级缓存中获取Bean A的早期引用并注入到Bean B中，从而打破初始化阻塞。

3. Setter注入虽可缓解，但非万能解药

相较于构造器注入，Setter注入允许Bean在构造完成后逐步设置依赖，因此更容易被Spring的三级缓存机制处理。然而，在以下场景中仍可能出现问题：

• 涉及AOP代理（如@Transactional、@Async）时，早期暴露的对象可能是原始对象而非代理对象，导致后续调用无法触发切面逻辑。
• 若某个Bean在@PostConstruct方法中使用了尚未完全装配的依赖，将引发NullPointerException或业务逻辑错误。
• 多线程环境下，Bean的初始化状态不一致可能导致不可预知的行为。

这表明，即使技术上可行，循环依赖仍是代码结构“坏味道”的体现。

4. 常见解决方案对比分析

为避免循环依赖带来的潜在风险，开发者应优先考虑重构而非依赖框架兜底。以下是主流解决方案的对比：

方案	实现方式	适用场景	优点	缺点
重构依赖关系	提取公共逻辑至第三方Bean	长期维护项目	根治问题，提升内聚性	需较大重构成本
@Lazy延迟加载	@Lazy注解修饰@Autowired字段	启动性能敏感场景	简单易行，无需改结构	仅推迟依赖创建，未消除耦合
@PostConstruct分阶段注入	在初始化后回调中访问依赖	必须保留双向交互逻辑	确保依赖已装配	增加代码复杂度

5. 实战示例：结合@Autowired与@PostConstruct规避风险

在无法立即重构的情况下，可通过生命周期回调确保依赖可用：

@Component
public class ServiceA {

    @Autowired
    private ServiceB serviceB;

    private boolean initialized = false;

    @PostConstruct
    public void init() {
        // 确保serviceB已完成注入后再执行业务逻辑
        serviceB.registerHandler(this);
        initialized = true;
    }

    public void handleEvent() {
        if (!initialized) throw new IllegalStateException("Service not initialized");
        // 正常业务处理
    }
}
    

该模式适用于事件监听、回调注册等需要双向通信的场景。

6. 使用@Lazy实现延迟依赖注入

通过@Lazy注解，Spring会在首次访问时才真正创建Bean，从而打破初始化时的依赖链：

@Component
public class CircularServiceX {

    @Autowired
    @Lazy
    private CircularServiceY serviceY;
    
    // 其他逻辑...
}
    

此方式特别适合启动阶段不需要立即使用的服务，如定时任务处理器、异步消息消费者等。

7. 架构层面的设计建议

从DDD（领域驱动设计）视角出发，合理的模块划分有助于从根本上杜绝循环依赖：

• 遵循“依赖倒置原则”（DIP），高层模块不应直接依赖低层模块，二者都应依赖抽象。
• 引入中介者模式（Mediator Pattern）或事件总线（Event Bus）解耦组件间直接引用。
• 采用CQRS模式分离读写模型，减少服务间的交叉调用。

例如，使用Spring的ApplicationEvent机制替代直接调用：

public class OrderCreatedEvent extends ApplicationEvent { ... }

@Service
public class InventoryService implements ApplicationListener {
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // 处理库存扣减，无需直接引用OrderService
    }
}
    

8. 可视化流程：Spring解决Setter循环依赖过程

以下Mermaid流程图展示了Spring如何通过三级缓存处理Setter循环依赖：

graph TD
    A[开始创建BeanA] --> B{BeanA是否在缓存中?}
    B -- 否 --> C[实例化BeanA(未填充属性)]
    C --> D[放入三级缓存singletonFactories]
    D --> E[开始填充属性, 发现依赖BeanB]
    E --> F{BeanB是否存在?}
    F -- 否 --> G[创建BeanB]
    G --> H[实例化BeanB, 放入三级缓存]
    H --> I[填充BeanB属性, 发现依赖BeanA]
    I --> J[从三级缓存获取BeanA早期引用]
    J --> K[注入BeanA到BeanB]
    K --> L[BeanB初始化完成, 移入一级缓存]
    L --> M[继续初始化BeanA, 注入BeanB]
    M --> N[BeanA初始化完成, 移入一级缓存]
    N --> O[循环依赖解决]
    

该流程揭示了Spring如何巧妙利用“提前暴露”机制化解死锁风险。

9. 高级技巧：自定义ObjectFactory绕过限制

对于复杂的初始化逻辑，可手动注册ObjectFactory以控制早期引用生成：

@Configuration
public class CustomBeanConfig {

    @Autowired
    private ConfigurableListableBeanFactory beanFactory;

    @PostConstruct
    public void registerEagerBeans() {
        beanFactory.registerSingleton("beanA", new BeanA());
        beanFactory.registerDependentBean("beanB", "beanA");
    }
}
    

这种方式适用于需要精细控制Bean生命周期的中间件开发场景。

10. 总结性思考：技术妥协 vs 架构优雅

尽管Spring提供了强大的循环依赖解决方案，但作为资深开发者，我们应当意识到：

• 循环依赖往往是职责划分不清的信号。
• 过度依赖框架特性会降低系统的可测试性和可维护性。
• 真正的高可用系统应追求“无循环依赖”的干净架构。

建议团队在代码评审中将循环依赖列为重要检查项，并建立自动化检测机制（如ArchUnit规则）预防此类问题蔓延。