Spring 循环依赖
循环依赖
多个bean。A 依赖 B，B 依赖 A，或者 C 依赖 C，就成了循环依赖。原因很简单，AB 循环依赖，A 实例化的时候，发现依赖 B，创建 B 实例，创建 B 的时候发现需要 A，创建 A1 实例……无限套娃。。。。
循环依赖只发生在 Singleton 作用域的 Bean 之间，因为如果是 Prototype 作用域的 Bean，Spring 会直接抛出异常。
Spring 可以解决哪些情况的循环依赖？
看看这几种情形（AB 循环依赖）：
也就是说：
- AB 均采用构造器注入，不支持
- AB 均采用 setter 注入，支持
- AB 均采用属性自动注入，支持
- A 中注入的 B 为 setter 注入，B 中注入的 A 为构造器注入，支持
- B 中注入的 A 为 setter 注入，A 中注入的 B 为构造器注入，不支持
第四种可以，第五种不可以的原因是 Spring 在创建 Bean 时默认会根据自然排序进行创建，所以 A 会先于 B 进行创建。
简单总结下，当循环依赖的实例都采用 setter 方法注入时，Spring 支持，都采用构造器注入的时候，不支持；构造器注入和 setter 注入同时存在的时候，看天
Spring 怎么解决循环依赖呢？
Spring 通过三级缓存机制来解决循环依赖：
- 一级缓存：存放完全初始化好的单例 Bean。
- 二级缓存：存放正在创建但未完全初始化的 Bean 实例。
- 三级缓存：存放 Bean 工厂对象，用于提前暴露 Bean。
三级缓存解决循环依赖的过程是什么样的？
- 实例化 Bean 时，将其早期引用放入三级缓存。
- 其他依赖该 Bean 的对象，可以从缓存中获取其引用。
- 初始化完成后，将 Bean 移入一级缓存。
其实就是三级缓存存了代理对象/原始对象的堆地址，初始化动作后移。 细节参考link
为什么要三级缓存？⼆级不⾏吗？
不行，主要是为了 ⽣成代理对象。如果是没有代理的情况下，使用二级缓存解决循环依赖也是 OK 的。但是如果存在代理，三级没有问题，二级就不行了。
因为三级缓存中放的是⽣成具体对象的匿名内部类，获取 Object 的时候，它可以⽣成代理对象，也可以返回普通对象。使⽤三级缓存主要是为了保证不管什么时候使⽤的都是⼀个对象。
当涉及到 AOP 时，三级缓存就显得非常重要了，因为它确保了即使在 Bean 的创建过程中有多次对早期引用的请求，也始终只返回同一个代理对象，从而避免了同一个 Bean 有多个代理对象的问题。
假设只有⼆级缓存的情况，往⼆级缓存中放的显示⼀个普通的 Bean 对象，Bean 初始化过程中，通过 BeanPostProcessor 去⽣成代理对象之后，覆盖掉⼆级缓存中的普通 Bean 对象，那么可能就导致取到的 Bean 对象不一致了。
如果缺少第二级缓存会有什么问题？
如果没有二级缓存，Spring 无法在未完成初始化的情况下暴露 Bean。会导致代理 Bean 的循环依赖问题，因为某些代理逻辑无法在三级缓存中提前暴露。最终可能抛出 BeanCurrentlyInCreationException。
@Lazy 能解决循环依赖吗？
@Lazy 用来标识类是否需要懒加载/延迟加载，可以作用在类上、方法上、构造器上、方法参数上、成员变量中。
Spring Boot 2.2 新增了全局懒加载属性，开启后全局 bean 被设置为懒加载，需要时再去创建。
如非必要，尽量不要用全局懒加载。全局懒加载会让 Bean 第一次使用的时候加载会变慢，并且它会延迟应用程序问题的发现（当 Bean 被初始化时，问题才会出现）。
如果一个 Bean 没有被标记为懒加载，那么它会在 Spring IoC 容器启动的过程中被创建和初始化。如果一个 Bean 被标记为懒加载，那么它不会在 Spring IoC 容器启动时立即实例化，而是在第一次被请求时才创建。这可以帮助减少应用启动时的初始化时间，也可以用来解决循环依赖问题。
Lazy 解决循环依赖的关键点在于代理对象的使用。
- 没有
@Lazy的情况下：在 Spring 容器初始化A时会立即尝试创建B，而在创建B的过程中又会尝试创建A，最终导致循环依赖（即无限递归，最终抛出异常）。 - 使用
@Lazy的情况下：Spring 不会立即创建B，而是会注入一个B的代理对象。由于此时B仍未被真正初始化，A的初始化可以顺利完成。等到A实例实际调用B的方法时，代理对象才会触发B的真正初始化。
@Lazy 能够在一定程度上打破循环依赖链，允许 Spring 容器顺利地完成 Bean 的创建和注入。但这并不是一个根本性的解决方案，尤其是在构造函数注入、复杂的多级依赖等场景中，@Lazy 无法有效地解决问题。因此，最佳实践仍然是尽量避免设计上的循环依赖。