面试官问我Spring循环依赖，我直接画了张三级缓存流程图

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. 三级缓存的工作机制图解当面试官要求画图说明解决过程时你需要清晰地展示这三个核心缓存缓存级别存储内容数据结构生命周期阶段一级缓存完全初始化好的BeanConcurrentHashMap初始化完成后二级缓存提前暴露的原始/代理对象HashMap属性填充过程中三级缓存对象工厂(ObjectFactory)HashMap实例化后初始化前整个解决流程可以分解为以下步骤Bean A实例化调用构造器创建原始对象此时生成ObjectFactory放入三级缓存Bean A属性填充发现需要注入Bean B转向处理Bean B的生命周期Bean B实例化同样创建原始对象并注册ObjectFactory到三级缓存Bean B属性填充发现需要Bean A此时从三级缓存获取ObjectFactory调用getEarlyBeanReference()方法protected Object getEarlyBeanReference(String beanName, Object bean) { // 如果有AOP代理则返回代理对象否则返回原始对象 return wrapIfNecessary(bean, beanName); }Bean B完成初始化将最终对象放入一级缓存清除二三级缓存回到Bean A属性填充此时可以注入完整的Bean BBean A完成初始化同样移入一级缓存流程结束关键提示二级缓存的存在是为了保证AOP代理对象的单例性。如果直接从三级缓存多次获取可能产生不同的代理实例。3. AOP代理与二级缓存的关键作用当面试官追问为什么需要二级缓存时这就是展示你深度理解的机会。考虑以下被AOP增强的Bean场景Service Transactional public class ServiceA { Autowired private ServiceB serviceB; } Service public class ServiceB { Autowired private ServiceA serviceA; }在这种情况下第一次从三级缓存获取ServiceA时会通过ProxyFactory创建代理对象如果没有二级缓存每次调用getEarlyBeanReference()都会生成新的代理实例二级缓存earlySingletonObjects保证了代理对象的唯一性维护了单例约定这个设计体现了Spring框架的精妙之处——通过三级缓存的分工三级缓存负责暴露未完成初始化的对象引用二级缓存保证代理对象的单例性一级缓存存储最终可用的成品Bean4. 面试中的常见追问与应对策略有经验的面试官往往会沿着这个主题深入追问。以下是几个典型问题和回答要点Q1为什么构造器注入无法解决循环依赖构造器注入必须在实例化阶段完成依赖注入此时Bean尚未创建完成无法放入三级缓存Spring会直接抛出BeanCurrentlyInCreationExceptionQ2多级缓存如何保证线程安全一级缓存使用ConcurrentHashMap保证并发安全二三级缓存采用同步块保护关键操作synchronized (this.singletonObjects) { // 检查一级缓存 // 操作二三级缓存 }Q3如何在实际开发中避免循环依赖使用设计模式重构代码如中介者模式将共同逻辑抽离到第三方类采用Lazy延迟加载打破循环使用ApplicationContext.getBean()显式获取不推荐5. 从源码角度验证核心流程对于想冲击高薪岗位的候选人还需要展示源码层面的理解。关键代码位于DefaultSingletonBeanRegistryprotected 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-referencesfalse记得在一次微服务改造项目中我们发现启动时间从2分钟延长到了5分钟。通过分析依赖关系图定位到核心服务之间存在复杂的循环引用链。最终通过引入门面模式重组服务边界不仅解决了启动问题还使代码结构更加清晰。