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

到此这篇关于Spring 循环依赖之AOP实现详情的文章就介绍到这了,更多相关Spring 循环依赖 AOP 实现内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！