如上代码所示,即 A 里面注入 B,B 里面又注入 A。此时,就发生了「循环依赖」。
前言 相信很多小伙伴在工作中都会遇到循环依赖,不过大多数它是这样显示的: 还会提示这么一句: Requested bean is currently in creation: Is there an
循环依赖,其实就是循环引用,就是两个或者两个以上的 bean 互相引用对方,最终形成一个闭环,如 A 依赖 B,B 依赖 C,C 依赖 A。如下图所示:
从字面上来理解就是A依赖B的同时B也依赖了A,就像上面这样,或者C依赖与自己本身。体现到代码层次就是这个样子
做 Java 开发的,一般都绕不开 Spring,那么面试中肯定会被问到 Spring 的相关内容,而循环依赖又是 Spring 中的高频面试题
面试官:“三级缓存是怎么处理的?为什么一定得是三级缓存?三级缓存别是对应存储的是什么?”
大家好。我们都知道,Spring可以通过三级缓存解决循环依赖的问题,这也是面试中很常见的一个面试题,本文就来着重讨论一下有关循环依赖和三级缓存的问题。
在Spring框架中,依赖注入(Dependency Injection, DI)是其核心功能之一,它通过配置来管理对象的创建和它们之间的依赖关系。然而,在复杂的应用程序中,开发人员有时会遇到循环依赖的问题,即Bean A依赖于Bean B,而Bean B又依赖于Bean A。如果不加以处理,这种情况会导致应用程序无法启动。在本文中,我们将深入探讨Spring循环依赖的原理、处理机制、最佳实践以及可能遇到的问题。
前一段时间,阿粉的读者给阿粉留言,说在面试的时候,有个面试官就问她,Spring 的各种知识,Spring 的生命周期, Spring 的循环依赖是如何解决的。
Spring中的循环依赖一直是Spring中一个很重要的话题,一方面是因为源码中为了解决循环依赖做了很多处理,另外一方面是因为面试的时候,如果问到Spring中比较高阶的问题,那么循环依赖必定逃不掉。如果你回答得好,那么这就是你的必杀技,反正,那就是面试官的必杀技,这也是取这个标题的原因,当然,本文的目的是为了让你在之后的所有面试中能多一个必杀技,专门用来绝杀面试官!
当你听到三级缓存的时候,你在想什么?你了解过的有哪些三级缓存?CPU三级缓存?Spring三级缓存?应用架构(JVM、分布式缓存、db)三级缓存?今天爬完香山,趁自己还不困的时候,把三级缓存的一些重点絮叨絮叨。离 CPU 核心越近,缓存的读写速度就越快。但 CPU 的空间很狭小,离 CPU 越近缓存大小受到的限制也越大。所以,综合硬件布局、性能等因素,CPU 缓存通常分为大小不等的三级缓存。三级缓存要比一、二级缓存大许多倍,这是因为当下的 CPU 都是多核心的,每个核心都有自己的一、二级缓存,但三级缓存却是一颗 CPU 上所有核心共享的。
通俗来讲,循环依赖指的是一个实例或多个实例存在相互依赖的关系(类之间循环嵌套引用)。
在日常开发中,Bean之间的循环依赖非常常见,Spring 已经帮我们做到使用无感知处理,那么 Spring 是如何实现的呢?
这个例子存在的问题:理论上spring创建A的时候依赖了B,然后spring就会去加载B,但是这个时候B又依赖了A,spring又去加载A,就会陷入一个死循环,但我们在实际使用spring的时候并没有出现这样的循环,这是因为spring设计之初就考虑了这个问题,那么spring是如何解决的呢?我们先要明确的是spring对循环依赖的处理有三种情况,分别为
一级缓存里存的是成品对象,实例化和初始化都完成了,我们的应用中使用的对象就是一级缓存中的
实例化: Spring 根据 Bean 的配置信息创建一个实例。这个实例还没有进行属性注入和初始化。
当你听到三级缓存的时候,你在想什么?你了解过的有哪些三级缓存?CPU三级缓存?Spring三级缓存?应用架构(JVM、分布式缓存、db)三级缓存?今天爬完香山,趁自己还不困的时候,把三级缓存的一些重点絮叨絮叨。
那Spring到底是如何解决的setter方法依赖注入引起的循环依赖问题呢?请看下图(其实主要是通过两个缓存来解决的):
初学 Spring 的时候,我们就知道 IOC,控制反转么,它将原本在程序中手动创建对象的控制权,交由 Spring 框架来管理,不需要我们手动去各种 new XXX。
前置知识: 所谓的 三级缓存只是三个可以当作是全局变量的Map,Spring的源码中大量使用了这种 先将数据放入容器中等使用结束再销毁的代码风格
循环依赖是指在Spring容器中,两个或多个bean互相持有对方,最终形成闭环。Spring容器无法创建这样的循环依赖,因为它会破坏依赖关系链。
只有单例的Bean才存在循环依赖的情况,原型(Prototype)情况下,Spring会直接抛出异常。原因很简单,AB循环依赖,A实例化的时候,发现依赖B,创建B实例,创建B的时候发现需要A,创建A1实例……无限套娃,直接把系统干垮。
1,createBeanInstance:实例化,其实也就是调用对象的构造方法实例化对象
我们在使用Spring框架的日常开发中,bean之间的循环依赖太频繁了,Spring已经帮我们去解决循环依赖问题,对我们开发者来说是无感知的,下面具体分析一下Spring是如何解决bean之间循环依赖,为什么要使用到三级缓存,而不是二级缓存?
1、Husband创建Bean,先判断缓存池中是否存在,存在直接返回,不存在进入createBean创建的流程,调用构造方法创建一个早期的Bean【未进行属性赋值】,创建成功将其放入二级缓存earlySingletonObjects中,之后又调用addSingletonFactory方法将其放入三级缓存中并且将二级缓存中的移除,之后调用populateBean为属性赋值,在@Autowired的后置处理器中查找需要注入的依赖,发现Husband中的一个属性Wife,因此调用getBean方法从容器中获取,但是此时的Wife还未创建,因此又进入了doGetBean的流程,但是此时Wife并没有创建,因此在一二三级缓存中不能获取,又执行createBean方法创建Wife,同样调用构造方法创建一个早期Bean放入二级缓存中,调用addSingletonFactory放入三级缓存并移除二级缓存,然后调用populateBean方法为Wife属性赋值,在@Autowired的后置处理器中查找需要注入的依赖,发现Wife类中有一个属性是Husband,因此调用getBean方法,再次调用doGetBean获取Husband,但是此时的Husband已经创建成功【未赋值】,存放在三级缓存中,因此直接从三级缓存中取出Husband赋值给Wife属性,至此Wife属性已经赋值成功,直接添加到一级缓存(singletonObjects)中并且移除三级缓存,直接返回给Husband赋值,因此Husband中的属性也持有了Wife的引用,都创建并且赋值成功了。
在探讨Spring三级缓存解决循环引用之前,我们需要了解一点就是Spring所谓的循环依赖到底是什么,是如何产生的,为什么会产生这种问题?
这里是TestA调用了TestB,TestB里面又调用了TestA。是一个典型的循环依赖场景,但是我们知道Spring对于循环依赖问题是做了处理的。但是这里为什么会报错?
在Spring框架中,循环依赖(Circular Dependency)是一个常见的概念,它指的是两个或多个bean相互依赖对方,形成了一个闭环。例如,Bean A依赖于Bean B,而Bean B又依赖于Bean A。Spring容器默认可以处理单例(singleton)作用域下的构造器注入(constructor injection)的循环依赖,但是通过setter注入(setter injection)或原型(prototype)作用域下的循环依赖则可能导致问题。
精读文章:Dependency Injection in JS/TS – Part 1
循环依赖就是多个Bean之间存在相互依赖,形成一个闭环,如下,PostService和UserService之间就存在相互依赖,这个依赖并不是方法 之间的依赖,而是Bean与Bean之间的依赖。
循环依赖其实就是循环引⽤,也就是两个或者两个以上的 Bean 互相持有对⽅,最终形成闭环。⽐如A依赖于B,B依赖于C,C⼜依赖于A
第一篇: 3.1 spring5源码系列--循环依赖 之 手写代码模拟spring循环依赖
但即使有三级缓存也无法解决构造器的循环依赖, 对象无法正常实例化, 没有操作的空间
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
当多个Bean相互依赖时则构成了循环依赖,例如A,B两个Bean。其中A中存在属性B,B中存在属性A,当Spring在实例化A时发现A中存在属性B,就去实例化B,实例化B时又发现存在属性A,一直在循环注入依赖,导致循环依赖问题出现。
支持不支持循环引用this.allowCircularReferences这个参数,可以在之前将参数修改为false;
当Bean产生循环依赖时,比如BeanA的构造方法依赖BeanB作为成员需要注入,BeanB也依赖BeanA,你觉得会出现什么问题呢?又有哪些解决方式呢?
问:Spring如何解决循环依赖? 答:Spring通过提前曝光机制,利用三级缓存解决循环依赖(这原理还是挺简单的,参考:三级缓存、图解循环依赖原理) 再问:Spring通过提前曝光,直接曝光到二级缓存已经可以解决循环依赖问题了,为什么一定要三级缓存? 再细问:如果循环依赖的时候,所有类又都需要Spring AOP自动代理,那Spring如何提前曝光?曝光的是原始bean还是代理后的bean?
在正式研究Spring如何解决循环依赖之前,不如我们就假设spring目前没有提供三级缓存来解决循环依赖,那么目前spring的getBean流程图就如下所示:
在实际工作中,经常由于设计不佳或者各种因素,导致类之间相互依赖。这些类可能单独使用时不会出问题,但是在使用Spring进行管理的时候可能就会抛出BeanCurrentlyInCreationException等异常 。当抛出这种异常时表示Spring解决不了该循环依赖,本文将简要说明Spring对于循环依赖的解决方法。
这个其实是一个特别高频的面试题,松哥也一直很想和大家仔细来聊一聊这个话题,网上关于这块的文章很多,但是我一直觉得要把这个问题讲清楚还有点难度,今天我来试一试,看能不能和小伙伴们把这个问题梳理清楚。
如果在代码中将两个或多个 Bean 互相之间持有对方的引用,就会发生循环依赖。循环的依赖将会导致注入死循环。
楼主一而再,再而三的折腾循环依赖,你们不烦,楼主自己都烦了,如果你们实在是受不了,那就...
工厂模式:工厂模式主要是通过 BeanFactory 和 ApplicationContext 来生产 Bean 对象。
这篇分析 doCreateBean() 第三个过程:循环依赖处理。其实循环依赖并不仅仅只是在 doCreateBean() 中处理,其实在整个加载 bean 的过程中都有涉及,所以下篇内容并不仅仅只局限于 doCreateBean(),而是从整个 Bean 的加载过程进行分析。
在研究 『 Spring 是如何解决循环依赖的 』 的时候,了解到 Spring 是借助三级缓存来解决循环依赖的。
@[toc] 之前简单讲过Spring循环依赖的解决办法,但是没有深入源码分析,今天源码相关分析来了。
spring-ioc中循环依赖的问题,也算是高频的面试问题了,今天跟大家一起来总结一下spring-ioc中是如何解决循环依赖的,相信大家是可以从这篇文章中彻底理解spring容器如何帮我们解决循环依赖,为了更好的理解spring-ioc如何解决循环依赖,大家可以先简单的了解spring-ioc中bean实例化的整个时序图。
领取专属 10元无门槛券
手把手带您无忧上云