亲宝软件园·资讯

展开

Spring 循环依赖 AOP 实现

​ 码农参上 ​ 人气: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.

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

再回头看上面的错误,大意为在循环依赖中我们给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的代理对象,因此不用找三级缓存直接返回这个代理对象,并最终把这个代理对象添加到一级缓存单例池中。

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

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

我们发现,在生成的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进行包装,循环依赖的问题还是不能解决的。

总结:

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

加载全部内容

相关教程
猜你喜欢
用户评论