大家好，我是锋哥。今天分享关于【Java高频面试题：SpringBoot为什么要禁止循环依赖?】面试题。希望对大家有帮助；
Java高频面试题：SpringBoot为什么要禁止循环依赖?
Spring Boot（实际上是其底层的 Spring Framework）默认禁止循环依赖，主要是基于以下核心原因：
设计缺陷的警示：
- 代码坏味道：循环依赖通常是不良设计的强烈信号。它表明类之间的职责划分不清晰、模块化程度低、耦合度过高。
- 违反单一职责原则：如果类需要相互依赖才能工作，很可能意味着它们承担了过多的职责，或者应该属于同一个逻辑单元（此时应该考虑重构）。
- 违反依赖倒置原则：高层模块和低层模块应该依赖于抽象，而不是具体实现。循环依赖往往意味着双方都直接依赖于对方的具体实现，使得代码难以解耦和测试。
运行时行为复杂性与不确定性：
- 初始化顺序难题：Spring 容器创建 Bean 的过程本质上是构建一个有向无环图。循环依赖打破了这种顺序性，使得确定哪个 Bean 应该先完全初始化变得极其复杂甚至不可能（尤其是在构造器注入的情况下）。
- 代理与 AOP 的陷阱：Spring AOP 通常通过创建代理对象（JDK 动态代理或 CGLIB）来实现。循环依赖可能导致代理对象在依赖注入时尚未完全准备好（例如，代理逻辑还未应用），从而引发难以预料的行为或错误（如
NullPointerException或方法拦截失效）。 - 微妙的 Bug：即使 Spring 通过“提前暴露引用”（三级缓存）机制部分解决了字段/Setter 注入的循环依赖，这种解决方式本身引入了额外的复杂性和潜在风险。依赖关系在 Bean 未完全初始化完成时就被设置，可能导致 Bean 处于一种“半成品”状态被使用，引发难以调试的并发问题或状态不一致。
可测试性降低：
- 高度耦合、相互依赖的类非常难以进行单元测试。测试一个类通常需要同时模拟或创建其依赖项，而如果这些依赖项又反向依赖它，测试设置会变得极其复杂甚至无法隔离。
可维护性与演化困难：
- 循环依赖使得代码库变得脆弱。修改一个类可能产生连锁反应，需要同时修改所有依赖它的类（包括那些它依赖的类），大大增加了维护成本和引入新错误的风险。
- 阻碍代码的重构和模块化。当类紧密耦合时，将它们提取到独立的模块或服务中会非常困难。
性能开销（次要但存在）：
- Spring 为了解决字段/Setter 注入的循环依赖，使用了额外的缓存机制（三级缓存）和更复杂的实例化逻辑。虽然现代 JVM 上这个开销通常不大，但在大规模应用中或对启动时间有严格要求时，避免不必要的复杂性总是好的。
Spring 如何处理循环依赖？
- 构造器注入：完全无法解决循环依赖如果发生在构造器参数上，Spring 会直接抛出
BeanCurrentlyInCreationException。因为 Java 对象构造必须完成才能使用，A 构造需要 B 实例，B 构造又需要 A 实例，形成死锁。 - 字段注入 / Setter 注入：Spring 使用“三级缓存”机制来有限度地解决这种循环依赖：
- 一级缓存 (Singleton Objects)：存放完全初始化好的单例 Bean。
- 二级缓存 (Early Singleton Objects)：存放提前暴露的、仅完成实例化（调用了构造器）但尚未进行属性填充和初始化方法的 Bean 的原始对象引用。
- 三级缓存 (Singleton Factories)：存放用于生成提前暴露代理对象的
ObjectFactory（如果需要 AOP 代理）。
- 过程简述：
- 创建 A，实例化（调用构造器），得到一个原始对象 A。
- 将 A 的
ObjectFactory放入三级缓存（如果需要代理，则工厂能生成代理；否则工厂直接返回原始对象）。 - 开始填充 A 的属性，发现需要 B。
- 创建 B，实例化（调用构造器），得到一个原始对象 B。
- 将 B 的
ObjectFactory放入三级缓存。 - 开始填充 B 的属性，发现需要 A。
- 从一级缓存找 A（没有）-> 从二级缓存找 A（没有）->从三级缓存找到 A 的
ObjectFactory，调用getObject()。 getObject()可能返回 A 的原始对象或早期代理对象，将这个对象放入二级缓存，同时从三级缓存移除 A 的工厂。- 将这个（可能是早期的）A 对象注入到 B 中。
- B 完成属性填充，执行初始化方法（
@PostConstruct,InitializingBean），成为一个完全初始化好的 Bean，放入一级缓存，清除二、三级缓存中 B 的相关条目。 - 此时 A 的属性 B 还未填充，将完全初始化好的 B 注入到 A 中。
- A 完成属性填充，执行初始化方法，成为一个完全初始化好的 Bean，放入一级缓存，清除二、三级缓存中 A 的相关条目。
为什么 Spring Boot 2.6+ 默认禁止？
- 强调最佳实践：Spring Boot 团队认为，虽然 Spring Framework 提供了解决部分循环依赖的机制，但这是一种妥协，掩盖了设计问题。默认禁止是为了引导开发者遵循更好的设计原则，写出低耦合、高内聚、易于测试和维护的代码。
- 减少陷阱：如前所述，即使解决了，循环依赖（尤其是涉及代理时）可能导致难以诊断的运行时问题。默认禁止可以减少开发者掉入这些陷阱的概率。
- 推动健康架构：鼓励使用清晰的依赖方向、接口抽象、事件驱动、回调机制（如
ApplicationEventPublisher）或重新设计职责划分来避免循环依赖，从而构建更健壮、可扩展的应用。
如何应对？
- 重构设计（首选）：
- 重新审视类的职责，尝试提取公共功能到第三个类中。
- 使用接口抽象，让依赖方依赖于接口，实现方实现接口，打破具体类之间的循环。
- 引入事件/消息机制（如 Spring Events,
ApplicationEventPublisher），让一方完成工作后发布事件，另一方监听事件并响应，代替直接方法调用。 - 应用依赖倒置原则，通过接口或抽象类定义依赖关系。
- 考虑服务/功能拆分，将紧密耦合的部分合并或拆分成更合理的模块。
- 谨慎使用
@Lazy：在其中一个注入点（通常是字段或 Setter 参数）上使用@Lazy注解。这会告诉 Spring 注入一个代理对象，该代理在第一次实际使用时才会去解析真正的依赖。这可以打破初始化时的死锁，但只是延迟了问题的爆发点，并没有真正解决设计问题，且可能引入代理相关的复杂性。应视为临时解决方案或最后手段。 - 显式允许循环依赖（不推荐）：如果必须保留循环依赖（通常有历史包袱或特殊原因），可以在 Spring Boot 配置中显式开启：
强烈建议仅在充分理解风险、且暂时无法重构的情况下使用此选项，并应尽快计划重构以消除循环依赖。spring.main.allow-circular-references=true
总结：
Spring Boot 默认禁止循环依赖，核心目的是为了促进良好的软件设计实践，避免由循环依赖带来的运行时复杂性、不确定性、可测试性差和可维护性低等问题。它强制开发者面对设计上的缺陷（循环依赖是症状），并通过重构（如提取接口、引入事件、重新划分职责）来创建更健康、更健壮的应用程序。虽然 Spring 提供了机制（三级缓存）和变通方法（@Lazy, 配置开关）来处理某些情况下的循环依赖，但这些都应被视为权宜之计而非最佳实践。
