Spring 循环依赖
《Spring之23:AbstractBeanFactory》
循环依赖就是循环引用,就是两个或多个Bean相互之间的持有对方,比如CircleA引用CircleB,CircleB引用CircleC,CircleC引用CircleA,则它们最终反映为一个环。此处不是循环调用,循环调用是方法之间的环调用。如下图所示:
循环调用是无法解决的,除非有终结条件,否则就是死循环,最终导致内存溢出错误。
循环依赖的产生和解决的前提
循环依赖的产生可能有很多种情况,例如:
- A的构造方法中依赖了B的实例对象,同时B的构造方法中依赖了A的实例对象
- A的构造方法中依赖了B的实例对象,同时B的某个field或者setter需要A的实例对象,以及反之
- A的某个field或者setter依赖了B的实例对象,同时B的某个field或者setter依赖了A的实例对象,以及反之
当然,Spring对于循环依赖的解决不是无条件的,首先前提条件是针对scope单例并且没有显式指明不需要解决循环依赖的对象,而且要求该对象没有被代理过。同时Spring解决循环依赖也不是万能,以上三种情况只能解决两种,第一种在构造方法中相互依赖的情况Spring也无力回天。结论先给在这,下面来看看Spring的解决方法,知道了解决方案就能明白为啥第一种情况无法解决了。
Spring对于循环依赖的解决
Spring循环依赖的理论依据其实是Java基于引用传递,当我们获取到对象的引用时,对象的field或者或属性是可以延后设置的。
Spring单例对象的初始化其实可以分为三步:
- createBeanInstance, 实例化,实际上就是调用对应的构造方法构造对象,此时只是调用了构造方法,spring xml中指定的property并没有进行populate
- populateBean,填充属性,这步对spring xml中指定的property进行populate
- initializeBean,调用spring xml中指定的init方法,或者AfterPropertiesSet方法
会发生循环依赖的步骤集中在第一步和第二步。
三级缓存
对于单例对象来说,在Spring的整个容器的生命周期内,有且只存在一个对象,很容易想到这个对象应该存在Cache中,Spring大量运用了Cache的手段,在循环依赖问题的解决过程中甚至使用了“三级缓存”。
在DefaultSingletonBeanRegistry使用三级缓存,“三级缓存”主要是指:
// 第一层: 初始化完备的单例bean
/** Cache of singleton objects: bean name to bean instance. */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
// 第二层: 提前曝光的单例对象的Cache
/** Cache of early singleton objects: bean name to bean instance. */
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
// 第三层: ObjectFactory工厂bean缓存, 存储实例话后的bean Factory
/** Cache of singleton factories: bean name to ObjectFactory. */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
从字面意思来说:singletonObjects指单例对象的cache,singletonFactories指单例对象工厂的cache,earlySingletonObjects指提前曝光的单例对象的cache。以上三个cache构成了三级缓存,Spring就用这三级缓存巧妙的解决了循环依赖问题。
解决方法
回想《Spring之23:AbstractBeanFactory》文章中关于Bean创建的过程getBean(),首先Spring会尝试从缓存中获取单例对象,这个缓存就是指singletonObjects,
缓存中获取单例对象---主要调用的方法是:
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
// 首先从第一层缓存获取
Object singletonObject = this.singletonObjects.get(beanName);
// 其次第一层未找到缓存 且 bean处于创建中(例如A定义的构造函数依赖了B对象,得先去创建B对象,或者在populatebean过程中依赖了B对象,得先去创建B对象,此时A处于创建中)
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
// 最后第二层未找到缓存 并 允许循环依赖即从工厂类获取对象
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
// 此时会将三级缓存 移入 二级缓存
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
首先解释两个参数:
- isSingletonCurrentlyInCreation 判断对应的单例对象是否在创建中,当单例对象没有被初始化完全(例如A定义的构造函数依赖了B对象,得先去创建B对象,或者在populatebean过程中依赖了B对象,得先去创建B对象,此时A处于创建中)
- allowEarlyReference 是否允许从singletonFactories中通过getObject拿到对象
分析getSingleton的整个过程,Spring首先从singletonObjects(一级缓存)中尝试获取,如果获取不到并且对象在创建中,则尝试从earlySingletonObjects(二级缓存)中获取,如果还是获取不到并且允许从singletonFactories通过getObject获取,则通过singletonFactory.getObject()(三级缓存)获取。如果获取到了则
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
则移除对应的singletonFactory,将singletonObject放入到earlySingletonObjects,其实就是将三级缓存提升到二级缓存中!
Spring解决循环依赖的诀窍就在于singletonFactories这个cache,这个cache中存的是类型为ObjectFactory,其定义如下:
public interface ObjectFactory<T> {
T getObject() throws BeansException;}
在bean创建过程中,有两处比较重要的匿名内部类实现了该接口。一处是
new ObjectFactory<Object>() {
@Override public Object getObject() throws BeansException {
try {
return createBean(beanName, mbd, args);
} catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
} }
在上文已经提到,Spring利用其创建bean(这样做真的很不明确呀...)
另一处就是:
addSingletonFactory(beanName, new ObjectFactory<Object>() {
@Override public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}});
此处就是解决循环依赖的关键,这段代码发生在createBeanInstance之后,也就是说单例对象此时已经被创建出来的。这个对象已经被生产出来了,虽然还不完美(还没有进行初始化的第二步和第三步),但是已经能被人认出来了(根据对象引用能定位到堆中的对象),所以Spring此时将这个对象提前曝光出来让大家认识,让大家使用。
这样做有什么好处呢?让我们来分析一下“A的某个field或者setter依赖了B的实例对象,同时B的某个field或者setter依赖了A的实例对象”这种循环依赖的情况。A首先完成了初始化的第一步,并且将自己提前曝光到singletonFactories中,此时进行初始化的第二步,发现自己依赖对象B,此时就尝试去get(B),发现B还没有被create,所以走create流程,B在初始化第一步的时候发现自己依赖了对象A,于是尝试get(A),尝试一级缓存singletonObjects(肯定没有,因为A还没初始化完全),尝试二级缓存earlySingletonObjects(也没有),尝试三级缓存singletonFactories,由于A通过ObjectFactory将自己提前曝光了,所以B能够通过ObjectFactory.getObject拿到A对象(虽然A还没有初始化完全,但是总比没有好呀),B拿到A对象后顺利完成了初始化阶段1、2、3,完全初始化之后将自己放入到一级缓存singletonObjects中。此时返回A中,A此时能拿到B的对象顺利完成自己的初始化阶段2、3,最终A也完成了初始化,长大成人,进去了一级缓存singletonObjects中,而且更加幸运的是,由于B拿到了A的对象引用,所以B现在hold住的A对象也蜕变完美了!一切都是这么神奇!!
知道了这个原理时候,肯定就知道为啥Spring不能解决“A的构造方法中依赖了B的实例对象,同时B的构造方法中依赖了A的实例对象”这类问题了!
Spring通过三级缓存加上“提前曝光”机制,配合Java的对象引用原理,比较完美地解决了某些情况下的循环依赖问题!
Spring容器循环依赖包括构造器循环依赖和setter循环依赖,那Spring容器如何解决循环依赖呢?首先让我们来定义三个循环引用类:
CircleA.java
public class CircleA { private CircleB circleB;
public CircleA() {
}
public CircleA(CircleB circleB) {
this.circleB = circleB;
}
public void setCircleB(CircleB circleB)
{
this.circleB = circleB;
}
public void a() {
circleB.b();
} }
CircleB.java
public class CircleB { private CircleC circleC;
public CircleB() {
}
public CircleB(CircleC circleC) {
this.circleC = circleC;
}
public void setCircleC(CircleC circleC)
{
this.circleC = circleC;
}
public void b() {
circleC.c();
} }
CircleC.java
public class CircleC { private CircleA circleA;
public CircleC() {
}
public CircleC(CircleA circleA) {
this.circleA = circleA;
}
public void setCircleA(CircleA circleA)
{
this.circleA = circleA;
}
public void c() {
circleA.a();
} }
1、构造器循环依赖(此依赖是无法解决)
构造器循环依赖:表示通过构造器注入构成的循环依赖,此依赖是无法解决的,只能抛出BeanCurrentlyInCreationException异常表示循环依赖。
如在创建CircleA类时,构造器需要CircleB类,那将去创建CircleB,在创建CircleB类时又发现需要CircleC类,则又去创建CircleC,最终在创建CircleC时发现又需要CircleA;从而形成一个环,没办法创建。
Spring容器将每一个正在创建的Bean 标识符放在一个“当前创建Bean池”中,Bean标识符在创建过程中将一直保持在这个池中,因此如果在创建Bean过程中发现自己已经在“当前创建Bean池”里时将抛出BeanCurrentlyInCreationException
异常表示循环依赖;而对于创建完毕的Bean将从“当前创建Bean池”中清除掉。
circleInjectByConstructor.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="circleA" class="com.spring.framework.carl.ioc.CircleA">
<constructor-arg index="0" ref="circleB" />
</bean> <bean id="circleB" class="com.spring.framework.carl.ioc.CircleB">
<constructor-arg index="0" ref="circleC" />
</bean> <bean id="circleC" class="com.spring.framework.carl.ioc.CircleC">
<constructor-arg index="0" ref="circleA" />
</bean> </beans>
测试方法:
@Test(expected = BeanCurrentlyInCreationException.class)
public void testCircleByConstructor() throws Throwable {
try{
new ClassPathXmlApplicationContext("circleInjectByConstructor.xml");
} catch (Exception e){
// 因为要在创建circle3时抛出;
Throwable e1 = e.getCause().getCause().getCause();
throw e1;
}
}
让我们分析一下吧:
- Spring容器创建“circleA” Bean,首先去“当前创建Bean池”查找是否当前Bean正在创建,如果没发现,则继续准备其需要的构造器参数“circleB”,并将“circleA” 标识符放到“当前创建Bean池”;
- Spring容器创建“circleB” Bean,首先去“当前创建Bean池”查找是否当前Bean正在创建,如果没发现,则继续准备其需要的构造器参数“circleC”,并将“circleB” 标识符放到“当前创建Bean池”;
- Spring容器创建“circleC” Bean,首先去“当前创建Bean池”查找是否当前Bean正在创建,如果没发现,则继续准备其需要的构造器参数“circleA”,并将“circleC” 标识符放到“当前创建Bean池”;
- 到此为止Spring容器要去创建“circleA”Bean,发现该Bean 标识符在“当前创建Bean池”中,因为表示循环依赖,抛出BeanCurrentlyInCreationException。
2、setter循环依赖(singleton)(“提前曝光”机制刚完成构造器注入但未完成其他步骤(如setter注入)的Bean来完成,只能解决单例作用域的Bean循环依赖)
setter循环依赖:表示通过setter注入方式构成的循环依赖。
对于setter注入造成的依赖是通过Spring容器提前暴露刚完成构造器注入但未完成其他步骤(如setter注入)的Bean来完成的,而且只能解决单例作用域的Bean循环依赖。
如下代码所示,通过提前暴露一个单例工厂方法,从而使其他Bean能引用到该Bean。
addSingletonFactory(beanName, new ObjectFactory() {
public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}
});
具体步骤如下:
- Spring容器创建单例“circleA” Bean,首先根据无参构造器创建Bean,并暴露一个“ObjectFactory ”用于返回一个提前暴露一个创建中的Bean,并将“circleA” 标识符放到“当前创建Bean池”;然后进行setter注入“circleB”;
- Spring容器创建单例“circleB” Bean,首先根据无参构造器创建Bean,并暴露一个“ObjectFactory”用于返回一个提前暴露一个创建中的Bean,并将“circleB” 标识符放到“当前创建Bean池”,然后进行setter注入“circleC”;
- Spring容器创建单例“circleC” Bean,首先根据无参构造器创建Bean,并暴露一个“ObjectFactory ”用于返回一个提前暴露一个创建中的Bean,并将“circleC” 标识符放到“当前创建Bean池”,然后进行setter注入“circleA”;进行注入“circleA”时由于提前暴露了“ObjectFactory”工厂从而使用它返回提前暴露一个创建中的Bean;
- 最后在依赖注入“circleB”和“circleA”,完成setter注入。
circleInjectBySetterSingleton.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="circleA" class="com.spring.framework.carl.ioc.CircleA">
<property name="circleB" ref="circleB" />
</bean> <bean id="circleB" class="com.spring.framework.carl.ioc.CircleB">
<property name="circleC" ref="circleC" />
</bean> <bean id="circleC" class="com.spring.framework.carl.ioc.CircleC">
<property name="circleA" ref="circleA" />
</bean> </beans>
测试方法:
@Test
public void testCircleBySetterSingleton(){
new ClassPathXmlApplicationContext("circleInjectBySetterSingleton.xml");
}
3、setter循环依赖(非singleton)(此依赖是无法解决)
对于prototype
作用域Bean,Spring容器无法完成依赖注入,因为prototype作用域的Bean,Spring容器不进行缓存,因此无法提前暴露一个创建中的Bean。
circleInjectBySetterNotSingleton.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="circleA" class="com.spring.framework.carl.ioc.CircleA" scope="prototype">
<property name="circleB" ref="circleB" />
</bean> <bean id="circleB" class="com.spring.framework.carl.ioc.CircleB" scope="prototype">
<property name="circleC" ref="circleC" />
</bean> <bean id="circleC" class="com.spring.framework.carl.ioc.CircleC" scope="prototype">
<property name="circleA" ref="circleA" />
</bean> </beans>
测试方法:
@Test(expected = BeanCurrentlyInCreationException.class)
public void testCircleBySetterNotSingleton() throws Throwable {
try {
ApplicationContext context = new ClassPathXmlApplicationContext("circleInjectBySetterNotSingleton.xml");
System.out.println(context.getBean("circleA"));
} catch (Exception e){
// 因为要在创建circle3时抛出;
Throwable e1 = e.getCause().getCause().getCause();
throw e1;
}
}
4、setter循环依赖(singleton设置不允许依赖注入)【这里无法解决循环依赖,只是如何禁用循环引用】
在Spring IOC中对于singleton作用域Bean,可以通过setAllowCircularReferences(false);
来禁用循环引用:
测试方法:
@Test(expected = BeanCurrentlyInCreationException.class)
public void testCircleBySetterAndSingleton2() throws Throwable {
try {
ClassPathXmlApplicationContext ctx =
new ClassPathXmlApplicationContext();ctx.setAllowCircularReferences(
false
);
ctx.setConfigLocation("chapter3/circleInjectBySetterAndSingleton.xml");
ctx.refresh();
}
catch (Exception e) {
Throwable e1 = e.getCause().getCause().getCause();
throw e1;
}
}
5、循环调用
循环调用是无法解决的,除非有终结条件,否则就是死循环,最终导致内存溢出错误。
测试方法:
@Test(expected = StackOverflowError.class)
public void testCircleInvokeMethod(){
ApplicationContext context = new ClassPathXmlApplicationContext("circleInjectBySetterSingleton.xml");
CircleA circleA = context.getBean("circleA", CircleA.class);
circleA.a(); //a()中调用circleB.b()--circleC.c()-->a(),内存溢出
}
补充:出现循环依赖是设计上的问题,一定要避免!
请参考《敏捷软件开发:原则、模式与实践》中的“无环依赖”原则
包之间的依赖结构必须是一个直接的无环图形(DAG)。也就是说,在依赖结构中不允许出现环(循环依赖)。
引用地址:【第三章】 DI 之 3.2 循环依赖 ——跟我学spring3
Spring 循环依赖的更多相关文章
- spring循环依赖问题分析
新搞了一个单点登录的项目,用的cas,要把源码的cas-webapp改造成适合我们业务场景的项目,于是新加了一些spring的配置文件. 但是在项目启动时报错了,错误日志如下: 一月 , :: 下午 ...
- Springboot源码分析之Spring循环依赖揭秘
摘要: 若你是一个有经验的程序员,那你在开发中必然碰到过这种现象:事务不生效.或许刚说到这,有的小伙伴就会大惊失色了.Spring不是解决了循环依赖问题吗,它是怎么又会发生循环依赖的呢?,接下来就让我 ...
- Spring 循环依赖的三种方式(三级缓存解决Set循环依赖问题)
本篇文章解决以下问题: [1] . Spring循环依赖指的是什么? [2] . Spring能解决哪种情况的循环依赖?不能解决哪种情况? [3] . Spring能解决的循环依赖原理(三级缓存) 一 ...
- Spring循环依赖的解决
## Spring循环依赖的解决 ### 什么是循环依赖 循环依赖,是依赖关系形成了一个圆环.比如:A对象有一个属性B,那么这时候我们称之为A依赖B,如果这时候B对象里面有一个属性A.那么这时候A和B ...
- 这个 Spring 循环依赖的坑,90% 以上的人都不知道
1. 前言 这两天工作遇到了一个挺有意思的Spring循环依赖的问题,但是这个和以往遇到的循环依赖问题都不太一样,隐藏的相当隐蔽,网络上也很少看到有其他人遇到类似的问题.这里权且称他非典型Spring ...
- Spring — 循环依赖
读完这篇文章你将会收获到 Spring 循环依赖可以分为哪两种 Spring 如何解决 setter 循环依赖 Spring 为何是三级缓存 , 二级不行 ? Spring 为啥不能解决构造器循环依赖 ...
- 帮助你更好的理解Spring循环依赖
网上关于Spring循环依赖的博客太多了,有很多都分析的很深入,写的很用心,甚至还画了时序图.流程图帮助读者理解,我看了后,感觉自己是懂了,但是闭上眼睛,总觉得还没有完全理解,总觉得还有一两个坎过不去 ...
- spring 循环依赖的一次 理解
前言: 在看spring 循环依赖的问题中,知道原理,网上一堆的资料有讲原理. 但今天在看代码过程中,又产生了疑问. 疑问点如下: // 疑问点: 先进行 dependon 判断String[] de ...
- 3.1 spring5源码系列--循环依赖 之 手写代码模拟spring循环依赖
本次博客的目标 1. 手写spring循环依赖的整个过程 2. spring怎么解决循环依赖 3. 为什么要二级缓存和三级缓存 4. spring有没有解决构造函数的循环依赖 5. spring有没有 ...
随机推荐
- MD5加密算法的java实现
package other; import java.security.MessageDigest;import java.security.NoSuchAlgorithmException;/* * ...
- java 使用反射
java程序中的对象在运行时会出现两种类型:编译时类型和运行时类型.例如List list = new ArrayList().其中变量list的编译时类型是List,运行时类型是ArrayList ...
- docker之DockerSwarm的了解
这次一起了解下docker Swarm,什么是dockerSwarm. 什么是docker Swarm 产品背景 使用docker的流程,ssh到一台服务器,运行docker命令来运行本机的docke ...
- 【译】:python中的colorlog库
本文翻译自colorlog官方文档 一. 描述 colorlog.ColoredFormatter是一个Python logging模块的格式化,用于在终端输出日志的颜色 二. 安装 pip inst ...
- 通用 mysql配置
windows:my.ini [mysqld] # Remove leading # and set to the amount of RAM for the most important data ...
- YCSB benchmark测试cassandra性能——和web服务器测试性能结果类似
转自:http://www.itdadao.com/articles/c15a531189p0.html http://www.cnblogs.com/bettersky/p/6158172.html ...
- MySQL Multi-Range Read
MySQL 5.6版本提供了很多性能优化的特性,其中之一就是 Multi-Range Read 多范围读(MRR) , 它的作用针对基于辅助/第二索引的查询,减少随机IO,并且将随机IO转化为顺序IO ...
- OC-SEL 和 Class
[认识选择器]============================================ SEL 1.选择器(SEL)是一个变量类型. 2.选择器用来装成员消息(成员方法) people ...
- Struts2 用过滤器代替了 servlet ,???? 且不需要tomcat就可以直接做功能测试
Struts2 用过滤器代替了 servlet ,???? 且不需要tomcat就可以直接做功能测试
- 使用Python 2.7实现的垃圾短信识别器
最近参加比赛,写了一个垃圾短信识别器,在这里做一下记录. 官方提供的数据是csv文件,其中训练集有80万条数据,测试集有20万条数据,训练集的格式为:行号 标记(0为普通短信,1为垃圾短信) 短信内容 ...