浅谈 spring 如何解决 bean 的循环依赖问题

2025年Java面试宝典下载地址（提取码：9b3g）建议保存在个人网盘备用

浅谈Spring如何解决Bean的循环依赖问题

什么是Bean的循环依赖

在Spring框架中，当两个或多个Bean之间通过构造函数或属性注入形成相互依赖时，就会产生Bean循环依赖问题。比如BeanA依赖BeanB，而BeanB又反过来依赖BeanA，这种情况下容器初始化时就会出现死锁。

去年我在美团三面时，面试官就让我在白板上画这种场景下的依赖关系图。当时我虽然知道三级缓存的概念，但具体如何分级处理还是卡壳了。后来深入研究源码才发现，Spring解决循环依赖的核心在于三级缓存机制。

Spring的三级缓存机制

Spring容器内部维护了三个关键缓存容器：

1. SingletonObjects（一级缓存）：存放完全初始化好的Bean
2. EarlySingletonObjects（二级缓存）：存放提前暴露的原始Bean
3. SingletonFactories（三级缓存）：存放Bean的ObjectFactory

这三个缓存就像三个不同阶段的装配车间。当创建BeanA时，Spring会先把它放入三级缓存，等属性填充阶段发现需要BeanB时，又会去创建BeanB。此时如果BeanB反过来需要BeanA，就能通过三级缓存拿到还在创建中的BeanA引用。

解决流程四部曲

1. 创建BeanA实例：通过反射调用构造函数，此时对象处于"正在创建"状态
2. 暴露早期引用：将BeanA的ObjectFactory存入三级缓存
3. 填充属性：发现需要注入BeanB，触发BeanB的创建流程
4. 递归解决：当BeanB需要注入BeanA时，通过三级缓存拿到半成品BeanA

这个过程就像拼装乐高积木，先搭好骨架结构再逐步填充细节。这种设计保证了即使存在循环依赖，Bean也能正确组装。

构造函数循环依赖的例外情况

虽然属性注入的循环依赖可以通过三级缓存解决，但构造函数循环依赖却是Spring明确声明不支持的。这是因为在构造函数执行阶段，Bean还没有被放入缓存，导致后续依赖查找失败。

去年腾讯TEG的面试中就遇到这个考点。当面试官追问："为什么@Autowired能解决循环依赖，而构造器注入不行？"时，能清晰解释三级缓存的工作阶段差异，就能加分不少。

面试应对技巧

在面试场景中解释这个问题时，建议按照以下脉络：

1. 先说现象：遇到循环依赖会导致容器启动失败
2. 引出三级缓存机制
3. 画图说明三个缓存的协作流程
4. 特别强调构造器注入的特殊情况
5. 最后补充实际开发中的规避方法

如果需要准备更多Spring面试题，可以通过面试鸭返利网找到我，购买会员可返利25元。这个平台整理了近三年大厂真题，我自己备考时也常去刷题，实测覆盖率能达到80%以上。