Spring循环依赖

Spring循环依赖

1.概念:

看他的名字想必你就猜到八九不离十和循环有关

没错!循环依赖就是循环引用,两个或者两个以上的bean互相持有对方

和操作系统的死锁的四大必要条件循环等待有点类似,但这里面出现的死锁现象是因为对象依赖,不是调用导致的(有点电视据中的狗血三角恋味道!)

说的不生动??来张图康康

2.我们怎样检测循环依赖

简单的很!

Bean在创建的时候给该Bean打标,如果递归调用回来说明出现循环依赖

3Spring怎么solve此问题

Spring解决依赖主要基于java的引用传递

就是我们获取到对象的引用时,对象的Field属性可以延后设置

Spring采用的方法:三级缓存

在说之前我们先看下Spring的单例对象实例化

Spring的单例对象的初始化主要分为三步：

1. 实例化：其实就是调用对象的构造方法实例化对象
2. 注入：填充属性，这一步主要是对bean的依赖属性进行填充
3. 初始化：属性注入后，执行自定义初始化

在上述的三个步骤中:循环依赖主要发生在一和两个步骤上

那你说Spring用的三级缓存到底是什么?听起来好难??(直接上源码!一起锤他)

==我来解释下:
/** Cache of singleton objects: bean name --> bean instance */
//singletonObjects:表示的是单例对象的cache (是我们在创建bean时,首先会从cache获取的)  ------------------一级缓存
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

/** Cache of singleton factories: bean name --> ObjectFactory */
//singletonFactories:表示的是单例对象工厂的cache   ------------------二级缓存
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

/** Cache of early singleton objects: bean name --> bean instance */
//earlySingletonObjects:提前让单例对象的cache显示出来     ------------------三级缓存
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);

1
2
3
4
5
6
7
8
9
10
11
12
13

创建的Bean时的代码举例:

//beanName:你创建的bean
//allowEarlyReference:是否允许从singletonFactories中通过getObject拿到对象
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    //详细解释看下面
    Object singletonObject = this.singletonObjects.get(beanName);
    //加锁进行校验
    /**
     *isSingletonCurrentlyInCreation:
     *		判断当前单例bean是否正在创建中，
     *		也就是没有初始化完成(比如A的构造器依赖B对象所以得先去创建B对象
     *	         或则在A的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;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

上述代码剖析:

分析getSingleton()的整个过程，

1. Spring首先从一级缓存singletonObjects中获取。
2. 如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取。
3. 如果还是获取不到且允许singletonFactories通过getObject()获取，就从三级缓存singletonFactory.getObject()(三级缓存)获取，
4. 如果获取到了则：从singletonFactories中移除，并放入earlySingletonObjects中。
5. 其实也就是从三级缓存移动到了二级缓存。

三级缓存关键点:

调用createBeanInstance实例化后，

如果bean是单例，且允许从singletonFactories获取bean，

并且当前bean正在创建中，那么就把beanName放入三级缓存(singletonFactories)中:
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean

下面的源码可以不瞅,刚开始看的话(我心里一开始:这什么鬼东西!!哈哈)

// Eagerly cache singletons to be able to resolve circular references
// even when triggered by lifecycle interfaces like BeanFactoryAware.
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
		isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
	if (logger.isDebugEnabled()) {
		logger.debug("Eagerly caching bean '" + beanName +
				"' to allow for resolving potential circular references");
	}
	addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
	Assert.notNull(singletonFactory, "Singleton factory must not be null");
	synchronized (this.singletonObjects) {
		if (!this.singletonObjects.containsKey(beanName)) {
			this.singletonFactories.put(beanName, singletonFactory);
			this.earlySingletonObjects.remove(beanName);
			this.registeredSingletons.add(beanName);
		}
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

这里就是解决循环依赖的关键!!

这段代码发生在createBeanInstance之后，也就是说单例对象此时已经被创建出来(调用了构造器)。

这个对象已经被生产出来了，虽然还不完美（还没有进行初始化的第二步和第三步），但是已经能被人认出来了（根据对象引用能定位到堆中的对象），

所以Spring此时将这个对象提前曝光出来让大家认识，让大家使用。

这样做有什么好处呢？让我们来分析一下“A的某个field或者setter依赖了B的实例对象，同时B的某个field或者setter依赖了A的实例对象”这种循环依赖的情况：

Spring初始化bean过程

1. 首先尝试从一级缓存中获取serviceA实例，发现不存在并且serviceA不在创建过程中；
2. serviceA完成了初始化的第一步（实例化：调用createBeanInstance方法，即调用默认构造方法实例化）；
3. 将自己(serviceA)提前曝光到singletonFactories中;
4. 此时进行初始化的第二步（注入属性serviceB），发现自己依赖对象serviceB，此时就尝试去get(B)，发现B还没有被实create，所以走create流程;
5. serviceB完成了初始化的第一步（实例化：调用createBeanInstance方法，即调用默认构造方法实例化)
6. 将自己(serviceB)提前曝光到singletonFactories中;
7. 此时进行初始化的第二步（注入属性serviceA）;
8. 于是尝试get(A)，尝试一级缓存singletonObjects(肯定没有，因为A还没初始化完全)，尝试二级缓存earlySingletonObjects（也没有），尝试三级缓存singletonFactories，由于A通过ObjectFactory将自己提前曝光了，所以B能够通过ObjectFactory.getObject拿到A对象(虽然A还没有初始化完全，但是总比没有好呀);
9. B拿到A对象后顺利完成了初始化阶段1、2、3，完全初始化之后将自己放入到一级缓存singletonObjects中；
10. 此时返回A中，A此时能拿到B的对象顺利完成自己的初始化阶段2、3，最终A也完成了初始化，进去了一级缓存singletonObjects中;

知道了这个原理时候，肯定就知道为啥Spring不能解决“A的构造方法中依赖了B的实例对象，同时B的构造方法中依赖了A的实例对象”这类问题了！因为加入singletonFactories三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决。

4.常见的循环依赖场景

1. 单例Setter注入
2. 单例代理对象setter注入
3. 多例Setter注入
4. 构造器注入
5. DependsOn循环依赖

5.循环依赖的常见的解决方法

1. 生成代理对象产生的循环依赖

   1、使用@Lazy注解，延迟加载
   2、使用@DependsOn注解，指定加载先后关系
   3、修改文件名称，改变循环依赖类的加载顺序

2. 多例的setter注入

3. 构造器注入

4. dependsOn循环依赖

参考博文:spring如何解决循环依赖