目录
最近一直在面试，上周遇到这个问题，因为之前其实梳理过这个问题，但是因为时间过去很久，一些细节给忽略掉了，今天正好找到了之前画的示意图，针对Spring的循环依赖问题的解决方案，再尝试自己去理解下，可能不是很周全，如有错的地方，还望指正。
开门见山，就不再赘述什么是循环依赖，简单提一下就是A服务依赖B服务，同时B服务也依赖A服务，当然也有三者之间的闭环依赖，总之就是依赖之间的闭环。
1.什么是循环依赖？
例如：两个或多个 Bean 互相持有对方的引用，形成依赖闭环：
java
@Component
public class BeanA {
@Autowired
private BeanB beanB;
}
@Component
public class BeanB {
@Autowired
private BeanA beanA;
}2.三种常见形式
| 注入方式 | 是否能被 Spring 解决 | 说明 |
|---|---|---|
| Setter/Field 注入（单例） | ✅ 能解决 | 最常见场景，也是三级缓存的主战场 |
| 构造器注入 | ❌ 无法解决 | 实例化阶段就必须拿到完整对象，无机会提前暴露 |
| 多例 Bean | ❌ 无法解决 | 不缓存 Bean，每次 getBean 都新建，会无限递归 |
3.图解
4.避免出现循环依赖的方式
- 拆分公共逻辑到新类 C，让 A 和 B 都依赖 C，而不是互相依赖
- 用依赖倒置原则，把高层模块的依赖抽象出来
- 把构造器注入改成
@Autowired字段 /setter 注入 - 延迟注入：用
@Lazy注解，注入时不立即初始化 Bean
5.补充
面试的过程中，提到一个为什么不使用二级缓存，为什么是三级缓存，解决了什么问题，当时说实话，这块确实忘了，今天再看才回忆起来，其实是因为要解决的是AOP的代理，因为二级缓存确实是可以解决了循环依赖，但是考虑到如果存在AOP代理的话，只用二级缓存是可能出现原始对象和代理对象不统一的，什么意思呢？注入的是a服务的半成品，此时AOP都是不生效的，但是最后生成了完整的a服务bean的时候是拥有AOP的代理对象的，所以会导致两者不一致。
以上是我个人的见解，欢迎交流留言！