Spring 循环依赖 AOP 实现

时间:2022-09-27 码农参上人气:0

前言：

我们接着上一篇文章继续往下看，首先看一下下面的例子，前面的两个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方法：

执行AbstractAutoProxyCreator的postProcessAfterInitialization方法：

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的过程。

回过头来再梳理一下，因为之前进行过循环依赖，所以提前执行了AbstractAutoProxyCreator的getEarlyBeanReference方法，执行了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、此外，除去本文中提到的通过属性的方式注入依赖的情况外，大家可能会好奇如果使用构造函数能否实现循环依赖，结果是不可以的。具体的调用过程这里不再多说，有兴趣的同学可以自己再对照源码进行一下梳理。

加载全部内容