Springboot循环依赖的解决方式
起因
今天重构代码时,发现之前的代码结构完全混乱,没有按照MVC分层思想去编写,很多业务逻辑写在了controller中,导致引用的很多service和mapper依赖被注入到controller中。所以我准备将业务转移到service中,结果在改完代码准备debug启动的时候发现项目起不来了!springboot报错循环依赖,所以今天记录一下发生的原因和可用的解决方案。
原因
这个其实我也不好说,我自己写代码从来没有发现有循环依赖的问题,每个类确定好自己的职责,将方法正确的放入该类去引用bean一般就不会出现这种问题。。。这里我就描述一下循环依赖的产生吧,就是在容器启动过程准备bean的时候,会检测bean中是否注入了别的依赖,如果有就再去生成别的依赖对象注入到bean中,但是会发生这么一种情况,我有A,B两个@service,在A类中我通过注解引入B,然后再在B类中通过注解引入A,这个时候理论上就会无限产生A和B的实例,递归创建bean了属于是
下图我在一个Springboot项目中创建了A和B两个类,都加入了@Component注解并分别在其中注入另一个类
接下来启动该项目控制台报错:
根据提示可以很明显的看到,A依赖B,B依赖A导致循环
解决方案
配置文件解决
可以在配置文件中进行如下配置允许项目出现循环依赖:
spring:
main:
allow-circular-references: true
但是不推荐这样,因为出现循环依赖应该是代码结构不规范导致的问题,如果有充足时间的话应该找出原因并优化,确保每个bean各司其职,一层一层依赖。
以下GPT回答:
为什么通常不推荐使用 allow-circular-references: true
代码可读性和可维护性:循环依赖使得代码结构复杂,增加了理解和维护的难度。
生命周期问题:当 Bean 之间存在循环依赖时,Spring 必须使用代理来处理这些问题,这可能导致 Bean 生命周期管理的复杂性。
性能影响:处理循环依赖会增加 Spring 创建 Bean 的开销,尤其是在大型应用中。
调试困难:循环依赖可能导致难以追踪的问题,尤其是当问题与特定环境或配置有关时
使用工具类获取bean
这种方式是使用SpringBeanUtil(一种可以获取Spring容器中bean的工具类,网上有很多)在业务代码中实时获取bean的方式,这种方式不需要在B类中注入A了,只需要在A类方法被调用之前获取到该bean即可
还有一种我设想的方案
这种不建议使用,原理是通过Springboot项目完全启动后(bean都生成完毕)执行的代码中使用SpringBeanUtil获取你想要的bean,然后通过set方法去注入所需要的bean实例,但是这种方式不太靠谱,因为项目完全启动后可能都接到请求了,如果在业务执行过程中你还没注入完毕的话很有可能导致NPE。。。