企业官网建设流程全解析

Spring循环依赖的三级缓存机制：从面试场景拆解核心原理

"能详细解释下Spring如何处理循环依赖吗？"——这个看似简单的问题，往往成为区分普通开发者和资深工程师的关键分水岭。当面试官抛出这个问题时，他们期待的不仅是一个标准答案，更是考察候选人对Spring框架底层设计的理解深度。本文将从一个真实的面试对话切入，通过三级缓存流程图解和AOP代理场景分析，带你掌握这个高频面试题的完整回答策略。

1. 循环依赖的本质与解决前提

让我们从一个典型的技术面试场景开始。面试官推了推眼镜问道："假设你有两个Service类互相引用，Spring为什么不会陷入死循环？"此时，你需要先明确循环依赖的定义——当Bean A依赖Bean B，同时Bean B又依赖Bean A时，就形成了循环引用链。

Spring解决这个问题有两个关键前提条件：

• 必须是单例Bean：原型(prototype)作用域的Bean会直接抛出BeanCurrentlyInCreationException
• 必须采用setter或字段注入：构造器注入的循环依赖无法解决，因为Java语言要求在构造阶段就必须完成对象初始化

// 构造器注入的循环依赖示例（无法解决） @Service class ServiceA { private final ServiceB serviceB; public ServiceA(ServiceB serviceB) { this.serviceB = serviceB; } } @Service class ServiceB { private final ServiceA serviceA; public ServiceB(ServiceA serviceA) { this.serviceA = serviceA; } }

2. 三级缓存的工作机制图解

当面试官要求"画图说明解决过程"时，你需要清晰地展示这三个核心缓存：

整个解决流程可以分解为以下步骤：

1. Bean A实例化：调用构造器创建原始对象，此时生成ObjectFactory放入三级缓存
2. Bean A属性填充：发现需要注入Bean B，转向处理Bean B的生命周期
3. Bean B实例化：同样创建原始对象并注册ObjectFactory到三级缓存
4. Bean B属性填充：发现需要Bean A，此时从三级缓存获取ObjectFactory
   • 调用getEarlyBeanReference()方法：

     protected Object getEarlyBeanReference(String beanName, Object bean) { // 如果有AOP代理则返回代理对象，否则返回原始对象 return wrapIfNecessary(bean, beanName); }

5. Bean B完成初始化：将最终对象放入一级缓存，清除二三级缓存
6. 回到Bean A属性填充：此时可以注入完整的Bean B
7. Bean A完成初始化：同样移入一级缓存，流程结束

关键提示：二级缓存的存在是为了保证AOP代理对象的单例性。如果直接从三级缓存多次获取，可能产生不同的代理实例。

3. AOP代理与二级缓存的关键作用

当面试官追问"为什么需要二级缓存"时，这就是展示你深度理解的机会。考虑以下被AOP增强的Bean场景：

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

在这种情况下：

1. 第一次从三级缓存获取ServiceA时，会通过ProxyFactory创建代理对象
2. 如果没有二级缓存，每次调用getEarlyBeanReference()都会生成新的代理实例
3. 二级缓存earlySingletonObjects保证了代理对象的唯一性，维护了单例约定

这个设计体现了Spring框架的精妙之处——通过三级缓存的分工：

• 三级缓存负责暴露未完成初始化的对象引用
• 二级缓存保证代理对象的单例性
• 一级缓存存储最终可用的成品Bean

4. 面试中的常见追问与应对策略

有经验的面试官往往会沿着这个主题深入追问。以下是几个典型问题和回答要点：

Q1：为什么构造器注入无法解决循环依赖？

• 构造器注入必须在实例化阶段完成依赖注入
• 此时Bean尚未创建完成，无法放入三级缓存
• Spring会直接抛出BeanCurrentlyInCreationException

Q2：多级缓存如何保证线程安全？

• 一级缓存使用ConcurrentHashMap保证并发安全
• 二三级缓存采用同步块保护关键操作：

  synchronized (this.singletonObjects) { // 检查一级缓存 // 操作二三级缓存 }

Q3：如何在实际开发中避免循环依赖？

• 使用设计模式重构代码（如中介者模式）
• 将共同逻辑抽离到第三方类
• 采用@Lazy延迟加载打破循环
• 使用ApplicationContext.getBean()显式获取（不推荐）

5. 从源码角度验证核心流程

对于想冲击高薪岗位的候选人，还需要展示源码层面的理解。关键代码位于DefaultSingletonBeanRegistry：

protected Object getSingleton(String beanName, boolean allowEarlyReference) { // 1. 检查一级缓存 Object singletonObject = this.singletonObjects.get(beanName); if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { synchronized (this.singletonObjects) { // 2. 检查二级缓存 singletonObject = this.earlySingletonObjects.get(beanName); if (singletonObject == null && allowEarlyReference) { // 3. 从三级缓存获取ObjectFactory ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName); if (singletonFactory != null) { singletonObject = singletonFactory.getObject(); this.earlySingletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName); } } } } return singletonObject; }

这个方法清晰地展示了三级缓存的查询顺序和升级逻辑。当我在实际阅读源码时发现，Spring通过isSingletonCurrentlyInCreation()方法维护了一个名为singletonsCurrentlyInCreation的Set集合，用于标识正在创建中的Bean，这是检测循环引用的关键。

6. 性能优化与生产实践

在大型应用中，循环依赖可能带来启动性能问题。通过以下方式可以优化：

• 监控工具：使用Spring Boot Actuator的beans端点检查依赖关系
• 架构设计：
  • 模块化拆分减少交叉依赖
  • 明确分层架构规范（Controller→Service→Repository）
• 启动加速：

  # 开启快速失败模式 spring.main.allow-circular-references=false

记得在一次微服务改造项目中，我们发现启动时间从2分钟延长到了5分钟。通过分析依赖关系图，定位到核心服务之间存在复杂的循环引用链。最终通过引入门面模式重组服务边界，不仅解决了启动问题，还使代码结构更加清晰。