Spring源码-Spring中循环依赖

什么是循环依赖

代码中的样子就是:

@Component
public class A {
    // A中注入了B
    @Autowired
    private B b;
}
@Component
public class B {
    // B中也注入了A
    @Autowired
    private A a;
}

什么情况下循环依赖可以被处理?

Spring解决循环依赖是有前置条件的

  1. 出现循环依赖的Bean必须是单例
  2. 依赖注入的方式不能全是构造器注入(只能解决setter方法的循环依赖,这是错误的)

Spring源码-Spring中循环依赖_第1张图片

如何解决循环依赖?

简单的循环依赖(没有AOP)

@Component
public class A {
     // A中注入了B
     @Autowired
     private B b;
}
@Component
public class B {
     // B中也注入了A
     @Autowired
     private A a;
}

Spring在创建Bean的时候默认是按照自然顺序来进行创建的,所以第一步Spring会去创建A。创建Bean的过程分为三步:

1. 实例化,对应方法:AbstractAutowireCapableBeanFactory中的createBeanInstance方法,就是new了一个对象

2. 属性注入,对应方法:AbstractAutowireCapableBeanFactorypopulateBean方法,为实例化中new出来的对象填充属性

3. 初始化,对应方法:AbstractAutowireCapableBeanFactoryinitializeBean ,执行aware接口中的方法,初始化方法,完成AOP代理

创建A的过程实际上就是调用getBean方法,有两层含义:

  1. 创建一个新的Bean
  2. 从缓存中获取到已经被创建的对象

首先分析创建一个新的Bean,即没有A

调用getSingleton(beanName),这个方法会调用getSingleton(beanName, true)

public Object getSingleton(String beanName) {
    return getSingleton(beanName, true);
}

getSingleton(beanName, true)这个方法实际上就是到缓存中尝试去获取Bean,整个缓存分为三级:

  1. singletonObjects:一级缓存,存储的是所有创建好了的单例Bean
  2. earlySingletonObjects:完成实例化,但是还未进行属性注入及初始化的对象
  3. singletonFactories:提前暴露一个单例工厂,二级缓存中存储的就是从这个工厂中获取到的对象

由于A第一次创建,哪一个缓存都没有,因此会进入getSingleton的一个重载方法,getSingleton(beanName, singletonFactory)

调用getSingleton(beanName, singletonFactory)

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

doCreateBean中调用addSingletonFactory方法

Spring源码-Spring中循环依赖_第2张图片

在完成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方法完成属性注入

Spring源码-Spring中循环依赖_第3张图片

因为B需要注入A,所以在创建B的时候,又会去调用getBean(a),这个时候就又回到之前的流程了,但是不同的是,之前的getBean是为了创建Bean,而此时再调用getBean不是为了创建了,而是要从缓存中获取,因为之前A在实例化后已经将其放入了三级缓存singletonFactories中,所以此时getBean(a)的流程就是这样子了

Spring源码-Spring中循环依赖_第4张图片

从这里我们可以看出,注入到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的流程走完,如下图:

Spring源码-Spring中循环依赖_第5张图片

从上图中我们可以看到,虽然在创建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的实例化阶段创建后的对象。

Spring源码-Spring中循环依赖_第6张图片

问题1: 在给B注入的时候为什么要注入一个代理对象?

答:对A进行了AOP代理时,说明我们希望从容器中获取到的就是A代理后的对象而不是A本身,因此把A当作依赖进行注入时也要注入它的代理对象

问题2: 明明初始化的时候是A对象,那么Spring是在哪里将代理对象放入到容器中的呢?

下面为doCreateBean的部分代码

Spring源码-Spring中循环依赖_第7张图片

完成初始化后,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;
  }
}

问题3: 初始化的时候是对A对象本身进行初始化,而容器中以及注入到B中的都是代理对象,不会有问题吗?

答:不会,因为不管是cglib代理还是jdk动态代理生成的代理类,内部都持有一个目标类的引用,当调用代理对象的方法时,实际会去调用目标对象的方法,A完成初始化相当于代理对象自身完成了初始化

问题4: 三级缓存为什么要使用工厂而不是直接使用引用?为什么需要这个三级缓存,直接通过二级缓存暴露一个引用不行吗?

答:这个工厂的目的在于延迟对实例化阶段生成的对象的代理,只有真正发生循环依赖的时候,才去提前生成代理对象,否则只会创建一个工厂并将其放入到三级缓存中,但是不会去通过这个工厂去真正创建对象。

以单例创建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的生命周期本身就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来完成的,在这个后置处理的postProcessAfterInitialization方法中对初始化后的Bean完成AOP代理。如果出现了循环依赖,那没有办法,只有给Bean先创建代理,但是没有出现循环依赖的情况下,设计之初就是让Bean在生命周期的最后一步完成代理而不是在实例化后就立马完成代理。

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中。紧接着B会走完它的生命周期流程,包括初始化、后置处理器等。当B创建完后,会将B再注入到A中,此时A再完成它的整个生命周期。至此,循环依赖结束

为什么使用三级缓存?二级缓存能解决循环依赖吗?

答:如果要使用二级缓存解决循环依赖,意味着所有Bean在实例化后就要完成AOP代理,这样违背了Spring设计的原则,Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理,而不是在实例化后就立马进行AOP代理。

 

 

你可能感兴趣的:(Spring源码学习)