Spring循环依赖解析与三级缓存机制-Easy to understand and humorous

引言

在基于Spring框架的企业级应用开发中，依赖注入（DI）是其核心特性之一。然而，当多个组件之间形成相互依赖的闭环时，就会出现循环依赖问题。Spring通过一套精妙的三级缓存机制优雅地解决了这一问题，本文将从技术原理、实现机制和最佳实践三个维度深入剖析这一核心机制。

一、循环依赖的概念与类型

循环依赖本质上是组件间依赖关系的拓扑结构问题，当依赖图形成有向环时即产生循环依赖。根据依赖链的长度和结构，可分为以下三种典型情况：

1. 双向直接依赖

两个组件彼此直接引用，形成最简单的依赖闭环。这种场景在服务层相互调用、双向关联的业务对象中较为常见，是Spring默认支持的循环依赖类型。

2. 链式间接依赖

依赖关系通过多个中间组件传递，最终形成环形依赖链。这种多级循环依赖在实际业务中更为普遍，例如：订单服务依赖库存服务，库存服务依赖商品服务，而商品服务又反过来依赖订单服务。Spring的三级缓存机制同样能够处理这类复杂的依赖场景。

3. 自反依赖

特定设计模式下，组件对自身存在依赖。虽然这种情况较为少见，但Spring框架在设计时也考虑了这种边缘情况的处理。

二、Spring容器的依赖解决机制

2.1 三级缓存架构设计

Spring框架在DefaultSingletonBeanRegistry类中实现了三级缓存架构，这一设计充分体现了空间换时间的思想：

// 核心缓存定义
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry {
    // 第一级：完全初始化的单例Bean缓存
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    
    // 第二级：早期曝光对象缓存（已实例化但未完成初始化）
    private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);
    
    // 第三级：对象工厂缓存（可延迟创建Bean实例）
    private final Map<String, ObjectFactory<?>> singletonFactories = new ConcurrentHashMap<>(16);
}

2.2 Bean生命周期与缓存状态流转

第一阶段：实例化与工厂注册

当容器开始创建单例Bean时，首先通过反射调用构造器创建原始对象，此时对象处于"半成品"状态——成员变量为默认值，依赖尚未注入。关键步骤是将这个半成品包装成ObjectFactory并存入第三级缓存。

// 简化后的注册逻辑
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
    synchronized (this.singletonObjects) {
        if (!this.singletonObjects.containsKey(beanName)) {
            this.singletonFactories.put(beanName, singletonFactory);
            this.earlySingletonObjects.remove(beanName);
        }
    }
}

第二阶段：依赖解析与提前暴露

在属性注入阶段，如果发现当前Bean依赖其他尚未完全初始化的Bean，容器会启动依赖查找流程：

检查一级缓存（完全初始化的Bean）
如果未找到，检查二级缓存（早期曝光对象）
如果仍未找到，从三级缓存获取ObjectFactory并生成早期引用
将生成的早期引用升级到二级缓存，同时从三级缓存移除对应工厂

第三阶段：初始化完成与缓存升级

当Bean的所有依赖都成功注入，并完成所有初始化回调（@PostConstruct、InitializingBean、init-method）后，Bean从"早期引用"状态升级为"完全初始化"状态，从二级或三级缓存迁移到一级缓存。

三、机制的限制与边界条件

3.1 无法解决的场景

构造器注入循环依赖

@Service
public class OrderService {
    private final UserService userService;
    
    // 构造器注入 - 无法通过三级缓存解决
    public OrderService(UserService userService) {
        this.userService = userService;
    }
}

@Service
public class UserService {
    private final OrderService orderService;
    
    public UserService(OrderService orderService) {
        this.orderService = orderService;
    }
}

原因分析：构造器注入发生在对象实例化之前，而三级缓存机制依赖对象实例化后才能注册ObjectFactory。这个时序矛盾导致构造器注入的循环依赖无法解决。

原型作用域Bean

@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Component
public class PrototypeBean {
    @Autowired
    private AnotherPrototypeBean anotherBean;
}

原型Bean每次获取都会创建新实例，不适用单例Bean的缓存机制，因此无法处理循环依赖。

3.2 条件性支持场景

字段注入与Setter注入

这两种注入方式都支持循环依赖，因为它们在对象实例化后执行，此时ObjectFactory已注册到三级缓存。

@Service
public class ProductService {
    // 字段注入 - 支持循环依赖
    @Autowired
    private InventoryService inventoryService;
    
    // Setter注入 - 支持循环依赖
    @Autowired
    public void setInventoryService(InventoryService service) {
        this.inventoryService = service;
    }
}

四、高级特性与源码深度解析

4.1 代理对象的特殊处理

在AOP或事务管理等场景中，Spring需要创建代理对象。此时三级缓存中的ObjectFactory发挥关键作用：

// 获取单例Bean的核心逻辑
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    // 从一级缓存尝试获取
    Object singletonObject = this.singletonObjects.get(beanName);
    
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
        synchronized (this.singletonObjects) {
            // 从二级缓存尝试获取
            singletonObject = this.earlySingletonObjects.get(beanName);
            if (singletonObject == null && allowEarlyReference) {
                // 从三级缓存获取ObjectFactory
                ObjectFactory<?> singletonFactory = 
                    this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
                    // 通过工厂创建Bean（可能是代理对象）
                    singletonObject = singletonFactory.getObject();
                    // 升级到二级缓存
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return singletonObject;
}

4.2 并发安全设计

三级缓存机制在多线程环境下的线程安全通过细粒度锁保证：

一级缓存使用ConcurrentHashMap保证基础并发安全
在关键操作路径上加synchronized锁，防止状态不一致
缓存间的状态转移是原子操作

五、工程实践指南

5.1 循环依赖检测与调试

在开发阶段，可以通过以下方式识别和调试循环依赖：

# application.yml
spring:
  main:
    allow-circular-references: true  # Spring Boot 2.6+ 默认关闭
    
logging:
  level:
    org.springframework.beans.factory: DEBUG

5.2 设计模式替代方案

避免循环依赖的最佳实践是从设计层面解决问题：

事件驱动解耦

// 使用领域事件解耦相互依赖的服务
@Service
public class OrderService {
    @EventListener
    public void handleInventoryEvent(InventoryEvent event) {
        // 处理库存事件
    }
}

@Service 
public class InventoryService {
    @EventListener
    public void handleOrderEvent(OrderEvent event) {
        // 处理订单事件
    }
}

门面模式

@Service
public class BusinessFacade {
    private final OrderService orderService;
    private final InventoryService inventoryService;
    
    public void processBusiness() {
        // 协调各个服务，避免服务间直接依赖
    }
}

5.3 性能优化建议

缓存调优：根据应用规模调整缓存初始容量
懒加载策略：对非关键路径依赖使用@Lazy注解
模块化设计：通过模块边界减少不必要的依赖

六、Spring Boot 2.6+的变化

从Spring Boot 2.6开始，默认行为发生变化：

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(Application.class);
        // 如果需要支持循环依赖，需要显式设置
        app.setAllowCircularReferences(false); // 默认值
        app.run(args);
    }
}

结论

Spring的三级缓存机制是框架设计智慧的集中体现，它通过精妙的状态管理和对象生命周期控制，在不过度复杂化设计的前提下，优雅地解决了循环依赖这一经典难题。然而，技术解决方案不应成为不良设计的"保护伞"。在实际项目中，我们应当：

理解机制，但不依赖机制：将三级缓存视为安全保障，而非设计依据
分层设计，明确边界：通过清晰的分层和模块化减少不必要的循环依赖
持续重构，优化架构：定期审查依赖关系，保持架构的清晰性和可维护性

Spring框架通过这种机制向我们展示了优秀框架设计的原则：在提供强大功能的同时，引导开发者走向更好的设计实践。真正的技术价值不仅在于解决问题本身，更在于推动思考更好的问题解决方式。

目录CONTENT

Spring循环依赖解析与三级缓存机制

引言