Spring中的循环依赖
Spring循环依赖
- 只有在setter方式注入的情况下，循环依赖才能解决（错）
- 三级缓存的目的是为了提高效率（错）
大厂面试题
- 你解释下spring中的三级缓存?
- 三级缓存分别是什么?三个Map有什么异同?
- 什么是循环依赖?请你谈谈?看过spring源码吗?一般我们说的spring容器是什么
- 如何检测是否籽在循环依赖?实际开发中见过循环依赖的异常吗?
- 多例的情况下，循环依赖问题为什么无法解决?
- 为什么一定要用3级缓存，1级/2级能不能行？
- 是否可以关闭循环依赖？
什么是循环依赖
多个bean之间相互依赖，形成了一个闭环。 比如:A依赖于B、B依赖于C、C依赖于A。代码如下：
public class Test1{
class A{
B b;
}
class B{
C c;
}
class C{
A a;
}
}
通常来说，如果问spring容器内部如何解决循环依赖， 一定是指默认的单例Bean中，属性互相引用的场景。也就是说，Spring的循环依赖，是Spring容器注入时候出现的问题
两种注入方式对循环依赖的影响
(官网说明)[https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-dependencies]
结论：我们AB循环依赖问题只要A的注入方式是setter且singleton, 就不会有循环依赖问题
| 依赖情况 | 依赖注入方式 | 循环依赖是否被解决 |
|---|---|---|
| AB相互依赖（循环依赖） | 均采用setter方法注入 | 是 |
| AB相互依赖（循环依赖） | 均采用构造器注入 | 否 |
| AB相互依赖（循环依赖） | A中注入B的方式为setter方法，B中注入A的方式为构造器 | 是 |
| AB相互依赖（循环依赖） | B中注入A的方式为setter方法，A中注入B的方式为构造器 | 否 |
⚠️：Spring在创建Bean时默认会根据自然排序进行创建，所以A会先于B进行创建
Spring容器循环依赖报错 🤔
循环依赖现象在Spring容器中注入依赖的对象，有2种情况
-
构造器方式注入依赖
结论：构造器注入没有办法解决循环依赖， 你想让构造器注入支持循环依赖，是不存在的
// ServiceA @Component public class ServiceA { private ServiceB serviceB; public ServiceA(ServiceB serviceB){ this.serviceB = serviceB; } } // ServiceB @Component public class ServiceB { private ServiceA serviceA; public ServiceB(ServiceA serviceA){ this.serviceA = serviceA; } } // 构造器测试 // ⚠️ 结论：构造器注入没有办法解决循环依赖， 你想让构造器注入支持循环依赖，是不存在的 public class ClientConstructor { public static void main(String[] args) { new ServiceA(new ServiceB(...)); // 无限套娃 } } -
以set方式注入依赖
结论：属性注入可以解决循环依赖
// ServiceAA @Component public class ServiceAA { private ServiceBB serviceBB; public void setServiceBB(ServiceBB serviceBB){ this.serviceBB = serviceBB; System.out.println("A 里面设置了B"); } } // ServiceBB @Component public class ServiceBB { private ServiceAA serviceAA; public void setServiceAA(ServiceAA serviceAA){ this.serviceAA = serviceAA; System.out.println("B 里面设置了A"); } } // 构造器测试 // ⚠️ 结论：属性注入可以解决循环依赖 public class ClientSet { public static void main(String[] args) { // 创建serviceAA ServiceAA a = new ServiceAA(); // 创建serviceBB ServiceBB b = new ServiceBB(); // 将serviceAA注入到serviceBB中 b.setServiceAA(a); // 将serviceBB注入到serviceAA中 a.setServiceBB(b); } }
重要code案例演示
1）code-java基础编码
// A
public class A {
private B b;
public B getB() {
return b;
}
public void setB(B b) {
this.b = b;
}
public A(){
System.out.println("---A created success");
}
}
// B
public class B {
private A a;
public A getA() {
return a;
}
public void setA(A a) {
this.a = a;
}
public B(){
System.out.println("---B created success");
}
}
// ClientCode
public class ClientCode {
public static void main(String[] args) {
A a = new A();
B b = new B();
b.setA(a);
a.setB(b);
}
}
2）spring容器
- 默认的单例(singleton)的场景是支持循环依赖的，不报错
- 原型(Prototype)的场景是不支持循环依赖的，报错
- 每次都new一个，说明没办法放到缓存里面，就用不了三级缓存。
步骤:
- applicationContext.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="a" class="cn.silince.circulardepend.importantdemo.A" scope="prototype">
<property name="b" ref="b"/>
</bean>
<bean id="b" class="cn.silince.circulardepend.importantdemo.B" scope="prototype">
<property name="a" ref="a"/>
</bean>
</beans>
-
log4j.properties
-
默认单例，修改为原型scope=”prototype” 就导致了循环依赖错误
-
ClientSpringContainer
-
循环依赖异常 —
BeanCurrentlyInCreationException
重要结论(spring内部通过3级缓存来解决循环依赖)
⚠️ 只有单例的bean会通过三级缓存提前暴露来解决循环依赖的问题，而非单例的bean，每次从容器中获取都是一个新的对象，都会重新创建，所以非单例的bean是没有缓存的，不会将其放到三级缓存中。
关键类：DefaultSingletonBeanRegistry。
所谓的三级缓存其实就是spring容器内部用来解决循环依赖问题的三个map:
- 第一级缓存(也叫单例池)
singletonObjects：存放已经经历了完整生命周期的Bean对象 - 第二级缓存
earlySingletonObjects：存放早期暴露出来的Bean对象，Bean的生命周期未结束（属性还未填充完) - 第三级缓存
Map<String,ObjectFactory<?>> singletonFactories：存放可以生成Bean的工厂
循环依赖Debug(无AOP) 🤔
实例化/初初化
- 实例化：堆内存中申请一块内存空间(租赁好房子，自己的家具东西还没有搬家进去)
- 初始化：初始化属性填充，完成属性的各种赋值(装修、家电家具进场)
首先，我们要知道Spring在创建Bean的时候默认是按照自然排序来进行创建的，所以第一步Spring会去创建A。
与此同时，我们应该知道，Spring在创建Bean的过程中分为三步
- 实例化，对应方法：
AbstractAutowireCapableBeanFactory中的createBeanInstance方法 - 属性注入，对应方法：
AbstractAutowireCapableBeanFactory的populateBean方法 - 初始化，对应方法：
AbstractAutowireCapableBeanFactory的initializeBean
简单理解：
- 实例化，简单理解就是new了一个对象
- 属性注入，为实例化中new出来的对象填充属性
- 初始化，执行aware接口中的方法，初始化方法，完成
AOP代理
3大Map和四大方法
3大Map：
- 第一层singeltonObjects存放的是已经初始化好了的Bean
- 第二层earlySingletonObjects存放的是实例化了，但是未初始化的Bean
- 第三层singletonFactories存放的是FactoryBean，是提前暴露的一个单例工厂，二级缓存中存储的就是从这个工厂中获取到的对象。假如A类实现了FactoryBean，那么依赖注入的时候不是A类，而是A类产生的Bean。
四大方法：
- getSingleton：希望从容器里面获得单例的bean，有的话直接拿，没有的话说明还未创建
- doCreateBean: 没有就创建bean
- populateBean: 创建完了以后，要填充属性
- addSingleton: 填充完了以后，再添加到容器进行使用
/**
* 单例对象的缓存：bean 名称——bean实例，即所谓的单例池
* 表示已经经历了完整生命周期的 Bean 对象
* <b>第一级缓存</b>
*/
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
/**
* 早期的单例对象的高速缓存：bean 名称——bean 实例。
* 表示 Bean 的生命周期还没走完(Bean 的属性还未填充)就把这个 Bean 存入该缓存中
* 也就是实例化但是未初始化的 bean 放入该缓存里
* <b>第二级缓存</b>
*/
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
/**
* 单例工厂的高速缓存：bean 名称——ObjectFactory。
* 表示存放生成 bean 的工厂
* <b>第三级缓存</b>
*/
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
A/B两对象在三级缓存中的迁移说明
- A创建过程中需要B，于是A将自己放到三级缓存里面，去实例化B
-
B实例化的时候发现需要A，于是B先查一级缓存，没有，再查二级缓存，还是没有，再查三级缓存，找到了A，然后把三级缓存里面的这个A放到二级缓存里面，并删除三级缓存里面的A
- B顺利初始化完毕，将自己放到一级缓存里面(此时B里面的A依然是创建中状态)，然后回来接着创建A，此时B已经创建结束，直接从一级缓存里面拿到B，然后完成创建，并将A自己放到一级缓存里面。
断点与流程
详细流程
基于上面的知识，我们开始解读整个循环依赖处理的过程，整个流程应该是以A的创建为起点，前文也说了，第一步就是创建A嘛！
创建A的过程实际上就是调用getBean方法，这个方法有两层含义
- 创建一个新的Bean
- 从缓存中获取到已经被创建的对象
我们现在分析的是第一层含义，因为这个时候缓存中还没有A嘛！
调用getSingleton(beanName)
首先调用getSingleton(a)方法，这个方法又会调用getSingleton(beanName, true)，在上图中我省略了这一步
public Object getSingleton(String beanName) {
return getSingleton(beanName, true);
}
getSingleton(beanName, true)这个方法实际上就是到缓存中尝试去获取Bean，整个缓存分为三级
singletonObjects，一级缓存，存储的是所有创建好了的单例BeanearlySingletonObjects，完成实例化，但是还未进行属性注入及初始化的对象singletonFactories，提前暴露的一个单例工厂，二级缓存中存储的就是从这个工厂中获取到的对象
因为A是第一次被创建，所以不管哪个缓存中必然都是没有的，因此会进入getSingleton的另外一个重载方法getSingleton(beanName, singletonFactory)。
调用getSingleton(beanName, singletonFactory)
这个方法就是用来创建Bean的，其源码如下：
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(beanName, "Bean name must not be null");
synchronized (this.singletonObjects) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
// ....
// 省略异常处理及日志
// ....
// 在单例对象创建前先做一个标记
// 将beanName放入到singletonsCurrentlyInCreation这个集合中
// 标志着这个单例Bean正在创建
// 如果同一个单例Bean多次被创建，这里会抛出异常
beforeSingletonCreation(beanName);
boolean newSingleton = false;
boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
if (recordSuppressedExceptions) {
this.suppressedExceptions = new LinkedHashSet<>();
}
try {
// 上游传入的lambda在这里会被执行，调用createBean方法创建一个Bean后返回
singletonObject = singletonFactory.getObject();
newSingleton = true;
}
// ...
// 省略catch异常处理
// ...
finally {
if (recordSuppressedExceptions) {
this.suppressedExceptions = null;
}
// 创建完成后将对应的beanName从singletonsCurrentlyInCreation移除
afterSingletonCreation(beanName);
}
if (newSingleton) {
// 添加到一级缓存singletonObjects中
addSingleton(beanName, singletonObject);
}
}
return singletonObject;
}
}
上面的代码我们主要抓住一点，通过createBean方法返回的Bean最终被放到了一级缓存，也就是单例池中。
那么到这里我们可以得出一个结论：一级缓存中存储的是已经完全创建好了的单例Bean
调用addSingletonFactory方法
如下图所示：
在完成Bean的实例化后，属性注入之前Spring将Bean包装成一个工厂添加进了三级缓存中，对应源码如下：
// 这里传入的参数也是一个lambda表达式，() -> 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);
}
}
}
这里只是添加了一个工厂，通过这个工厂（ObjectFactory）的getObject方法可以得到一个对象，而这个对象实际上就是通过getEarlyBeanReference这个方法创建的。那么，什么时候会去调用这个工厂的getObject方法呢？这个时候就要到创建B的流程了。
当A完成了实例化并添加进了三级缓存后，就要开始为A进行属性注入了，在注入时发现A依赖了B，那么这个时候Spring又会去getBean(b)，然后反射调用setter方法完成属性注入。
因为B需要注入A，所以在创建B的时候，又会去调用getBean(a)，这个时候就又回到之前的流程了，但是不同的是，之前的getBean是为了创建Bean，而此时再调用getBean不是为了创建了，而是要从缓存中获取，因为之前A在实例化后已经将其放入了三级缓存singletonFactories中，所以此时getBean(a)的流程就是这样子了。
从这里我们可以看出，注入到B中的A是通过getEarlyBeanReference方法提前暴露出去的一个对象，还不是一个完整的Bean，那么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;
}
它实际上就是调用了后置处理器的getEarlyBeanReference，而真正实现了这个方法的后置处理器只有一个，就是通过@EnableAspectJAutoProxy注解导入的AnnotationAwareAspectJAutoProxyCreator。也就是说如果在不考虑AOP的情况下，上面的代码等价于：
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
return exposedObject;
}
也就是说这个工厂啥都没干，直接将实例化阶段创建的对象返回了！所以说在不考虑AOP的情况下三级缓存有用嘛？讲道理，真的没什么用，我直接将这个对象放到二级缓存中不是一点问题都没有吗？如果你说它提高了效率，那你告诉我提高的效率在哪?
那么三级缓存到底有什么作用呢？不要急，我们先把整个流程走完，在下文结合AOP分析循环依赖的时候你就能体会到三级缓存的作用！
到这里不知道小伙伴们会不会有疑问，B中提前注入了一个没有经过初始化的A类型对象不会有问题吗？
答：不会
这个时候我们需要将整个创建A这个Bean的流程走完，如下图：
从上图中我们可以看到，虽然在创建B时会提前给B注入了一个还未初始化的A对象，但是在创建A的流程中一直使用的是注入到B中的A对象的引用，之后会根据这个引用对A进行初始化，所以这是没有问题的。
总结
结合了AOP的循环依赖
之前我们已经说过了，在普通的循环依赖的情况下，三级缓存没有任何作用。三级缓存实际上跟Spring中的AOP相关，我们再来看一看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;
}
如果在开启AOP的情况下，那么就是调用到AnnotationAwareAspectJAutoProxyCreator的getEarlyBeanReference方法，对应的源码如下：
public Object getEarlyBeanReference(Object bean, String beanName) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
this.earlyProxyReferences.put(cacheKey, bean);
// 如果需要代理，返回一个代理对象，不需要代理，直接返回当前传入的这个bean对象
return wrapIfNecessary(bean, beanName, cacheKey);
}
回到上面的例子，我们对A进行了AOP代理的话，那么此时getEarlyBeanReference将返回一个代理后的对象，而不是实例化阶段创建的对象，这样就意味着B中注入的A将是一个代理对象而不是A的实例化阶段创建后的对象。
看到这个图你可能会产生下面这些疑问
-
在给B注入的时候为什么要注入一个代理对象？
答：当我们对A进行了
AOP代理时，说明我们希望从容器中获取到的就是A代理后的对象而不是A本身，因此把A当作依赖进行注入时也要注入它的代理对象 -
明明初始化的时候是A对象，那么Spring是在哪里将代理对象放入到容器中的呢？
在完成初始化后，Spring又调用了一次getSingleton方法，这一次传入的参数又不一样了，false可以理解为禁用三级缓存，前面图中已经提到过了，在为B中注入A时已经将三级缓存中的工厂取出，并从工厂中获取到了一个对象放入到了二级缓存中，所以这里的这个getSingleton方法做的时间就是从二级缓存中获取到这个代理后的A对象。exposedObject == bean可以认为是必定成立的，除非你非要在初始化阶段的后置处理器中替换掉正常流程中的Bean，例如增加一个后置处理器：
@Component
public class MyPostProcessor implements BeanPostProcessor {
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (beanName.equals("a")) {
return new A();
}
return bean;
}
}
不过，请不要做这种骚操作，徒增烦恼！
-
初始化的时候是对A对象本身进行初始化，而容器中以及注入到B中的都是代理对象，这样不会有问题吗？
答：不会，这是因为不管是
cglib代理还是jdk动态代理生成的代理类，内部都持有一个目标类的引用，当调用代理对象的方法时，实际会去调用目标对象的方法，A完成初始化相当于代理对象自身也完成了初始化 -
三级缓存为什么要使用工厂而不是直接使用引用？换而言之，为什么需要这个三级缓存，直接通过二级缓存暴露一个引用不行吗？🤔
答：这个工厂的目的在于延迟对实例化阶段生成的对象的代理，只有真正发生循环依赖的时候，才去提前生成代理对象，否则只会创建一个工厂并将其放入到三级缓存中，但是不会去通过这个工厂去真正创建对象
我们思考一种简单的情况，就以单独创建A为例，假设AB之间现在没有依赖关系，但是A被代理了，这个时候当A完成实例化后还是会进入下面这段代码：
// A是单例的，mbd.isSingleton()条件满足
// allowCircularReferences：这个变量代表是否允许循环依赖，默认是开启的，条件也满足
// isSingletonCurrentlyInCreation：正在在创建A，也满足
// 所以earlySingletonExposure=true
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
// 还是会进入到这段代码中
if (earlySingletonExposure) {
// 还是会通过三级缓存提前暴露一个工厂对象
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
看到了吧，即使没有循环依赖，也会将其添加到三级缓存中，而且是不得不添加到三级缓存中，因为到目前为止Spring也不能确定这个Bean有没有跟别的Bean出现循环依赖。
假设我们在这里直接使用二级缓存的话，那么意味着所有的Bean在这一步都要完成AOP代理。这样做有必要吗？
不仅没有必要，而且违背了Spring在结合AOP跟Bean的生命周期的设计！Spring结合AOP跟Bean的生命周期本身就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来完成的，在这个后置处理的postProcessAfterInitialization方法中对初始化后的Bean完成AOP代理。如果出现了循环依赖，那没有办法，只有给Bean先创建代理，但是没有出现循环依赖的情况下，设计之初就是让Bean在生命周期的最后一步完成代理而不是在实例化后就立马完成代理。
三级缓存真的提高了效率了吗？
现在我们已经知道了三级缓存的真正作用，但是这个答案可能还无法说服你，所以我们再最后总结分析一波，三级缓存真的提高了效率了吗？分为两点讨论：
-
没有进行
AOP的Bean间的循环依赖从上文分析可以看出，这种情况下三级缓存根本没用！所以不会存在什么提高了效率的说法
-
进行了
AOP的Bean间的循环依赖就以我们上的A、B为例，其中A被
AOP代理，我们先分析下使用了三级缓存的情况下，A、B的创建流程
假设不使用三级缓存，直接在二级缓存中
上面两个流程的唯一区别在于为A对象创建代理的时机不同，在使用了三级缓存的情况下为A创建代理的时机是在B中需要注入A的时候，而不使用三级缓存的话在A实例化后就需要马上为A创建代理然后放入到二级缓存中去。
对于整个A、B的创建过程而言，消耗的时间是一样的。
综上，不管是哪种情况，三级缓存提高了效率这种说法都是错误的！
总结
面试官：”Spring是如何解决的循环依赖？“
答：Spring通过三级缓存解决了循环依赖，其中一级缓存为单例池（singletonObjects）,二级缓存为早期曝光对象earlySingletonObjects，三级缓存为早期曝光对象工厂（singletonFactories）。
当A、B两个类发生循环引用时，在A完成实例化后，就使用实例化后的对象去创建一个对象工厂，并添加到三级缓存中，如果A被AOP代理，那么通过这个工厂获取到的就是A代理后的对象，如果A没有被AOP代理，那么这个工厂获取到的就是A实例化的对象。
当A进行属性注入时，会去创建B，同时B又依赖了A，所以创建B的同时又会去调用getBean(a)来获取需要的依赖，此时的getBean(a)会从缓存中获取：
第一步，先获取到三级缓存中的工厂；
第二步，调用对象工工厂的getObject方法来获取到对应的对象，得到这个对象后将其注入到B中(把三级缓存里面的这个A放到二级缓存里面，并删除三级缓存里面的A)。紧接着B会走完它的生命周期流程，包括初始化、后置处理器等。
当B创建完后(此时B里面的A依然是创建中状态)，会将B再注入到A中(直接从一级缓存里面拿到B)，此时A再完成它的整个生命周期(将A自己放到一级缓存里)。至此，循环依赖结束！
面试官：”为什么要使用三级缓存呢？二级缓存能解决循环依赖吗？“
答：如果要使用二级缓存解决循环依赖，意味着所有Bean在实例化后就要完成AOP代理，这样违背了Spring设计的原则，Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理，而不是在实例化后就立马进行AOP代理。
既已览卷至此，何不品评一二：