Spring基礎系列-AOP織入邏輯跟蹤

AOP Spring · 發表 2019-02-17 22:15:12

摘要：原創文章，轉載請標註出處：《Spring基礎系列-AOP織入邏輯跟蹤》其實在之前的原始碼解讀裡面，關於織入的部分並沒有說清楚，那些前置、後置、環繞、異常等通知是如何圍繞在目標方法周圍執行的呢？這裡面最重要的就是遞迴，Spring在實現這塊邏輯的時候使用的大量的遞迴呼叫，完美的...

原創文章，轉載請標註出處：《Spring基礎系列-AOP織入邏輯跟蹤》

其實在之前的原始碼解讀裡面，關於織入的部分並沒有說清楚，那些前置、後置、環繞、異常等通知是如何圍繞在目標方法周圍執行的呢？

這裡面最重要的就是遞迴，Spring在實現這塊邏輯的時候使用的大量的遞迴呼叫，完美的實現的織入的邏輯。

我們不凡就以 Spring基礎系列--AOP實踐中的例子來進行一番邏輯追蹤，來一探究竟。

我們就從測試類開始：

首先我們通過 CglibAopProxy 類的 intercept 方法構建一個方法呼叫，並執行其 proceed

方法：

然後進入 ReflectiveMethodInvocation 類的 proceed() 方法，由於 currentInterceptorIndex 下標從-1開始，在進行++自增操作之後變成0，獲取 interceptorsAndDynamicMethodMatchers 中的第一個攔截器。

我們看下 interceptorsAndDynamicMethodMatchers 中的內容：

第一個是 ExposeInvocationInterceptor ，這個正是之前在 Spring基礎系列-AOP原始碼分析中原始碼11裡提到的，獲取通知鏈的時候會將其放到通知鏈首位，用於暴露方法呼叫到 ThreadLocal 中。

由於其為一個簡單的攔截器，上面的判斷是不成立的，所以直接執行最後一行：

然後進入到 ExposeInvocationInterceptor 方法的 invoke 方法中:

在這個方法中我們可以看到，90行處，將方法呼叫mi放到了invocation中。那invocation是什麼呢？如下：

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

可見，是將方法呼叫儲存到了ThreadLocal中，這個invocation儲存的正是當前AOP的方法呼叫。

然後執行 mi.proceed() 方法，這就是一個遞迴呼叫了。在這裡執行 proceed 方法，將會繼續執行下一個通知，執行邏輯又回到 ReflectiveMethodInvocation 類的 proceed() 方法，這時 currentInterceptorIndex 自增之後為1，正好指向 interceptorsAndDynamicMethodMatchers 中的下一個通知：

很顯然，下一個通知為後置異常通知afterThrowingTest。

執行這個通知的invoke方法，程式碼調到 AspectJAfterThrowingAdvice 類的 invoke 方法。

在異常通知的invoke方法中直接遞迴呼叫proceed方法，並將剩下所有的呼叫執行全部try...catch住，在最後catch塊中執行其通知邏輯。

除開普通的攔截器之外，最先執行的通知是異常通知，它會將剩下所有的呼叫邏輯全部catch住，也就是說在這期間發生的任何異常都會被捕捉到，而且一旦哪一步發生了異常，那麼執行就會被中斷，到這裡執行catch邏輯。

這下又回到了 ReflectiveMethodInvocation 類的 proceed 方法。 currentInterceptorIndex 再次自增為2，指向通知鏈中第三個通知：

後置返回通知，遵從以上的邏輯我們看看下一步的行為：

在 AfterReturningAdviceInterceptor 類中

果然去執行後置返回通知的invoke方法去啦，第一步任然是遞迴呼叫，又回到了 ReflectiveMethodInvocation 類的 proceed 方法去執行第四個通知：

這個是後置終點通知，這個通知有點特殊哦，我們來看看其invoke方法

它也是先直接進行遞迴呼叫，將其邏輯放在最後，這個是真正的最後，直接放到了finally塊中，這表示什麼，這表示，無論接下來的呼叫操作是否會發生異常，這部分邏輯永遠會執行。

現在又一次回去了 ReflectiveMethodInvocation 類的 proceed 方法去執行第五個通知：

嗯，這次是環繞通知，這個通知不同於其他通知，其他通知只執行於方法的一點，這個通知卻需要執行於方法的兩處。所以它會擁有一個ProceedJoinPoint引數，這個引數就是用來區分這兩處執行邏輯的：目標方法之前與之後。

直接執行到最後一句，首次要執行invokeAdviceMethod方法了：

然後執行invokeAdviceMethodWithGivenArgs方法：

它要直接執行通知方法中的邏輯，想想為什麼沒有在進行遞迴呼叫而是直接執行的通知方法呢？

因為環繞通知將遞迴呼叫挪移到了通知邏輯中，由程式設計師自定義執行，來看看我自定義的環繞通知邏輯：

我們先不考慮具體的邏輯，先看看大體結構，顯示一段邏輯，然後執行jp.proceed(os)方法。然後又是一段邏輯。所謂的環繞就是將邏輯圍繞在目標執行前後。

通知的內容真正開始執行了，這裡首先執行了環繞通知的前置部分。

我們執行遞迴呼叫之後，我們發現邏輯跑到了MethodInvocationProceedingJoinPoint中，這是啥類呢？

這竟然是ProceedJoinPoint的實現類，我們執行jp.proceed(os)方法當然會跑到這裡了。

其實ProceedJoinPoint的proceed方法有兩個過載，一個有引數，一個無引數，分別用於針對目標方法有引數和目標發無引數的情況，所以這裡這兩個方法其實邏輯類似，只是有引數的方法會針對引數進行一番操作，將引數設定到方法呼叫中，這麼做，新的方法引數會替換就的方法引數，這也是我們可以在環繞通知中修改引數的原理所在。