Spring循环依赖难道只能通过两个Setter注入解决嘛？

原创 已于 2022-02-24 19:31:46 修改 · 1.2k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#spring #java #后端 #循环依赖 #spring boot

于 2022-02-24 19:29:36 首次发布
本文探讨了Spring中循环依赖问题的解决方案，指出构造器注入与Setter注入结合能有效避免报错，关键在于控制依赖加载顺序。

Spring循环依赖难道只能通过两个Setter注入解决嘛？

先说结论：并不是，可以是一个setter和一个构造器

如果存在循环依赖的对象关系的话，位置靠上的类会先进行生命周期的加载

所以位置靠上的类必须通过set注入其他属性，这样才不会导致循环依赖的报错

前言

其实想到这个问题是由于网上给出的结论是

于是我便好奇了起来：为什么同样是一个通过Setter注入、一个通过构造器注入，会有两种不同的结果呢？

Setter注入与构造器注入

首先我们先明确哪种是setter注入，哪种是构造器注入

//setter注入
@Autowired
private B b;

//构造器注入
@Autowired
public B(A a) {
    this.a = a;
}

为什么可以一个通过set和一个通过构造器进行注入也不会导致循环依赖的报错

Spring默认在package从上至下加载Bean的生命周期：创建->注入->初始化完成
我们假设代码中，A所在位置在B上方

先构造器注入，再set注入

条件：A是构造器注入，B是set注入

由于A在上方那么会先进行A的生命周期

A在构造器创建实例时，由于容器中B是空的，导致A无法通过构造器创建对象，于是报错

即使为A添加了空参构造器也无济于事，因为使用构造器注入会先行调用有参构造器

先set注入，再构造器注入

条件：A是set注入，B是构造器注入

由于A在上方还是会先进行A的生命周期

此时，由于A有默认的无参构造器直接创建一个空对象放入了三级缓存，为其注入B时，发现容器中B是空的

于是开始B的生命周期，因为在三级缓存中A已经存在，所以B可以直接根据这个对象去通过构造器实例化

实际上是会因为引用了A，为A执行一个提前引用来创建一个动态代理对象放入二级缓存中，然后将二级缓存中A的代理对象给B，这里为了方便理解直接忽略了动态代理这一层缓存

于是B被创建、注入、初始化完成后加入到一级缓存，此时又来到了A的注入阶段，直接将B注入

于是A经过注入与初始化后，也加入到了IOC容器中，至此不会导致报错

所以可以得出结论：并不是只能通过两个Setter注入才能解决循环依赖的问题，也可以是一个setter和一个构造器

如果存在循环依赖的对象关系的话，位置靠上的类会先进行生命周期的加载

所以位置靠上的类必须通过set注入其他属性，这样才不会导致循环依赖的报错

结论依据：

  • 可以通过实现BeanPostProcessor前置调用类的方法将所有Bean依次输出
  • 也可以通过实现BeanNameAware的方法输出Bean的名称

总之我们会发现是B先被初始化完成后才初始化完成了A
所以是先创建了A，然后为其注入B时，启动了B的完整的一个生命周期，才会是B先被初始化完成的这样一个结果

Spring框架中的循环依赖与Setter注入示例解析
m0_62153576的博客
08-23 658
循环依赖发生在两个或多个bean相互依赖对方，形成一个闭环。Spring容器在创建这些bean时，会因为无法解决这种循环引用而抛出异常。首先是Car和Driver两个类的定义，它们通过Setter方法相互注入。
Spring循环依赖的解决办法,你真的懂了吗
08-19
Spring循环依赖的解决办法 Spring框架中，循环依赖是指两个或多个Bean相互引用，形成一个环。这篇文章主要介绍了Spring循环依赖的解决办法。在Spring中，循环依赖可以分为两种场景：构造器的循环依赖和属性的循环...
肝！！！瞎扯，Spring只能解决setter注入方式的循环依赖？不存在的！
qq_31426247的博客
06-20 863
别的先不扯，先上结论 方式 依赖情况 注入方式 能够解决循环依赖 情况一 AB相互依赖 均采用setter方式 能 情况二 AB相互依赖 均采用构造器方式 不能 情况三 AB相互依赖 A中注入B采用setter，B中注入A采用构造器 能 情况四 AB相互依赖 A中注入B采用构造器，B中注入A采用setter 不能 测试数据 <bean id="a" class="com.ziyang.cycle.A"> <constructor-arg r
Spring 循环依赖解决方案（只对 setter 注入有效）
qq_44851477的博客
07-05 452
Spring 循环依赖
Spring源码分析之单型模式Setter注入下的循环依赖
疾风丶Sao年的IT博客
04-08 1118
摘要：Spring中总共有三种循环依赖，原型模式的循环依赖，单例模式的构造器循环依赖，单例模式的Setter注入循环依赖。 前面两种我已经写过了，在这里附上链接，有兴趣的可以去了解下，今天会将最后一种，也算是比较重要的一种。 原型模式的循环依赖：https://blog.youkuaiyun.com/lkp_kapila/article/details/105344252 单例模式的构造器循环依赖：h...
【源码分析】Spring的循环依赖（setter注入、构造器注入、多例、AOP）
weixin_45654405的博客
10-30 2292
- Spring是所有对象都是通过getBean去获取的，即从三级缓存里面找，如果有就直接从缓存池中获取并返回，没有就执行创建 - 对象创建的顺序决定了Spring能解决setter注入的循环依赖，而不能解决构造器注入的循环依赖。 - 当发生了Spring无法解决的循环依赖时，会通过一些标记检测出来，并抛异常结束程序。 - 三级缓存中存放的是ObjectFactory而不是Object - 无论有没有发生循环依赖，都会将实例化完的对象放入三级缓存池中，因为放入三级缓存池时并不知道会不会发生循环依赖。
Spring如何解决循环依赖和循环依赖问题解决
刘皇叔说Java的博客
05-11 2513
要普通对象和代理对象是不能同时出现在容器中的，因此当一个对象需要被代理时，就要使用代理对象覆盖掉之前的普通对象，在实际的调用过程中，是没有办法确定什么时候对象被使用，所以就要求当某个对象被调用的时候，优先判断此对象是否被代理，类似于一种回调机制的实现，因此传入lambda表达式的时候，可以通过lambda表达式来执行对象的覆盖过程，getEarlyBeanReference（）单例的Bean被创建后就被存放在一级缓存中，其实就是一个Map，只要这个单例bean被创建后，以后再次获取直接从Map中获取。
Spring如何解决循环依赖的问题
09-07
对于赋值属性循环依赖，即依赖对象通过setter方法注入，Spring采取了一种特殊策略来解决单例模式下的循环依赖。Spring维护了一个bean创建过程中的缓存，当一个单例bean正在创建时，会将其临时暴露给其他bean引用。...
基于SpringBoot构造器注入循环依赖及解决方式
09-16
这样，Spring可以在bean创建后，且在需要时才执行setter注入，从而避免了循环依赖的问题。 总结来说，处理SpringBoot中的构造器注入循环依赖需要理解依赖注入的工作原理，并灵活运用各种策略，包括但不限于重新设计...
spring循环注入异常问题的解决方案
08-26
当两个或多个bean相互依赖，形成一个闭环，就会触发Spring报出"BeanCurrentlyInCreationException"异常，提示存在无法解决的循环引用。循环注入分为两种类型：构造器循环依赖和setter方法循环依赖。 首先，我们来...
Spring中的循环依赖问题
Fvemim的博客
07-22 2451
关于Spring中的循环依赖问题和Spring解决循环依赖的方法
# spring注入方式和带来的循环依赖问题
qq_39855224的博客
12-08 462
本文将对单例模式和多例模式进行解释，并演示set注入和构造注入，和set注入和构造注入带来的循环依赖问题。
Spring 是怎么处理循环依赖的？
m0_56069948的博客
02-13 288
Python微信订餐小程序课程视频 https://edu.youkuaiyun.com/course/detail/36074 Python实战量化交易理财系统 https://edu.youkuaiyun.com/course/detail/35475 Java语法中的循环依赖 首先看一个使用构造函数的循环依赖，如下： public class ObjectA { private ObjectB b; public ObjectA(ObjectB b) { this.b = b; } }
怎么解决set注入造成的循环依赖
weixin_42226712的博客
03-14 1009
怎么解决set注入造成的循环依赖 靠三级缓存区解决的，A,B两个类，A中有B，B中有A，都是通过setter方法进行依赖注入的。先去实例化A的实例，根据A的beanDefinition定义 拿到A class的无参构造方法后，反射创建出来了A的实例对象，这时候A的实例对象，是一个尚未进行依赖注入和init-method方法调用等等逻辑处理的早期实例，他还不能让业务层直接拿来去用，可以理解为早产儿，在进行后续加工处理之前，会把这个早产儿包装到一个ObjectFactory对象内，然后存放到spring的第三级
一篇文章秒杀Spring循环依赖
KKK
12-28 890
秒杀Spirng循环依赖
循环依赖解决
01-30 2490
循环依赖解决 什么是循环依赖 如A依赖B,B依赖A，在A依赖注入时需要B，然后就去创建B，这时候发现又需要依赖注入 A ，这样就导致了循环依赖。 Spring创建Bean的过程大致为实例化->依赖注入->初始化，所以可以利用在实例化之后，依赖注入之前这段时间的间隙，将只实例化但未属性填充的的bean的ObjectFactory放到缓存中提前曝光，之后的对象可从缓存中获取提前曝光的对象进行属性填充。 虽然填充的不是完整的对象，但是由于bean是单例的，所以后续初始化完成后， bean 实例的引用
springboot如何解决循环依赖
m0_53752334的博客
08-07 3321
Spring如何解决循环依赖
SpringBoot构造器注入循环依赖及解决
热门推荐
Revivedsun的专栏
11-30 3万+
1. 循环依赖是什么？ Bean A 依赖 B，Bean B 依赖 A这种情况下出现循环依赖。 Bean A → Bean B → Bean A 更复杂的间接依赖造成的循环依赖如下。 Bean A → Bean B → Bean C → Bean D → Bean E → Bean A 2. 循环依赖会产生什么结果？ 当Spring正在加载所有Bean时，Spring尝试以能正常创建Bean的顺序...
spring改成setter注入能解决循环依赖吗
最新发布
04-13
<think>好的，我现在需要回答用户关于Spring框架中使用setter注入是否能解决循环依赖的问题。首先，我要回忆一下Spring的依赖注入机制，尤其是构造器注入和setter注入的区别。 用户提到的引用[3]指出，循环依赖发生在两个或多个bean通过构造器相互注入。这时候Spring无法解决，因为构造器注入在实例化bean时必须立即注入依赖，导致循环无法打破。而引用[1]提到，使用setter注入可能是一个解决办法，因为它允许在对象实例化后设置依赖，从而避免了构造器注入的立即性要求。 接下来，我需要理解Spring的三级缓存机制。引用[2]提到，三级缓存（singletonFactories）用于处理存在动态代理的情况。当bean还在创建过程中时，Spring会将未完成初始化的bean提前暴露到缓存中，这样其他bean可以引用这个半成品，之后再通过setter完成依赖注入。这个过程允许循环依赖在setter注入的情况下被解决，因为依赖的设置可以延后到实例化之后。 然后，我需要验证这个机制是否真的适用于setter注入。根据Spring官方文档，当使用setter注入时，Spring先实例化bean，然后在后续步骤中通过setter方法注入依赖。因此，如果两个bean都使用setter注入，Spring可以先将它们的实例创建出来（此时属性尚未设置），然后将这些半成品bean放入缓存，之后在注入阶段再互相设置依赖。这样就避免了构造器注入时的循环问题。 另外，用户提供的引用[1]建议使用setter注入来配置循环依赖，虽然不推荐，但技术上可行。这说明虽然Spring不鼓励循环依赖，但在某些情况下，setter注入确实能绕过构造器注入的限制。 总结一下，用户的问题核心是确认setter注入是否能解决循环依赖。根据引用和Spring机制，答案应该是肯定的，但需要明确其限制和潜在问题，比如可能隐藏设计缺陷，增加维护难度等。因此，在回答时需要说明setter注入如何通过延迟依赖注入来解决循环问题，同时提醒用户应优先考虑代码结构优化。</think>在Spring框架中，**通过setter注入可以解决部分循环依赖问题**，但需结合Spring的三级缓存机制实现。以下是具体分析： --- ### 一、循环依赖的产生条件 当两个Bean通过**构造器注入**相互依赖时，Spring无法解决循环依赖[^3]。例如： ```java // BeanA通过构造器注入BeanB public class BeanA { private BeanB b; public BeanA(BeanB b) { this.b = b; } } // BeanB通过构造器注入BeanA public class BeanB { private BeanA a; public BeanB(BeanA a) { this.a = a; } } ``` 此时Spring会直接抛出`BeanCurrentlyInCreationException`。 --- ### 二、setter注入的解决机制 若改用**setter注入**，Spring通过以下步骤实现依赖解析： 1. **提前暴露半成品对象** Spring在实例化Bean后（但未完成属性注入）时，将对象存入三级缓存`singletonFactories`[^2]。例如： ```java // BeanA通过setter注入BeanB public class BeanA { private BeanB b; public void setB(BeanB b) { this.b = b; } } ``` 2. **分阶段完成依赖注入** - 先创建`BeanA`实例（此时`BeanB`属性为空） - 将`BeanA`的引用存入缓存 - 创建`BeanB`实例时，从缓存获取`BeanA`的引用并注入 - 最后通过setter完成`BeanA`对`BeanB`的注入 --- ### 三、实现条件与限制 | 方案 | 可行性 | 限制条件 | |--------------------|--------|----------------------------------| | 纯构造器注入 | ❌ | 必然失败 | | setter注入 | ✅ | 需配合Spring三级缓存机制[^2] | | 字段注入（@Autowired）| ✅ | 底层实现与setter注入类似 | --- ### 四、潜在风险与建议 1. **设计缺陷的掩盖** 循环依赖通常意味着代码存在职责划分问题，强行解决可能降低可维护性。 2. **动态代理的兼容性** 若Bean需要AOP动态代理，必须通过`@Lazy`或接口代理确保代理对象正确生成[^2]。 3. **官方建议** Spring官方文档明确指出应尽量避免循环依赖，重构代码结构是更优解[^3]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值