Spring循环依赖源码解析

Hydra大约 14 分钟Spring

上篇文章中我们分析完了Spring中Bean的实例化过程,但是没有对循环依赖的问题进行分析,这篇文章中我们来看一下spring是如何解决循环依赖的实现。

之前在讲spring的过程中,我们提到了一个spring的单例池singletonObjects,用于存放创建好的bean,也提到过这个Map也可以说是狭义上的spring容器。

private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);

其实spring在缓存bean的过程中并不是只有这一个Map,我们看一下DefaultSingletonBeanRegistry这个类,在其中其实存在3个Map,这也就是经常提到的spring三级缓存。

/** Cache of singleton objects: bean name --> bean instance */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);
/** Cache of early singleton objects: bean name --> bean instance */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);
/** Cache of singleton factories: bean name --> ObjectFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);

从上到下分别为一到三级缓存,这里先对三级缓存有一个初步的认识,后面使用到的时候我们再详细分析。

循环依赖实现流程

下面开始分析spring循环依赖的注入实现过程。先写两个bean,在它们中分别注入了对方:

@Component
public class ServiceA {
  @Autowired
  ServiceB serviceB;  
  
  public ServiceB getServiceB() {
    System.out.println("get ServiceB");
    return serviceB;
  }
}
@Component
public class ServiceB {
  @Autowired
  ServiceA serviceA;  
  
  public ServiceA getServiceA() {
    return serviceA;
  }
}

进行测试,分别调用它们的get方法,能够正常获得bean,说明循环依赖是可以实现的:

com.hydra.service.ServiceB@58fdd99
com.hydra.service.ServiceA@6b1274d2

首先,回顾一下上篇文章中讲过的bean实例化的流程。下面的内容较多依赖于spring的bean实例化源码,如果不熟悉建议花点时间阅读一下上篇文章。

AbstractAutowireCapableBeanFactorydoCreateBean方法中,调用createBeanInstance方法创建一个原生对象,之后调用populateBean方法执行属性的填充,最后调用各种回调方法和后置处理器。

但是在执行populateBean方法前,上篇文章中省略了一些涉及到循环依赖的内容,看一下下面这段代码:

图片
图片

上面的代码先进行判断:如果当前创建的是单例bean,并且允许循环依赖,并且处于创建过程中,那么执行下面的addSingletonFactory方法。

图片
图片

主要工作为将lambda表达式代表的ObjectFactory,放入三级缓存的Map中。注意这里只是一个存放的操作,并没有实际执行lambda表达式中的内容,具体调用过程是在后面调用ObjectFactory的getObject方法时调用。这个方法执行完成后,三级缓存中存放了一条serviceA的数据,二级缓存仍然为空。

回到正常调用流程,生成原生对象后,调用populateBean方法进行属性的赋值也就是依赖注入,具体是通过执行AutowiredAnnotationBeanPostProcessor这一后置处理器的postProcessPropertyValues方法。

在这一过程中,serviceA会找到它依赖的serviceB这一属性,当发现依赖后,会调用DefaultListableBeanFactorydoResolveDependency方法,之后执行resolveCandidate方法,在该方法中,尝试使用beanFactory获取到serviceB的bean实例。

public Object resolveCandidate(String beanName, Class<?> requiredType, BeanFactory beanFactory)
      throws BeansException {
    return beanFactory.getBean(beanName);
  }

这时和之前没有循环依赖时的情况就会有些不一样了,因为现在serviceB还没有被创建出来,所以通过beanFactory是无法直接获取的。因此当在doGetBean方法中调用getSingleton方法会返回一个null值:

图片
图片

因此,继续使用与之前相同的创建bean的流程,实例化serviceB的bean对象。当serviceB的原生对象被实例化完成后,同样可以看到它依赖的serviceA还没有被赋值:

图片
图片

创建完serviceB的原生对象后,同样执行addSingletonFactory方法,将serviceB放入三级缓存中,执行完成后,三级缓存中就已经存在了两个bean的缓存:

图片
图片

向下执行,serviceB会调用populateBean方法进行属性填充。和之前serviceA依赖serviceB相同的调用链,执行到resolveCandidate方法,尝试使用beanFactorygetBean去获取serviceA

图片
图片

向下执行,调用getSingleton方法尝试直接获取serviceA,此时三级缓存singletonFactories中我们之前已经存进去了一个key为serviceAbeanName,value为lambda表达式,这时可以直接获取到。

图片
图片

在执行singletonFactorygetObject方法时才去真正执行lambda表达式中的方法,实际执行的是getEarlyBeanReference方法:

图片
图片

在遍历后置处理器后,获取到serviceA的执行过后置处理器后的对象,执行:

this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);

这里将serviceA放入二级缓存earlySingletonObjects,并从三级缓存singletonFactories中移除。在这一步执行完后,三级缓存中的serviceA就没有了。

当我们从缓存中获取了serviceA的bean后,就不会再调用createBean去重复创建新的bean了。之后,顺调用链返回serviceB调用的doResolveDependency方法:

图片
图片

serviceB就成功获取到了它的依赖的serviceA属性的bean对象,回到inject方法,使用反射给serviceA赋值成功。

图片
图片

回到doCreateBean的方法,可以看到serviceBserviceA属性已经被注入了,但是serviceA中的serviceB属性还是null。说明serviceB的依赖注入已经完成,而serviceA的依赖注入还没做完。

图片
图片

现在我们梳理一下运行到这里的流程:

1、在serviceA填充属性过程中发现依赖了serviceB,通过beanFactorygetBean方法,尝试获取serviceB

2、serviceB不存在,执行了一遍serviceB的创建流程,填充属性时发现serviceA已经存在于三级缓存,直接注入给serviceB

可以看到,在创建serviceA的过程中发现依赖的serviceB不存在,转而去创建了serviceB,而创建serviceA的流程并没有执行完,因此在创建完serviceB后再顺调用链返回,直到doResolveDependency方法:

图片
图片

可以看到,需要依赖的serviceB已经被创建并返回成功,返回到inject方法,同样通过反射给serviceB赋值:

图片
图片

返回doCreateBean方法,可以看到serviceAserviceB之间的循环依赖已经完成了:

图片
图片

这样,一个最简单的循环依赖流程就结束了。有的小伙伴可能会提出疑问,这样的话,我只需要添加一个缓存存放原生对象就够了啊,为什么还需要二级缓存和三级缓存两层结构呢?

AOP下循环依赖具体实现

我们看看下面的例子,前面的两个serviceA和serviceB不变,我们添加一个BeanPostProcessor

@Component
public class MyPostProcessor implements BeanPostProcessor {
   @Override
   public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
       if (beanName.equals("serviceA")){
           System.out.println("create new ServiceA");
           return new ServiceA();
       }
       return bean;
   }
}

运行一下,结果报错了:

Exception in thread "main" org.springframework.beans.factory.BeanCurrentlyInCreationException: 
Error creating bean with name 'serviceA': Bean with name 'serviceA' 
has been injected into other beans [serviceB] in its raw version as 
part of a circular reference, but has eventually been wrapped. This 
means that said other beans do not use the final version of the bean.
This is often the result of over-eager type matching - consider 
using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned 
off, for example.

在分析错误之前,我们再梳理一下正常循环依赖的过程:

1、初始化原生对象serviceA,放入三级缓存

2、serviceA填充属性,发现依赖serviceB,创建依赖对象

3、创建serviceB,填充属性发现依赖serviceA,从三级缓存中找到填充

4、执行serviceB的后置处理器和回调方法,放入单例池

5、执行serviceA的后置处理器和回调方法,放入单例池

再回头看上面的错误,大意为在循环依赖中我们给serviceB注入了serviceA,但是注入之后我们又在后置处理器中对serviceA进行了包装,因此导致了serviceB中注入的和最后生成的serviceA不一致。

但是熟悉aop的同学应该知道,aop的底层也是利用后置处理器实现的啊,那么为什么aop就可以正常执行呢?我们添加一个切面横切serviceA的getServiceB方法:

@Component
@Aspect
public class MyAspect {
    @Around("execution(* com.hydra.service.ServiceA.getServiceB())")
    public void invoke(ProceedingJoinPoint pjp){
        try{
            System.out.println("execute aop around method");
            pjp.proceed();
        }catch (Throwable e){
            e.printStackTrace();
        }
    }
}

先不看运行结果,代码可以正常执行不出现异常,那么aop是怎么实现的呢?

前面的流程和不使用aop相同,我们运行到serviceB需要注入serviceA的地方,调用getSingleton方法从三级缓存中获取serviceA存储的singletonFactory,调用getEarlyBeanReference方法。在该方法中遍历执行SmartInstantiationAwareBeanPostProcessor后置处理器的getEarlyBeanReference方法:

图片
图片

看一下都有哪些类实现了这个方法:

图片
图片

在spring中,就是这个AbstractAutoProxyCreator负责实现了aop,进入getEarlyBeanReference方法:

public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
    //beanName
    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    this.earlyProxyReferences.put(cacheKey, bean); 
    //产生代理对象
    return wrapIfNecessary(bean, beanName, cacheKey); 
}

earlyProxyReferences 是一个Map,用于缓存bean的原始对象,也就是执行aop之前的bean,非常重要,在后面还会用到这个Map:

Map<Object, Object> earlyProxyReferences = new ConcurrentHashMap<>(16);

记住下面这个wrapIfNecessary方法,它才是真正负责生成代理对象的方法:

图片
图片

上面首先解析并拿到所有的切面,调用createProxy方法创建代理对象并返回。然后回到getSingleton方法中,将serviceA加入二级缓存,并从三级缓存中移除掉。

图片
图片

可以看到,二级缓存中的serviceA已经是被cglib代理过的代理对象了,当然这时的serviceA还是没有属性值填充的。

那么这里又会有一个问题,我们之前讲过,在填充完属性后,会调用后置处理器中的方法,而这些方法都是基于原始对象的,而不是代理对象。

图片
图片

在前一篇文章中我们也讲过,在initializeBean方法中会执行后置处理器,并且正常情况下aop也是在这里完成的。那么我们就要面临一个问题,如果避免重复执行aop的过程。在initializeBean方法中:

if (mbd == null || !mbd.isSynthetic()) {
  wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}

调用applyBeanPostProcessorsAfterInitialization,执行所有后置处理器的after方法:

图片
图片

执行AbstractAutoProxyCreatorpostProcessAfterInitialization方法:

public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) throws BeansException {
  if (bean != null) {
    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    if (this.earlyProxyReferences.remove(cacheKey) != bean) {
      return wrapIfNecessary(bean, beanName, cacheKey);
    }
  }
  return bean;
}

earlyProxyReferences 我们之前说过非常重要,它缓存了进行aop之前的原始对象,并且这里参数传入的Object也是原始对象。因此在这里执行remove操作的判断语句返回false,不会执行if中的语句,不会再执行一遍aop的过程。

回过头来再梳理一下,因为之前进行过循环依赖,所以提前执行了AbstractAutoProxyCreatorgetEarlyBeanReference方法,执行了aop的过程,在earlyProxyReferences中缓存了原生对象。因此在循环依赖的情况下,等式成立,直接返回。而在没有循环依赖的普通情况下,earlyProxyReferences执行remove返回为null,等式不成立,正常执行aop流程。

需要注意的是,这个方法中最终返回的还是原始对象,而不是aop后的代理对象。执行到这一步,我们先看一下嵌套的状态:

图片
图片

对外暴露的serviceA是原始对象,依赖的serviceB已经被注入了。而serviceB中依赖的serviceA是代理对象,并且这个代理对象依赖的serviceB还没有被注入。

向下执行:

图片
图片

再次通过getSingleton获取serviceA:

图片
图片

这次我们通过二级缓存就可以拿到之前经过aop的代理对象,因此不用找三级缓存直接返回这个代理对象,并最终把这个代理对象添加到一级缓存单例池中。

到这,我们对三级缓存的作用做一个总结:

1、singletonObjects:单例池,缓存了经过完整生命周期的bean

2、earlySingletonObjects:缓存了提前曝光的原始对象,注意这里存的还不是bean,这里存的对象经过了aop的代理,但是没有执行属性的填充以及后置处理器方法的执行

3、singletonFactories:缓存的是ObjectFactory,主要用来去生成原始对象进行了aop之后得到的代理对象。在每个bean的生成过程中,都会提前在这里缓存一个工厂。如果没有出现循环依赖依赖这个bean,那么这个工厂不会起到作用,按照正常生命周期执行,执行完后直接把本bean放入一级缓存中。如果出现了循环依赖依赖了这个bean,没有aop的情况下直接返回原始对象,有aop的情况下返回代理对象。

全部创建流程结束,看一下结果:

图片
图片

我们发现,在生成的serviceA的cglib代理对象中,serviceB属性值并没有被填充,只有serviceB中serviceA的属性填充成功了。

图片
图片

可以看到如果使用cglib,在代理对象的target中会包裹一个原始对象,而原始对象的属性是被填充过的。

那么,如果不使用cglib代理,而使用jdk动态代理呢?我们对之前的代码进行一下改造,添加两个接口:

public interface IServiceA {
    public IServiceB getServiceB();
}
public interface IServiceB {
    public IServiceA getServiceA();
}

改造两个Service类:

@Component
public class ServiceA implements IServiceA{
    @Autowired
    private IServiceB serviceB;

    public IServiceB getServiceB() {
        System.out.println("get ServiceB");
        return this.serviceB;
    }
}
@Component
public class ServiceB implements IServiceB{
    @Autowired
    private IServiceA serviceA;

    public IServiceA getServiceA() {
        System.out.println("get ServiceA");
        return serviceA;
    }
}

执行结果:

图片
图片

看一下serviceA的详细信息:

图片
图片

同样也是在target中包裹了原生对象,并在原生对象中注入了serviceB的实例。

综上两种方法,可以看出在我们执行serviceA的getServiceB方法时,都无法正常获取到其bean对象,都会返回一个null值。那么如果非要直接获得这个serviceB应该怎么办呢?

我们可以通过反射的方式,先看cglib代理情况下:

ServiceA serviceA= (ServiceA) context.getBean("serviceA");
Field h = serviceA.getClass().getDeclaredField("CGLIB$CALLBACK_0");
h.setAccessible(true);
Object dynamicAdvisedInterceptor = h.get(serviceA);
Field advised = dynamicAdvisedInterceptor.getClass().getDeclaredField("advised");
advised.setAccessible(true);
Object target = ((AdvisedSupport)advised.get(dynamicAdvisedInterceptor)).getTargetSource().getTarget();
ServiceA serviceA1= (ServiceA) target;
System.out.println(serviceA1.getServiceB());

再看看jdk动态代理情况下:

IServiceA serviceA = (IServiceA) context.getBean("serviceA");
Field h=serviceA.getClass().getSuperclass().getDeclaredField("h");
h.setAccessible(true);
AopProxy aopProxy = (AopProxy) h.get(serviceA);
Field advised = aopProxy.getClass().getDeclaredField("advised");
advised.setAccessible(true);
Object target = ((AdvisedSupport)advised.get(aopProxy)).getTargetSource().getTarget();
ServiceA serviceA1= (ServiceA) target;
System.out.println(serviceA1.getServiceB());

执行结果都能获取到serviceB的实例:

图片
图片

对aop情况下的循环依赖进行一下总结:spring专门为了处理aop情况下的循环依赖提供了特殊的解决方案,但是不论是使用jdk动态代理还是cglib代理,都在代理对象的内部包裹了原始对象,在原始对象中才有依赖的属性。此外,如果我们使用了后置处理器对bean进行包装,循环依赖的问题还是不能解决的。

总结

最后对本文的重点进行一下总结:

1、spring通过借助三级缓存完成了循环依赖的实现,这个过程中要清楚三级缓存分别在什么场景下发挥了什么具体作用

2、产生aop情况下,调用后置处理器并将生成的代理对象提前曝光,并通过额外的一个缓存避免重复执行aop

3、二级缓存和三级缓存只有在产生循环依赖的情况下,才会真正起到作用

4、此外,除去本文中提到的通过属性的方式注入依赖的情况外,大家可能会好奇如果使用构造函数能否实现循环依赖,结果是不可以的。具体的调用过程这里不再多说,有兴趣的同学可以自己再对照源码进行一下梳理。