Spring AOP 源碼分析 - 攔截器鏈的執行過程

時間 2019-11-06

原文原文鏈接

1.簡介

本篇文章是 AOP 源碼分析系列文章的最後一篇文章，在前面的兩篇文章中，我分別介紹了 Spring AOP 是如何爲目標 bean 篩選合適的通知器，以及如何建立代理對象的過程。如今咱們的獲得了 bean 的代理對象，且通知也以合適的方式插在了目標方法的先後。接下來要作的事情，就是執行通知邏輯了。通知可能在目標方法前執行，也可能在目標方法後執行。具體的執行時機，取決於用戶的配置。當目標方法被多個通知匹配到時，Spring 經過引入攔截器鏈來保證每一個通知的正常執行。在本文中，咱們將會經過源碼瞭解到 Spring 是如何支持 expose-proxy 屬性的，以及通知與攔截器之間的關係，攔截器鏈的執行過程等。和上一篇文章同樣，在進行源碼分析前，咱們先來了解一些背景知識。好了，下面進入正題吧。java

2.背景知識

關於 expose-proxy，咱們先來講說它有什麼用，而後再來講說怎麼用。Spring 引入 expose-proxy 特性是爲了解決目標方法調用同對象中其餘方法時，其餘方法的切面邏輯沒法執行的問題。這個解釋可能很差理解，不直觀。那下面我來演示一下它的用法，你們就知道是怎麼回事了。咱們先來看看 expose-proxy 是怎樣配置的，以下：spring

<bean id="hello" class="xyz.coolblog.aop.Hello"/>
<bean id="aopCode" class="xyz.coolblog.aop.AopCode"/>

<aop:aspectj-autoproxy expose-proxy="true" />

<aop:config expose-proxy="true">
    <aop:aspect id="myaspect" ref="aopCode">
        <aop:pointcut id="helloPointcut" expression="execution(* xyz.coolblog.aop.*.hello*(..))" />
        <aop:before method="before" pointcut-ref="helloPointcut" />
    </aop:aspect>
</aop:config>

如上，expose-proxy 可配置在 <aop:config/> 和 <aop:aspectj-autoproxy /> 標籤上。在使用 expose-proxy 時，須要對內部調用進行改造，好比：express

public class Hello implements IHello {

    @Override
    public void hello() {
        System.out.println("hello");
        this.hello("world");
    }

    @Override
    public void hello(String hello) {
        System.out.println("hello " +  hello);
    }
}

hello()方法調用了同類中的另外一個方法hello(String)，此時hello(String)上的切面邏輯就沒法執行了。這裏，咱們要對hello()方法進行改造，強制它調用代理對象中的hello(String)。改造結果以下：數組

public class Hello implements IHello {

    @Override
    public void hello() {
        System.out.println("hello");
        ((IHello) AopContext.currentProxy()).hello("world");
    }

    @Override
    public void hello(String hello) {
        System.out.println("hello " +  hello);
    }
}

如上，AopContext.currentProxy()用於獲取當前的代理對象。當 expose-proxy 被配置爲 true 時，該代理對象會被放入 ThreadLocal 中。關於 expose-proxy，這裏先說這麼多，後面分析源碼時會再次說起。緩存

3.源碼分析

本章所分析的源碼來自 JdkDynamicAopProxy，至於 CglibAopProxy 中的源碼，你們如有興趣能夠本身去看一下。mvc

3.1 JDK 動態代理邏輯分析

本節，我來分析一下 JDK 動態代理邏輯。對於 JDK 動態代理，代理邏輯封裝在 InvocationHandler 接口實現類的 invoke 方法中。JdkDynamicAopProxy 實現了 InvocationHandler 接口，下面咱們就來分析一下 JdkDynamicAopProxy 的 invoke 方法。以下：ide

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    MethodInvocation invocation;
    Object oldProxy = null;
    boolean setProxyContext = false;

    TargetSource targetSource = this.advised.targetSource;
    Class<?> targetClass = null;
    Object target = null;

    try {
        // 省略部分代碼
        Object retVal;

        // 若是 expose-proxy 屬性爲 true，則暴露代理對象
        if (this.advised.exposeProxy) {
            // 向 AopContext 中設置代理對象
            oldProxy = AopContext.setCurrentProxy(proxy);
            setProxyContext = true;
        }

        // 獲取適合當前方法的攔截器
        List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);

        // 若是攔截器鏈爲空，則直接執行目標方法
        if (chain.isEmpty()) {
            Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
            // 經過反射執行目標方法
            retVal = AopUtils.invokeJoinpointUsingReflection(target, method, argsToUse);
        }
        else {
            // 建立一個方法調用器，並將攔截器鏈傳入其中
            invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain);
            // 執行攔截器鏈
            retVal = invocation.proceed();
        }

        // 獲取方法返回值類型
        Class<?> returnType = method.getReturnType();
        if (retVal != null && retVal == target &&
                returnType != Object.class && returnType.isInstance(proxy) &&
                !RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) {
            // 若是方法返回值爲 this，即 return this; 則將代理對象 proxy 賦值給 retVal 
            retVal = proxy;
        }
        // 若是返回值類型爲基礎類型，好比 int，long 等，當返回值爲 null，拋出異常
        else if (retVal == null && returnType != Void.TYPE && returnType.isPrimitive()) {
            throw new AopInvocationException(
                    "Null return value from advice does not match primitive return type for: " + method);
        }
        return retVal;
    }
    finally {
        if (target != null && !targetSource.isStatic()) {
            targetSource.releaseTarget(target);
        }
        if (setProxyContext) {
            AopContext.setCurrentProxy(oldProxy);
        }
    }
}

如上，上面的代碼我作了比較詳細的註釋。下面咱們來總結一下 invoke 方法的執行流程，以下：工具

檢測 expose-proxy 是否爲 true，若爲 true，則暴露代理對象
獲取適合當前方法的攔截器
若是攔截器鏈爲空，則直接經過反射執行目標方法
若攔截器鏈不爲空，則建立方法調用 ReflectiveMethodInvocation 對象
調用 ReflectiveMethodInvocation 對象的 proceed() 方法啓動攔截器鏈
處理返回值，並返回該值

在以上6步中，咱們重點關注第2步和第5步中的邏輯。第2步用於獲取攔截器鏈，第5步則是啓動攔截器鏈。下面先來分析獲取攔截器鏈的過程。源碼分析

3.2 獲取全部的攔截器

所謂的攔截器，顧名思義，是指用於對目標方法的調用進行攔截的一種工具。攔截器的源碼比較簡單，因此咱們直接看源碼好了。下面之前置通知攔截器爲例，以下：this

public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {
    
    /** 前置通知 */
    private MethodBeforeAdvice advice;

    public MethodBeforeAdviceInterceptor(MethodBeforeAdvice advice) {
        Assert.notNull(advice, "Advice must not be null");
        this.advice = advice;
    }

    @Override
    public Object invoke(MethodInvocation mi) throws Throwable {
        // 執行前置通知邏輯
        this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis());
        // 經過 MethodInvocation 調用下一個攔截器，若全部攔截器均執行完，則調用目標方法
        return mi.proceed();
    }
}

如上，前置通知的邏輯在目標方法執行前被執行。這裏先簡單向你們介紹一下攔截器是什麼，關於攔截器更多的描述將放在下一節中。本節咱們先來看看如何如何獲取攔截器，以下：

public List<Object> getInterceptorsAndDynamicInterceptionAdvice(Method method, Class<?> targetClass) {
    MethodCacheKey cacheKey = new MethodCacheKey(method);
    // 從緩存中獲取
    List<Object> cached = this.methodCache.get(cacheKey);
    // 緩存未命中，則進行下一步處理
    if (cached == null) {
        // 獲取全部的攔截器
        cached = this.advisorChainFactory.getInterceptorsAndDynamicInterceptionAdvice(
                this, method, targetClass);
        // 存入緩存
        this.methodCache.put(cacheKey, cached);
    }
    return cached;
}

public List<Object> getInterceptorsAndDynamicInterceptionAdvice(
        Advised config, Method method, Class<?> targetClass) {

    List<Object> interceptorList = new ArrayList<Object>(config.getAdvisors().length);
    Class<?> actualClass = (targetClass != null ? targetClass : method.getDeclaringClass());
    boolean hasIntroductions = hasMatchingIntroductions(config, actualClass);
    // registry 爲 DefaultAdvisorAdapterRegistry 類型
    AdvisorAdapterRegistry registry = GlobalAdvisorAdapterRegistry.getInstance();

    // 遍歷通知器列表
    for (Advisor advisor : config.getAdvisors()) {
        if (advisor instanceof PointcutAdvisor) {
            PointcutAdvisor pointcutAdvisor = (PointcutAdvisor) advisor;
            /*
             * 調用 ClassFilter 對 bean 類型進行匹配，沒法匹配則說明當前通知器
             * 不適合應用在當前 bean 上
             */
            if (config.isPreFiltered() || pointcutAdvisor.getPointcut().getClassFilter().matches(actualClass)) {
                // 將 advisor 中的 advice 轉成相應的攔截器
                MethodInterceptor[] interceptors = registry.getInterceptors(advisor);
                MethodMatcher mm = pointcutAdvisor.getPointcut().getMethodMatcher();
                // 經過方法匹配器對目標方法進行匹配
                if (MethodMatchers.matches(mm, method, actualClass, hasIntroductions)) {
                    // 若 isRuntime 返回 true，則代表 MethodMatcher 要在運行時作一些檢測
                    if (mm.isRuntime()) {
                        for (MethodInterceptor interceptor : interceptors) {
                            interceptorList.add(new InterceptorAndDynamicMethodMatcher(interceptor, mm));
                        }
                    }
                    else {
                        interceptorList.addAll(Arrays.asList(interceptors));
                    }
                }
            }
        }
        else if (advisor instanceof IntroductionAdvisor) {
            IntroductionAdvisor ia = (IntroductionAdvisor) advisor;
            // IntroductionAdvisor 類型的通知器，僅需進行類級別的匹配便可
            if (config.isPreFiltered() || ia.getClassFilter().matches(actualClass)) {
                Interceptor[] interceptors = registry.getInterceptors(advisor);
                interceptorList.addAll(Arrays.asList(interceptors));
            }
        }
        else {
            Interceptor[] interceptors = registry.getInterceptors(advisor);
            interceptorList.addAll(Arrays.asList(interceptors));
        }
    }

    return interceptorList;
}

public MethodInterceptor[] getInterceptors(Advisor advisor) throws UnknownAdviceTypeException {
    List<MethodInterceptor> interceptors = new ArrayList<MethodInterceptor>(3);
    Advice advice = advisor.getAdvice();
    /*
     * 若 advice 是 MethodInterceptor 類型的，直接添加到 interceptors 中便可。
     * 好比 AspectJAfterAdvice 就實現了 MethodInterceptor 接口
     */
    if (advice instanceof MethodInterceptor) {
        interceptors.add((MethodInterceptor) advice);
    }

    /*
     * 對於 AspectJMethodBeforeAdvice 等類型的通知，因爲沒有實現 MethodInterceptor 
     * 接口，因此這裏須要經過適配器進行轉換
     */ 
    for (AdvisorAdapter adapter : this.adapters) {
        if (adapter.supportsAdvice(advice)) {
            interceptors.add(adapter.getInterceptor(advisor));
        }
    }
    if (interceptors.isEmpty()) {
        throw new UnknownAdviceTypeException(advisor.getAdvice());
    }
    return interceptors.toArray(new MethodInterceptor[interceptors.size()]);
}

以上就是獲取攔截器的過程，代碼有點長，不過好在邏輯不是很複雜。這裏簡單總結一下以上源碼的執行過程，以下：

從緩存中獲取當前方法的攔截器鏈
若緩存未命中，則調用 getInterceptorsAndDynamicInterceptionAdvice 獲取攔截器鏈
遍歷通知器列表
對於 PointcutAdvisor 類型的通知器，這裏要調用通知器所持有的切點（Pointcut）對類和方法進行匹配，匹配成功說明應向當前方法織入通知邏輯
調用 getInterceptors 方法對非 MethodInterceptor 類型的通知進行轉換
返回攔截器數組，並在隨後存入緩存中

這裏須要說明一下，部分通知器是沒有實現 MethodInterceptor 接口的，好比 AspectJMethodBeforeAdvice。咱們能夠看一下前置通知適配器是如何將前置通知轉爲攔截器的，以下：

class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {

    @Override
    public boolean supportsAdvice(Advice advice) {
        return (advice instanceof MethodBeforeAdvice);
    }

    @Override
    public MethodInterceptor getInterceptor(Advisor advisor) {
        MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
        // 建立 MethodBeforeAdviceInterceptor 攔截器
        return new MethodBeforeAdviceInterceptor(advice);
    }
}

如上，適配器的邏輯比較簡單，這裏就很少說了。

如今咱們已經得到了攔截器鏈，那接下來要作的事情就是啓動攔截器了。因此接下來，咱們一塊兒去看看 Sring 是如何讓攔截器鏈運行起來的。

3.3 啓動攔截器鏈

3.3.1 執行攔截器鏈

本節的開始，咱們先來講說 ReflectiveMethodInvocation。ReflectiveMethodInvocation 貫穿於攔截器鏈執行的始終，能夠說是核心。該類的 proceed 方法用於啓動啓動攔截器鏈，下面咱們去看看這個方法的邏輯。

public class ReflectiveMethodInvocation implements ProxyMethodInvocation {

    private int currentInterceptorIndex = -1;

    public Object proceed() throws Throwable {
        // 攔截器鏈中的最後一個攔截器執行完後，便可執行目標方法
        if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
            // 執行目標方法
            return invokeJoinpoint();
        }

        Object interceptorOrInterceptionAdvice =
                this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
        if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {
            InterceptorAndDynamicMethodMatcher dm =
                    (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
            /*
             * 調用具備三個參數（3-args）的 matches 方法動態匹配目標方法，
             * 兩個參數（2-args）的 matches 方法用於靜態匹配
             */
            if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {
                // 調用攔截器邏輯
                return dm.interceptor.invoke(this);
            }
            else {
                // 若是匹配失敗，則忽略當前的攔截器
                return proceed();
            }
        }
        else {
            // 調用攔截器邏輯，並傳遞 ReflectiveMethodInvocation 對象
            return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
        }
    }
}

如上，proceed 根據 currentInterceptorIndex 來肯定當前應執行哪一個攔截器，並在調用攔截器的 invoke 方法時，將本身做爲參數傳給該方法。前面的章節中，咱們看過了前置攔截器的源碼，這裏來看一下後置攔截器源碼。以下：

public class AspectJAfterAdvice extends AbstractAspectJAdvice
        implements MethodInterceptor, AfterAdvice, Serializable {

    public AspectJAfterAdvice(
            Method aspectJBeforeAdviceMethod, AspectJExpressionPointcut pointcut, AspectInstanceFactory aif) {

        super(aspectJBeforeAdviceMethod, pointcut, aif);
    }


    @Override
    public Object invoke(MethodInvocation mi) throws Throwable {
        try {
            // 調用 proceed
            return mi.proceed();
        }
        finally {
            // 調用後置通知邏輯
            invokeAdviceMethod(getJoinPointMatch(), null, null);
        }
    }

    //...
}

如上，因爲後置通知須要在目標方法返回後執行，因此 AspectJAfterAdvice 先調用 mi.proceed() 執行下一個攔截器邏輯，等下一個攔截器返回後，再執行後置通知邏輯。若是你們不太理解的話，先看個圖。這裏假設目標方法 method 在執行前，須要執行兩個前置通知和一個後置通知。下面咱們看一下由三個攔截器組成的攔截器鏈是如何執行的，以下：

注：這裏用 advice.after() 表示執行後置通知

本節的最後，插播一個攔截器，即 ExposeInvocationInterceptor。爲啥要在這裏介紹這個攔截器呢，緣由是我在Spring AOP 源碼分析 - 篩選合適的通知器一文中，在介紹 extendAdvisors 方法時，有一個點沒有詳細說明。如今你們已經知道攔截器的概念了，就能夠把以前無法詳細說明的地方進行補充說明。這裏再貼一下 extendAdvisors 方法的源碼，以下：

protected void extendAdvisors(List<Advisor> candidateAdvisors) {
    AspectJProxyUtils.makeAdvisorChainAspectJCapableIfNecessary(candidateAdvisors);
}

public static boolean makeAdvisorChainAspectJCapableIfNecessary(List<Advisor> advisors) {
    if (!advisors.isEmpty()) {
        // 省略部分代碼

        if (foundAspectJAdvice && !advisors.contains(ExposeInvocationInterceptor.ADVISOR)) {
            // 向通知器列表中添加 ExposeInvocationInterceptor.ADVISOR
            advisors.add(0, ExposeInvocationInterceptor.ADVISOR);
            return true;
        }
    }
    return false;
}

如上，extendAdvisors 所調用的方法會向通知器列表首部添加 ExposeInvocationInterceptor.ADVISOR。如今咱們再來看看 ExposeInvocationInterceptor 的源碼，以下：

public class ExposeInvocationInterceptor implements MethodInterceptor, PriorityOrdered, Serializable {

    public static final ExposeInvocationInterceptor INSTANCE = new ExposeInvocationInterceptor();

    // 建立 DefaultPointcutAdvisor 匿名對象
    public static final Advisor ADVISOR = new DefaultPointcutAdvisor(INSTANCE) {
        @Override
        public String toString() {
            return ExposeInvocationInterceptor.class.getName() +".ADVISOR";
        }
    };

    private static final ThreadLocal<MethodInvocation> invocation =
            new NamedThreadLocal<MethodInvocation>("Current AOP method invocation");

    public static MethodInvocation currentInvocation() throws IllegalStateException {
        MethodInvocation mi = invocation.get();
        if (mi == null)
            throw new IllegalStateException(
                    "No MethodInvocation found: Check that an AOP invocation is in progress, and that the " +
                    "ExposeInvocationInterceptor is upfront in the interceptor chain. Specifically, note that " +
                    "advices with order HIGHEST_PRECEDENCE will execute before ExposeInvocationInterceptor!");
        return mi;
    }

    // 私有構造方法
    private ExposeInvocationInterceptor() {
    }

    @Override
    public Object invoke(MethodInvocation mi) throws Throwable {
        MethodInvocation oldInvocation = invocation.get();
        // 將 mi 設置到 ThreadLocal 中
        invocation.set(mi);
        try {
            // 調用下一個攔截器
            return mi.proceed();
        }
        finally {
            invocation.set(oldInvocation);
        }
    }

    //...
}

如上，ExposeInvocationInterceptor.ADVISOR 通過 registry.getInterceptors 方法（前面已分析過）處理後，便可獲得 ExposeInvocationInterceptor。ExposeInvocationInterceptor 的做用是用於暴露 MethodInvocation 對象到 ThreadLocal 中，其名字也體現出了這一點。若是其餘地方須要當前的 MethodInvocation 對象，直接經過調用 currentInvocation 方法取出。至於哪些地方須要 MethodInvocation，這個你們本身去探索吧。最後，建議你們寫點代碼調試一下。我在一開始閱讀代碼時，並無注意到 ExposeInvocationInterceptor，而是在調試代碼的過程當中才發現的。好比：

好了，關於攔截器鏈的執行過程這裏就講完了。下一節，咱們來看一下目標方法的執行過程。你們再忍忍，源碼很快分析完了。

3.3.2 執行目標方法

與前面的大部頭相比，本節的源碼比較短，也很簡單。本節咱們來看一下目標方法的執行過程，以下：

protected Object invokeJoinpoint() throws Throwable {
    return AopUtils.invokeJoinpointUsingReflection(this.target, this.method, this.arguments);
}

public abstract class AopUtils {
    public static Object invokeJoinpointUsingReflection(Object target, Method method, Object[] args)
            throws Throwable {

        try {
            ReflectionUtils.makeAccessible(method);
            // 經過反射執行目標方法
            return method.invoke(target, args);
        }
        catch (InvocationTargetException ex) {...}
        catch (IllegalArgumentException ex) {...}
        catch (IllegalAccessException ex) {...}
    }
}

目標方法時經過反射執行的，比較簡單的吧。好了，就很少說了，over。

4.總結

到此，本篇文章的就要結束了。本篇文章是Spring AOP 源碼分析系列文章的最後一篇，從閱讀源碼到寫完本系列的4篇文章總共花了約兩週的時間。總的來講仍是有點累的，可是也有很大的收穫和成就感，值了。須要說明的是，Spring IOC 和 AOP 部分的源碼我分析的並非很是詳細，也有不少地方沒弄懂。這一系列的文章，是做爲本身工做兩年的一個總結。因爲工做時間不長，工做經驗和技術水平目前都還處於入門階段。因此暫時很難把 Spring IOC 和 AOP 模塊的源碼分析的很出彩，這個請見諒。若是你們在閱讀文章的過程當中發現了錯誤，能夠指出來，也但願多多指教，這裏先說說謝謝。

好了，本篇文章到這裏就結束了。謝謝你們的閱讀。

參考

《Spring 源碼深度解析》- 郝佳

附錄：Spring 源碼分析文章列表

Ⅰ. IOC

更新時間	標題
2018-05-30	Spring IOC 容器源碼分析系列文章導讀
2018-06-01	Spring IOC 容器源碼分析 - 獲取單例 bean
2018-06-04	Spring IOC 容器源碼分析 - 建立單例 bean 的過程
2018-06-06	Spring IOC 容器源碼分析 - 建立原始 bean 對象
2018-06-08	Spring IOC 容器源碼分析 - 循環依賴的解決辦法
2018-06-11	Spring IOC 容器源碼分析 - 填充屬性到 bean 原始對象
2018-06-11	Spring IOC 容器源碼分析 - 餘下的初始化工做

Ⅱ. AOP

更新時間	標題
2018-06-17	Spring AOP 源碼分析系列文章導讀
2018-06-20	Spring AOP 源碼分析 - 篩選合適的通知器
2018-06-20	Spring AOP 源碼分析 - 建立代理對象
2018-06-22	Spring AOP 源碼分析 - 攔截器鏈的執行過程