Spring源码分析(七)SpringAOP生成代理类及执行的过程

1、AOP的入口

上一节我们在分析解析AOP标签的时候,第一步就是注册了一个类AspectJAwareAdvisorAutoProxyCreator,我们说它是AOP的入口类。为什么这样说呢?
来看它父类的父类AbstractAutoProxyCreator,它继承了BeanPostProcessor接口。
那么,有两个方法肯定要被调用到postProcessBeforeInitialization、postProcessAfterInitialization。一个在依赖注入完成之前调用,一个在之后调用。

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

wrapIfNecessary方法则是真正产生代理的地方,我们先看下它的内部实现。

protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
    // Create proxy if we have advice.
    //先看它的注释,大意说:如果有通知,就创建代理。
    //其实就是在bean.getClass()找到所有的通知和advisor
    //这里面其实又分为两个步骤:
    //第一,在Bean工厂找到所有的Advisor 第二,根据beanClass和Pointcut去做匹配
    Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
    if (specificInterceptors != DO_NOT_PROXY) {
        this.advisedBeans.put(cacheKey, Boolean.TRUE);
        //真正创建代理并返回,这时候返回的就是代理类了,把真实的bean替换掉
        Object proxy = createProxy(bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
        this.proxyTypes.put(cacheKey, proxy.getClass());
        return proxy;
    }
    this.advisedBeans.put(cacheKey, Boolean.FALSE);
    return bean;
}

看到上面的源码,整个过程就分为了两步,匹配和创建返回。这样就完成了代理类的替换,是不是有点偷梁换柱的感觉。

匹配

先是找到所有的Advisor,这个比较简单。因为我们知道,在解析的时候就把配置的通知封装成advisor注册了进去。首先拿到beanDefinitionNames容器所有beanName,循环判断bean的类型是不是advisor接口的类型,符合条件返回。

public List<Advisor> findAdvisorBeans() {
    // Determine list of advisor bean names, if not cached already.
    String[] advisorNames = null;
    
    //先拿到beanName
    advisorNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(
            this.beanFactory, Advisor.class, true, false);
        
    List<Advisor> advisors = new LinkedList<Advisor>();
    for (String name : advisorNames) {
        if (isEligibleBean(name)) {     
            try {
                //再从Bean工厂中拿bean的实例
                advisors.add(this.beanFactory.getBean(name, Advisor.class));
            }
        }
    }
    //返回的advisors就是配置文件中所有的advice和advisor
    return advisors;
}

找到advisors并未结束,还要跟pointcut做匹配,看这些advisor符不符合表达式条件。它最终调用到Pointcut的match方法。这个方法嵌套的太深,就不贴代码了,核心思想就是判断class和class对应的method是否与pointcut表达式匹配。

创建代理

经过上面查找匹配后,确定当前的bean确实需要代理,就调用createProxy方法。

  • 设置代理工厂
protected Object createProxy(Class<?> beanClass, 
        String beanName, Object[] specificInterceptors, TargetSource targetSource) {
    //创建代理工厂
    ProxyFactory proxyFactory = new ProxyFactory();
    // Copy our properties (proxyTargetClass etc) inherited from ProxyConfig.
    proxyFactory.copyFrom(this);

    //将beanClass上的接口设置到代理工厂
    evaluateProxyInterfaces(beanClass, proxyFactory);
        
    //设置Advisor到代理工厂
    Advisor[] advisors = buildAdvisors(beanName, specificInterceptors);
    for (Advisor advisor : advisors) {
        proxyFactory.addAdvisor(advisor);
    }
    //设置目标对象
    proxyFactory.setTargetSource(targetSource);
    return proxyFactory.getProxy(this.proxyClassLoader);
}
  • 创建

创建代理分为JDK的代理和Cglib的代理,这里我们先关注JDK的代理。getProxy方法就调用到JdkDynamicAopProxy类的方法。这个类还实现了InvocationHandler接口,说明它同时还是调用处理程序。即在调用代理类的invoke方法时,实际上就会调用到JdkDynamicAopProxy.invoke()

public Object getProxy(ClassLoader classLoader) {
    //这里又给代理工厂加了两个接口 SpringProxy和Advised
    Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised);
    
    //这个方法就比较熟悉了,正是JDK动态代理的方法
    //这里的this就是JdkDynamicAopProxy实例。
    return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}

2、代理类的调用

在实例化Bean和完成依赖注入后,会判断当前的Bean是否需要代理,如果需要,就生成代理类把原始类替换掉。在业务方法里面调用的时候,就会调用到JdkDynamicAopProxy.invoke()

在执行invoke的时候,我们又可以分为两个步骤...-_-||,是不是跟二很有缘,每次都是两个步骤。。

  1. 获取方法的拦截链

首先从代理工厂中拿到所有的advisor,然后判断是不是PointcutAdvisor类型,其次先matches一下targetClass,再matches一下method,证明这个类的方法在pointcut范围内,加入interceptorList,最后返回。

public List<Object> getInterceptorsAndDynamicInterceptionAdvice(
            Advised config, Method method, Class<?> targetClass) {
    List<Object> interceptorList = new ArrayList<Object>(config.getAdvisors().length);
    //config就是代理工厂的实例
    for (Advisor advisor : config.getAdvisors()) {
        if (advisor instanceof PointcutAdvisor) {
            PointcutAdvisor pointcutAdvisor = (PointcutAdvisor) advisor;
            if (config.isPreFiltered() || pointcutAdvisor.getPointcut().getClassFilter().matches(targetClass)) {
                MethodInterceptor[] interceptors = registry.getInterceptors(advisor);
                MethodMatcher mm = pointcutAdvisor.getPointcut().getMethodMatcher();
                if (MethodMatchers.matches(mm, method, targetClass, hasIntroductions)) {
                    interceptorList.addAll(Arrays.asList(interceptors));
                }
            }
        }
    }
    return interceptorList;
}
  1. 调用

拿到方法的拦截链,然后调用。调用的时候有个地方比较有意思。它先创建了一个对象ReflectiveMethodInvocation。这个对象有两个参数

currentInterceptorIndex   //当前调用的拦截器的索引,默认值-1
interceptorsAndDynamicMethodMatchers   //拦截器的列表

然后看它的调用方法。

public Object proceed() throws Throwable {
    
    //如果俩个变量相等,说明已经调用完了所有的拦截器
    if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
        //执行被代理方法
        return invokeJoinpoint();
    }
    //从-1开始,每次累加1。interceptorOrInterceptionAdvice就是对应的每一个通知
    //比如before、after、after-returning...
    //对应的实例类分别是:
    //MethodBeforeAdviceInterceptor、AspectJAfterAdvice、AfterReturningAdviceInterceptor
    Object interceptorOrInterceptionAdvice =
            this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
            
    
    //在调用具体通知的invoke方法时,把当前对象当参数传了过去。
    //因为在具体的通知执行之后还要回调回来,执行当前对象的proceed().
    //这样就形成了一个通知调用链,当所有的通知执行完毕,调用上面的invokeJoinpoint()
    return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
}

看完它的调用流程,我们还有一个疑问。通知一共有5种类型,前置通知、后置通知、方法返回后通知、环绕通知、异常通知。那么,它是怎么保证调用顺序的呢?
我们来看两个通知类里面具体的实现。

前置通知
public Object invoke(MethodInvocation mi) throws Throwable {
    //这个比较简单,执行完before就回调
    this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
    return mi.proceed();
}
后置通知
public Object invoke(MethodInvocation mi) throws Throwable {
    //这个就比较有趣了,它先执行回调
    //通过finally机制再执行自己的通知方法
    try {
        return mi.proceed();
    }
    finally {
        invokeAdviceMethod(getJoinPointMatch(), null, null);
    }
}
环绕通知
//环绕通知会调用到切面类的自定义方法
public Object aroundAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
    System.out.println("环绕通知之前");
    //可以自己判断还要不要回调回去。
    //回调回去的话,接着循环调用链
    //如果不再回调,就要看链的顺序了,在它之后的就不再执行
    Object result = joinPoint.proceed();
    System.out.println("环绕通知之后");
    return result;
}

3、基于注解的AOP

如果想使用注解AOP,需要开启一个配置。<aop:aspectj-autoproxy />。Spring解析配置标签的时候,调用到AspectJAutoProxyBeanDefinitionParser.parse()
这个方法主要就干了一件事:注册入口类AnnotationAwareAspectJAutoProxyCreator
XML配置方式的AOP,Spring注册的入口类叫做AspectJAwareAdvisorAutoProxyCreator

它们的调用流程是一样的,都是在实例化之后调用爷爷类的AbstractAutoProxyCreator.postProcessAfterInitialization()。回忆一下,wrapIfNecessary方法是真正产生代理的地方。它先获取所有的通知并与当前的bean class匹配,如果有,就说明当前的Bean需要代理,则产生代理类。我们知道,在XML配置方式的AOP中,Spring把配置的通知都封装成advisor注册到容器里,所以在获取的时候,直接在Bean工厂中匹配Advisor类型的Bean就行。
但是,在解析注解AOP的时候,我们看到它只是注册了一个入口类而已呀,并没有注册advisor,那么,在这里怎么获取呢?

目光回到查询advisor的方法。

protected List<Advisor> findCandidateAdvisors() {
    // Add all the Spring advisors found according to superclass rules.
    // 这个是查询XML配置方式的advoisor
    List<Advisor> advisors = super.findCandidateAdvisors();
    // Build Advisors for all AspectJ aspects in the bean factory.
    // 这个就是查询注解方式的advisor
    advisors.addAll(this.aspectJAdvisorsBuilder.buildAspectJAdvisors());
    return advisors;
}

buildAspectJAdvisors方法查询advisor的时候,它大致可以分3个步骤。

  • 从Bean工厂获取所有的beanName
    String[] beanNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(this.beanFactory, Object.class, true, false);

  • 循环beanNames,判断bean是否包含Aspect注解

for (String beanName : beanNames) {
    Class<?> beanType = this.beanFactory.getType(beanName);
    if (this.advisorFactory.isAspect(beanType)) {
        aspectNames.add(beanName);
        ......
    }
}
  • 获取Advisors。先拿到Class对象上的所有Method对象,根据Method对象的Annotation类型,返回不同的Advice对象。这个跟XML方式返回的Advice对象是一样的。
switch (aspectJAnnotation.getAnnotationType()) {
    case AtBefore:
        springAdvice = new AspectJMethodBeforeAdvice(candidateAdviceMethod, ajexp, aif);
        break;
    case AtAfter:
        springAdvice = new AspectJAfterAdvice(candidateAdviceMethod, ajexp, aif);
        break;
    case AtAfterReturning:
        springAdvice = new AspectJAfterReturningAdvice(candidateAdviceMethod, ajexp, aif);
        AfterReturning afterReturningAnnotation = (AfterReturning) aspectJAnnotation.getAnnotation();
        if (StringUtils.hasText(afterReturningAnnotation.returning())) {
            springAdvice.setReturningName(afterReturningAnnotation.returning());
        }
        break;
    case AtAfterThrowing:
        springAdvice = new AspectJAfterThrowingAdvice(candidateAdviceMethod, ajexp, aif);
        AfterThrowing afterThrowingAnnotation = (AfterThrowing) aspectJAnnotation.getAnnotation();
        if (StringUtils.hasText(afterThrowingAnnotation.throwing())) {
            springAdvice.setThrowingName(afterThrowingAnnotation.throwing());
        }
        break;
    case AtAround:
        springAdvice = new AspectJAroundAdvice(candidateAdviceMethod, ajexp, aif);
        break;
    case AtPointcut:
        if (logger.isDebugEnabled()) {
            logger.debug("Processing pointcut '" + candidateAdviceMethod.getName() + "'");
        }
        return null;
    default:
        throw new UnsupportedOperationException(
                "Unsupported advice type on method " + candidateAdviceMethod);
}

最后将advice和pointcut封装成InstantiationModelAwarePointcutAdvisorImpl对象返回。返回之后,创建代理类进行替换。

由此看来,注解方式的AOP,是在查询Advisors的时候才去解析并生成的,其他的与XML的配置方式处理流程都是一样的。

4、 总结

本章节我们重点阐述了3个问题。即怎样产生代理类、代理类的执行过程、AnnotationAOP的处理流程。结合本章节和上一章节的内容,可能使我们对Spring AOP的内部处理流程加深了印象。

  • 怎样产生代理类?
    通过循环beanNames实例化Bean对象,判断此对象是否与pointcut表达式匹配。如果匹配就根据advice生成不同的advisor对象,然后调用JDK或者CGLIB的方法生成代理类返回。

  • 代理类执行
    调用JDK或者CGLIB的invoke方法,查询advisor的调用链。链式调用,根据通知类型调用不同的advice实现增强。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,539评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,911评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,337评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,723评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,795评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,762评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,742评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,508评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,954评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,247评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,404评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,104评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,736评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,352评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,557评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,371评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,292评论 2 352

推荐阅读更多精彩内容