Spring的循环依赖原理解析

Spring的循环依赖原理解析

1.什么是循环依赖

 什么是循环依赖，很简单就是A对象依赖了B对象，B对象依赖了A对象。

// A依赖了B
class A{
	public B b;
}

// B依赖了A
class B{
	public A a;
}

那么循环依赖是个问题么？很显然如果不考虑Spring,循环依赖显然不是一个问题，因为对象之间相互依赖是一件很正常的事。例如： 

A a = new A();
B b = new B();

a.b = b;
b.a = a;

通过上述代码我们实现了A对象依赖了B对象，B对象依赖了A对象。但是为什么说在Spring中循环依赖就出现了问题？

因为在Spring中，一个对象并不是简单的new出来，而是经过一系列bean的生命周期。当然在Spring中，出现循环依赖的场景有很多，有的场景Spring自动帮我们解决，有的场景需要开发者自行解决。下面我们做详细分析Spring中循环依赖出现的问题，以及解决方案。

2.bean的生命周期

要了解Spring的循环依赖，首先要知道Spring中bean的生命周期。被Spring所管理的对象称作bean。bean的生命周期就是指在Spring中bean是如何生成的。但是这里不会对bean的生命周期做详细分析，如果想知道详情请参考：https://blog.csdn.net/qq_45065241/article/details/117597180

bean的生命周期：

1. Spring扫描class得到BeanDefinition
2. 根据得到的BeanDefinition去生成bean
3. 首先根据class推断构造方法
4. 根据推断出来的构造方法，反射得到一个对象（暂时称作原始对象）
5. 填充原始对象中的属性（依赖注入）
6. 如果原始对象中的个方法被AOP了，那么则需要根据原始对象生成一个代理对象
7. 把最终生成的代理对象放出单例池（源码中叫做singletionObjects）中。下次getBean直接从单例池里面去拿即可。

3.Spring中是如何产生循环依赖的。

我们通过案例去分析Spring中是如何产生循环依赖的。首先我们要分别创建AService,BService两个bean对象。这两个对象之间是相互依赖的。代码如下：

@Component
public class AService {
    @Autowired
    private BService bService;
}

@Component
public class BService {
    @Autowired
    private AService aService;
}
   public static void main(String[] args) {
        //单例模式下在启动Spring时就会创建bean.
        AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
      //  Object aService = applicationContext.getBean("AService", AService.class);
    }

我们通过bean的生命周期去分析：

AService的生命周期

1.Class---->BeanDefinition
2.AService = new AService() //原始对象
3.属性填充--->填充bService属性----->从单例池找bService对应的那个bean对象（根据beanName查找）---->不能找到----->创建bService
4.初始化
5.BeanPostProcessor
6.bean添加到单例池

BService的生命周期 

1.Class---->BeanDefinition
2.bService = new bService() //原始对象
3.属性填充--->填充aService属性----->从单例池找aService对应的哪个bean对象（根据beanName查找）--->不能找到----->创建aService
4.初始化
5.BeanPostProcessor
6.bean添加到单例池

结合上面所给的版图我们去看，当Spring去创建AService对象时，会在AService的生命周期的属性填充的步骤中去填充填充bService属性，首先会根据beanName从单例池中去找bService对应的bean对象，我们发现不能找到，因为BService这时还没有创建。所以Spring会去创建BService。但是在创建BService的过程中，由于BService中有aService的属性，所以在属性填充的步骤时又会去单例池中寻找AService,发现AService还没创建，则又会去创建AService。这样就出现了循环去创建的问题。也就是Spring中循环依赖的场景，但是在Spring中，通过某些机制帮我们解决了部门循环依赖的问题，这和机制就是三级缓存。

4.三级缓存

三级缓存是开发者通用的叫法，并不是官方定义的。这里先对三个缓存做简单的解释，后面做详细分析。

一级缓存为：singletonObjects   结构：HashMap

二级缓存为：earlySingletonObjects    结构：HashMap

三级缓存为：singletonFactories    结构：HashMap

• singletonObjects中缓存的是已经经历了完整生命周期的bena对象。
• earlySingletonObjects比singletonObjects多了一个early,表示缓存的是早期的bean对象。早期是什么意思？表示Bean的生命周期还没走完就把这个Bean放入了earlySingletonObjects
• singletonFactories中缓存的是ObjectFactory，表示对象工厂，用来创建对象的

5 解决循环依赖思路分析

5.1 “二级缓存”如何解决循环依赖

先来分析为什么缓存能解决循环依赖。

上文中分析得到，之所以产生循环依赖问题，主要是：A创建时--->需要B---->B去创建时--->需要A,从而产生了循环。

如何打破这个循环，加一层也就是加个中间人。

下面我们看添加缓存过后的生命周期

AService的生命周期

1.Class---->BeanDefinition
2.AService = new AService() //原始对象    ----->将原始对象放入缓存
3.属性填充--->填充bService属性----->从单例池找bService对应的那个bean对象（根据beanName查找）---->不能找到---->去缓存中找bService对应的那个bean对象---->不能找到----->创建bService
4.初始化
5.BeanPostProcessor
6.bean添加到单例池

BService的生命周期 

1.Class---->BeanDefinition
2.bService = new bService() //原始对象   ----->将原始对象放入缓存
3.属性填充--->填充aService属性----->从单例池找aService对应的哪个bean对象（根据beanName查找）--->不能找到------>去缓存中寻找aService对应的那个bean对象------>找到了----->创建aService
4.初始化
5.BeanPostProcessor
6.bean添加到单例池

通过上述面板分析，我们了解到： A的Bean在创建过程中，在进行依赖注入（属性填充）之前，先把A的原始Bean对象放入缓存。放入缓存之后在进行依赖注入，此时因为A的Bean依赖了B的Bean，如果B的Bean不存在，则需要创建B的Bean。创建B的Bean时与A创建Bean的步骤一样，也是先创建一个B的原始对象，然后将B的原始对象放入缓存中，然后在对B的原始对象进行依赖注入。在进行依赖注入时因为已经将A的原始对象（虽然时原始对象但是还不是最终的bean）放入缓存中，那么我们就能从缓存中获取到A的原始对象，从而完成对B的bean的创建。B的生命周期结束那么同样也代表着A的生命周期也完成了。

问题点：在进行依赖注入时就把A放入缓存，如果在BeanPostProcessor对原始对象发生修改，那么B中注入的A会发生变化么？

因为A的原始对象在后续的生命周期中堆中没有发生变化。

6.spring为什么用“三级缓存”去解决循环依赖

6.1 三级缓存应用场景：

难点：从上面的分析过程中我们可以得出，只需要二级缓存就能解决循环依赖了，那么为什么Spring中还需要引用singletonFactories（三级缓存）呢？ 

基于上面的场景我们想一个问题： 如果A的原始对象注入给B的属性之后，A的原始对象进行了AOP操作，那么就会产生了一个代理对象。对于A而言，它的Bean对象其实应该是AOP之后的代理都对象，而B的A属性在依赖注入时赋值的是原始对象，并不是AOP之后的代理对象。这就产生了冲突。

基于上面的问题的解决方法：

• 前提：出现了循环依赖并且A存在AOP操作。
• 方法：在A依赖注入的时候进行AOP操作，也就是提前进行AOP.

这里只针对上述问题场景作分析。

AService的生命周期

1. Class---->BeanDefinition
2. .AService = new AService() //原始对象    ----->三级缓存{ aService:lambda(原始对象) }
3. 属性填充--->填充bService属性----->从单例池找bService对应的那个bean对象（根据beanName查找）---->不能找到----->创建bService
4. 初始化
5. .BeanPostProcessor
6. bean添加到单例池

BService的生命周期 

1. .Class---->BeanDefinition
2. .bService = new bService() //原始对象   -
3. 属性填充--->填充aService属性----->从单例池找aService对应的哪个bean对象（根据beanName查找）--->不能找到------>出现了循环依赖---->三级缓存------->执行lambda(原始对象)------->执行lambda------->进行AOP操作----->生成一个代理对象----->创建aService
4. 初始化
5. BeanPostProcessor
6. bean添加到单例池

通过上述面板分析：我们分为两种情况考虑：

情况一：如果没有发生循环依赖，在执行AService 的生命周期时，会生成一个原始对象，然后将原始对象放入缓存。此时的缓存同样是三级缓存。

情况二：如果发生了循环依赖并且A执行了AOP操作，则需要提前进行AOP操作，那么在哪里进行AOP操作呢？则需要在执行BService的生命周期的依赖注入步骤的时候进行AOP操作。执行AOP操作的时候我们需要A的原始对象，A的原始对象则在AService创建原始对象的时候将原始对象放入缓存，这时的缓存我们称为三级缓存【三级缓存的结构是一个HashMap,存放的是（beanName,lambda（原始对象））】，方便BService创建时调用。这里我们就用到了三级缓存。

6.2 二级缓存应用场景

基于上面的场景我们对问题进行演深，如果AService有两个属性，分别是BService,CService。那么就生成了两个代理对象。怎么办？

这里只针对上述问题场景作分析。

AService的生命周期

1. Class---->BeanDefinition
2. .AService = new AService() //原始对象    ----->三级缓存{ aService:lambda(原始对象) }
3. 属性填充--->填充bService属性----->从单例池找bService对应的那个bean对象（根据beanName查找）---->不能找到----->创建bService
4. 初始化
5. .BeanPostProcessor
6. bean添加到单例池

BService的生命周期 

1. .Class---->BeanDefinition
2. .bService = new bService() //原始对象   -
3. 属性填充--->填充aService属性----->从单例池找aService对应的哪个bean对象（根据beanName查找）--->不能找到------>出现了循环依赖---->去二级缓存map去找----->不能找到------>三级缓存------->找到了------->执行lambda(原始对象)------->执行lambda------->进行AOP操作----->生成一个代理对象----->将代理对象放入二级缓存map------>删除三级缓存的lambda(删除三级缓存中的key)------>创建aService
4. 初始化
5. BeanPostProcessor
6. bean添加到单例池

CService的生命周期 

1. .Class---->BeanDefinition
2. .bService = new bService() //原始对象   -
3. 属性填充--->填充aService属性----->从单例池找aService对应的哪个bean对象（根据beanName查找）--->不能找到------>出现了循环依赖---->去二级缓存拿aService的代理对象
4. 初始化
5. BeanPostProcessor
6. bean添加到单例池

过程：因为A依赖了B，所以在执行A生命周期的时候，会先将A的原始对象放入三级缓存，然后去依赖注入，发现A依赖了B,则会创建B，在执行B生命周期的时候，同样会先将B的原始对象放入三级缓存中，然后执行依赖注入去填充A属性，首先会先去单例池中去找发现找不到，发现出现了循环依赖的问题，则去二级缓存中取找发现同样也找不到，最后去三级缓存中找，找到了然后执行三级缓存中HashMap中存储对应bean的lambda表达式，然后执行AOP操作生成一个代理对象，最后将生成的代理对象放到二级缓存并删除三级缓存中对应的lambda表达式。然后去执行创建C的步骤，与创建B的步骤一样，唯一区别就是能够直接从二级缓存中拿到代理对象不需要重复AOP操作。这就是二级缓存的作用。

7.Spring解决不了的循环依赖

通过Spring的循环依赖我们发现，B依赖的A和最终的A不是同一个对象。那么如何解决这个问题？很遗憾的是这个问题Spring中并没有提供解决这个问题的方法，可以说没办法解决。

因为在一个Bean的生命周期最后，Spring提供了BeanPostProcessor可以去对Bean进行加功，这个加功不仅仅只是能修改Bean的属性值，也可以替换掉当前Bean。

例如：

@Component
public class User {
}

@Component
public class LubanBeanPostProcessor implements BeanPostProcessor {

	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {

        // 注意这里，生成了一个新的User对象
		if (beanName.equals("user")) {
			System.out.println(bean);
			User user = new User();
			return user;
		}

		return bean;
	}
}

public class Test {
	public static void main(String[] args) {

		AnnotationConfigApplicationContext context =
				new AnnotationConfigApplicationContext(AppConfig.class);
		
		User user = context.getBean("user", User.class);
		System.out.println(user);

	}
}

打印运行结果如下：

com.luban.service.User@5e025e70
com.luban.service.User@1b0375b3

 上述代码分析可知：在BeanPostProcessor中可以完全替换掉某个beanName对应的bean对象。而BeanPostProcessor的执行在Bean的生命周期中是处于属性注入之后的，循环依赖是发生在属性注入过程中的，所以很有可能导致，注入给B对象的A对象和经历过完整生命周期之后的A对象，不是一个对象。这就是有问题的。所以在这种情况下的循环依赖，Spring是解决不了的，因为在属性注入时，Spring也不知道A对象后续会经过哪些BeanPostProcessor以及会对A对象做什么处理。

8.Spring到底解决了哪些情况下的循环依赖

虽然上面的情况（Spring解决不了的循环依赖）也能发生，但是发生的概率很小，我们通常在开发过程中，不会这样去做，但是，某个beanName对应的最终对象和原始对象不是一个对象却经常出现，这就是AOP。

AOP就是通过一个BeanPostProcessor来实现的，这个BeanPostProcessor就是AnnotationAwareAspectJAutoProxyCreator,他的父类是AbstartAutoProxyCreator,而在Spring中AOP利用的要么是JDK动态代理，要么CGLil的动态代理，所以如果给一个类中的某个方法设置了切面，那么这个类最终就需要生成一个代理对象。

一般过程就是： A类---->生成一个普通对象---->属性注入---->基于切面生成一个对象---->把代理对象放入singletonObjects单例池中。

而AOP可以说是Spring中除开IOC的另一个大功能，而循环依赖又是属于IOC范畴的，所以这两大功能想要并存，Spring需要特殊处理。如何处理的，就是利用三级缓存singletonFactories。

首先，singletonFactories中存的是某个beanName对应的ObjectFactory，在bean的生命周期中，生成完原始对象之后会构造一个ObjectFactory存入singletonFactories中。这个ObjectFactory是一个函数式接口，所以支持Lambda表达式：（） ->getEarlyBeanReference(beanName,mdb,bean)

上面的Lambda表达式就是一个ObjectFactory，执行该Lambda表达式就会去执行getEarlyBeanReference方法，该方法如下：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
	Object exposedObject = bean;
	if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
		for (BeanPostProcessor bp : getBeanPostProcessors()) {
			if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
				SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
				exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
			}
		}
	}
	return exposedObject;
}

 该方法会去执行SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法，而这个接口下的实现类中只有两个类实现了该方法，一个是AbstartAutoProxyCreator，一个是InstantiationAwareBeanPostProcessorAdapter，他的实现如下：

// InstantiationAwareBeanPostProcessorAdapter
@Override
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
	return bean;
}

// AbstractAutoProxyCreator
@Override
public Object getEarlyBeanReference(Object bean, String beanName) {
	Object cacheKey = getCacheKey(bean.getClass(), beanName);
	this.earlyProxyReferences.put(cacheKey, bean);
	return wrapIfNecessary(bean, beanName, cacheKey);
}

 所以很明显，整个Spring中，默认就只有AbstartAutoProxyCreator真正意义上实现了getEarlyBeanReference方法，而该类就是用来进行AOP的。上文提到的AnnotationAwareAspectJAutoProxyCreator的父类就是AbstartAutoProxyCreator。

那么getEarlyBeanReference方法到底在干什么？

首先得到一个cachekey，cachekey就是beanName。 然后把beanName和bean（这是原始对象）存入earlyProxyReferences中 调用wrapIfNecessary进行AOP，得到一个代理对象。

那么，什么时候会调用getEarlyBeanReference方法呢？回到循环依赖的场景中

我们这个时候得来理解一下earlySingletonObjects的作用，此时，我们只得到了A原始对象的代理对象，这 个对象还不完整，因为A原始对象还没有进行属性填充，所以此时不能直接把A的代理对象放入 singletonObjects中，所以只能把代理对象放入earlySingletonObjects，假设现在有其他对象依赖了A，那么 则可以从earlySingletonObjects中得到A原始对象的代理对象了，并且是A的同一个代理对象。

当B创建完了之后，A继续进行生命周期，而A在完成属性注入后，会按照它本身的逻辑去进行AOP，而此时 我们知道A原始对象已经经历过了AOP，所以对于A本身而言，不会再去进行AOP了，那么怎么判断一个对象 是否经历过了AOP呢？会利用上文提到的earlyProxyReferences，在AbstractAutoProxyCreator的 postProcessAfterInitialization方法中，会去判断当前beanName是否在earlyProxyReferences，如果在则表 示已经提前进行过AOP了，无需再次进行AOP。

对于A而言，进行了AOP的判断后，以及BeanPostProcessor的执行之后，就需要把A对应的对象放入 singletonObjects中了，但是我们知道，应该是要A的代理对象放入singletonObjects中，所以此时需要从 earlySingletonObjects中得到代理对象，然后入singletonObjects中。

9.总结“三级缓存”的精妙之处

1. 为什么三个级别的缓存都是用HashMap而不是ConcurrentHashMap,需要对三个hashMap加锁。
2.  singletonObjects：缓存某个beanName对应的经过了完整生命周期的bean
3.  earlySingletonObjects：缓存提前拿原始对象进行了AOP之后得到的代理对象，原始对象还没有进行属 性注入和后续的BeanPostProcessor等生命周期
4.  singletonFactories：缓存的是一个ObjectFactory，主要用来去生成原始对象进行了AOP之后得到的代 理对象，在每个Bean的生成过程中，都会提前暴露一个工厂，这个工厂可能用到，也可能用不到，如果 没有出现循环依赖依赖本bean，那么这个工厂无用，本bean按照自己的生命周期执行，执行完后直接把 本bean放入singletonObjects中即可，如果出现了循环依赖依赖了本bean，则另外那个bean执行 ObjectFactory提交得到一个AOP之后的代理对象(如果有AOP的话，如果无需AOP，则直接得到一个原始 对象)。
5. 其实还要一个缓存，就是earlyProxyReferences，它用来记录某个原始对象是否进行过AOP了。

本文参考： https://www.yuque.com/docs/share/c6934140-f84c-472c-b34a-2efc62c7dbb8?#

                   https://www.bilibili.com/video/BV1fT4y1F7Ly?p=10