1. Spring循环依赖的本质与场景循环依赖指的是两个或多个Bean相互依赖形成闭环的情况。比如Bean A依赖Bean B同时Bean B又依赖Bean A。这种场景在实际开发中并不少见特别是在大型项目中模块划分不够清晰时更容易出现。Spring框架处理循环依赖的核心机制建立在三个关键点上三级缓存结构singletonFactories、earlySingletonObjects、singletonObjectsBean生命周期的阶段性处理提前暴露未完成初始化的Bean引用典型的发生场景包括服务层相互调用如OrderService调用UserService同时UserService又需要OrderService配置类之间的交叉引用父子上下文之间的Bean依赖2. Spring解决循环依赖的底层原理2.1 三级缓存工作机制Spring通过三级缓存解决setter注入的循环依赖问题singletonObjects存储完全初始化好的单例BeanearlySingletonObjects存储提前暴露的原始Bean已实例化但未初始化singletonFactories存储Bean工厂对象用于生成原始Bean的代理对象处理流程示例// 创建Bean A的流程 1. 实例化A调用构造函数 2. 将A的ObjectFactory放入三级缓存 3. 填充A的属性时发现需要B 4. 开始创建B 5. B填充属性时从三级缓存获取A的早期引用 6. B完成初始化 7. A获取到B的实例继续完成初始化 8. A完全初始化后放入一级缓存2.2 构造器注入的限制Spring无法解决构造器注入的循环依赖因为构造器注入需要在实例化阶段就完成依赖注入此时Bean还未创建无法提前暴露引用会直接抛出BeanCurrentlyInCreationException3. 循环依赖的实战处理方案3.1 代码层面的解决方案使用Lazy注解Service public class ServiceA { Lazy // 延迟初始化 Autowired private ServiceB serviceB; }改为setter注入Service public class ServiceA { private ServiceB serviceB; Autowired public void setServiceB(ServiceB serviceB) { this.serviceB serviceB; } }使用ApplicationContext主动获取Service public class ServiceA implements ApplicationContextAware { private ApplicationContext context; public ServiceB getServiceB() { return context.getBean(ServiceB.class); } }3.2 架构层面的优化提取公共逻辑到新Service使用事件驱动架构ApplicationEvent引入门面模式统一对外接口合理划分模块边界4. 循环依赖的调试与排查4.1 常见异常分析BeanCurrentlyInCreationException构造器注入导致的循环依赖解决方案改为setter注入或使用LazyNoSuchBeanDefinitionException配置错误导致的依赖缺失检查ComponentScan范围4.2 调试技巧开启Spring调试日志logging.level.org.springframework.beansDEBUG使用断点观察AbstractAutowireCapableBeanFactory#doCreateBeanDefaultSingletonBeanRegistry#getSingleton可视化工具Spring Boot Actuator的/beans端点IDEA的Spring Beans视图5. 高级应用场景与限制5.1 原型(Prototype)作用域的循环依赖Spring无法解决原型Bean的循环依赖因为每次获取都会创建新实例无法通过缓存提前暴露引用解决方案改为单例或重构设计5.2 AOP代理下的特殊处理当存在AOP代理时Spring会通过SmartInstantiationAwareBeanPostProcessor提前生成代理对象。关键实现类AbstractAutoProxyCreatorAnnotationAwareAspectJAutoProxyCreator5.3 多数据源事务中的循环依赖典型问题场景Transactional Service public class ServiceA { Autowired private ServiceB serviceB; // 同样有Transactional }解决方案使用编程式事务管理调整事务传播级别分离事务操作到新Service6. 最佳实践与性能考量设计原则遵循单一职责原则保持依赖方向一致性上层→下层避免双向依赖性能影响循环依赖会增加启动时间可能影响内存使用缓存未完成Bean建议在开发阶段通过Spring Boot的启动指标监控检测工具ArchUnit测试验证架构约束SonarQube循环依赖检测IDEA的依赖分析工具关键提示虽然Spring提供了循环依赖的解决方案但从设计模式角度仍应尽量避免。良好的架构设计应该通过清晰的层次划分来消除循环依赖。 Spring循环依赖原理与解决方案详解
1. Spring循环依赖的本质与场景循环依赖指的是两个或多个Bean相互依赖形成闭环的情况。比如Bean A依赖Bean B同时Bean B又依赖Bean A。这种场景在实际开发中并不少见特别是在大型项目中模块划分不够清晰时更容易出现。Spring框架处理循环依赖的核心机制建立在三个关键点上三级缓存结构singletonFactories、earlySingletonObjects、singletonObjectsBean生命周期的阶段性处理提前暴露未完成初始化的Bean引用典型的发生场景包括服务层相互调用如OrderService调用UserService同时UserService又需要OrderService配置类之间的交叉引用父子上下文之间的Bean依赖2. Spring解决循环依赖的底层原理2.1 三级缓存工作机制Spring通过三级缓存解决setter注入的循环依赖问题singletonObjects存储完全初始化好的单例BeanearlySingletonObjects存储提前暴露的原始Bean已实例化但未初始化singletonFactories存储Bean工厂对象用于生成原始Bean的代理对象处理流程示例// 创建Bean A的流程 1. 实例化A调用构造函数 2. 将A的ObjectFactory放入三级缓存 3. 填充A的属性时发现需要B 4. 开始创建B 5. B填充属性时从三级缓存获取A的早期引用 6. B完成初始化 7. A获取到B的实例继续完成初始化 8. A完全初始化后放入一级缓存2.2 构造器注入的限制Spring无法解决构造器注入的循环依赖因为构造器注入需要在实例化阶段就完成依赖注入此时Bean还未创建无法提前暴露引用会直接抛出BeanCurrentlyInCreationException3. 循环依赖的实战处理方案3.1 代码层面的解决方案使用Lazy注解Service public class ServiceA { Lazy // 延迟初始化 Autowired private ServiceB serviceB; }改为setter注入Service public class ServiceA { private ServiceB serviceB; Autowired public void setServiceB(ServiceB serviceB) { this.serviceB serviceB; } }使用ApplicationContext主动获取Service public class ServiceA implements ApplicationContextAware { private ApplicationContext context; public ServiceB getServiceB() { return context.getBean(ServiceB.class); } }3.2 架构层面的优化提取公共逻辑到新Service使用事件驱动架构ApplicationEvent引入门面模式统一对外接口合理划分模块边界4. 循环依赖的调试与排查4.1 常见异常分析BeanCurrentlyInCreationException构造器注入导致的循环依赖解决方案改为setter注入或使用LazyNoSuchBeanDefinitionException配置错误导致的依赖缺失检查ComponentScan范围4.2 调试技巧开启Spring调试日志logging.level.org.springframework.beansDEBUG使用断点观察AbstractAutowireCapableBeanFactory#doCreateBeanDefaultSingletonBeanRegistry#getSingleton可视化工具Spring Boot Actuator的/beans端点IDEA的Spring Beans视图5. 高级应用场景与限制5.1 原型(Prototype)作用域的循环依赖Spring无法解决原型Bean的循环依赖因为每次获取都会创建新实例无法通过缓存提前暴露引用解决方案改为单例或重构设计5.2 AOP代理下的特殊处理当存在AOP代理时Spring会通过SmartInstantiationAwareBeanPostProcessor提前生成代理对象。关键实现类AbstractAutoProxyCreatorAnnotationAwareAspectJAutoProxyCreator5.3 多数据源事务中的循环依赖典型问题场景Transactional Service public class ServiceA { Autowired private ServiceB serviceB; // 同样有Transactional }解决方案使用编程式事务管理调整事务传播级别分离事务操作到新Service6. 最佳实践与性能考量设计原则遵循单一职责原则保持依赖方向一致性上层→下层避免双向依赖性能影响循环依赖会增加启动时间可能影响内存使用缓存未完成Bean建议在开发阶段通过Spring Boot的启动指标监控检测工具ArchUnit测试验证架构约束SonarQube循环依赖检测IDEA的依赖分析工具关键提示虽然Spring提供了循环依赖的解决方案但从设计模式角度仍应尽量避免。良好的架构设计应该通过清晰的层次划分来消除循环依赖。