在正常的業務流程中，往往存在著一些業務邏輯，例如安全審計、日誌管理，它們存在於每一個業務中，然而卻和實際的業務邏輯沒有太強的關聯關係。

　　　　　　　　　　　　　　　　　　　圖1

　　這些邏輯我們稱為橫切邏輯。如果把橫切的邏輯代碼寫在業務代碼中，散落在各個地方，則會變得非常難以維護，代碼也會顯得過於臃腫。

　　Spring AOP為處理這些問題提供了一種很好的方法。

1 AOP術語

　　1 通知（advice）。通知是指真正執行的目標邏輯。例如為系統記日誌，那麼通知做的事情，就是記錄日誌。

　　2 連接點(joinpoit)。連接點指何時執行advice的代碼。系統中如果想要為所有的start()方法執行之前，記錄一條"our system is starting"的日誌，那麼，start（）方法被調用的時機，稱為一個連接點。

　　3 切點(pointcut)。切點指何處執行advice的代碼。例如指定特定的一個路徑下的start()方法被調用時，執行advice的代碼，那麼，這個特定的路徑可以理解為切點。通常我們使用正則表達式定義匹配的類和方法來確定切點。

　　4 切麵(aspect)。 切麵是通知、切點和連接點的全部內容。它定義了何時在何處，完成什麼功能。

　　5 織入(weaving)。織入指實際代碼執行到切點時，完成對目標對象代理的過程。織入有如下三種方式：

　　　　a.編譯器織入。需要特殊編譯器支持，例如AspectJ的織入編譯器，在編譯期間將代碼織入。

　　　　b.類載入時。目標類在載入JVM時將切麵引入。需要特殊的classLoader支持，改變目標類的位元組碼，增加新的動作。

　　　　c.運行期。在運行期運用動態代理技術，代理目標類。Spring AOP就是使用這種方式。

2 Spring對AOP的支持

　　Spring對AOP提供了多種支持，大體上分為2種思路。

　　1 使用動態代理，在運行期對目標類生成代理對象。代理類封裝了目標類，並攔截被通知的方法的調用，再將調用轉發給真正的目標類方法調用。在代理類中，可以執行切麵邏輯。基於這種模式，僅限於對方法的攔截。如果想要實現更細粒度的攔截，例如特定的欄位的修改，則需要使用第2種思路了。

　　2 使用AspectJ特有的AOP語言。這種方式的成本在於，需要學習AspectJ的語法。

　　大多數情況下，第一種思路已經可以滿足我們的需求。

3 Demo

　　我們可以使用execution指示器來指示切點。如圖2

　　　　　　　　　         　圖2

　　execution指示器具體指定了哪個包下麵哪個類執行什麼方法時，會被織入橫切邏輯。Spring AOP的demo網上有很多，但是原理其實都一樣。這裡貼出其中一種。

　　我們需要2個類，一個類(Biz)用作正常的業務邏輯，一個類用作橫切(AdviceTest)。同時寫一個類Main測試

　　1.Biz

1 public class Biz {
2     public void doBiz(){
3         System.out.println("doing biz");
4     }
5 }

　　2.AdviceTest

 1 public class AdviceTest implements Advice, MethodInterceptor {
 2 
 3     @Override
 4     public Object invoke(MethodInvocation invocation) throws Throwable {
 5         advice();
 6         invocation.proceed();
 7         return null;
 8     }
 9 
10     public void advice(){
11         System.out.println("this is a advice");
12     }
13 
14 }

　　3.Main

1 public class Main {
2     public static void main(String[] args) {
3         ApplicationContext applicationContext = new ClassPathXmlApplicationContext(new String[]{"config/spring/spring-aop.xml"});
4         Biz biz = (Biz)applicationContext.getBean("biz");
5         biz.doBiz();
6     }
7 }

　　4.Spring配置

 1 <?xml version="1.0" encoding="UTF-8" ?>
 2 <beans
 3         xmlns="http://www.springframework.org/schema/beans"
 4         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 5         xmlns:aop="http://www.springframework.org/schema/aop"
 6         xsi:schemaLocation="
 7             http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
 8             http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
 9             ">
10 
11     <bean id="adviceTest" class="aop.AdviceTest"/>
12     
13     <bean id="biz" class="aop.Biz"/>
14     
15     <aop:config>
16         <aop:pointcut id="bizPointCut" expression="execution(* aop.Biz.*(..))"/>
17         <aop:advisor pointcut-ref="bizPointCut" advice-ref="adviceTest"/>
18     </aop:config>
19 
20 </beans>

　　執行Main函數代碼，輸出如下　

this is a advice
doing biz

　　可見，實際的biz邏輯已經經過增強。

4 源碼分析

　　Spring提供了兩種方式來生成代理對象: JDKProxy和Cglib，具體使用哪種方式生成由AopProxyFactory根據AdvisedSupport對象的配置來決定。預設的策略是如果目標類是介面，則使用JDK動態代理技術，否則使用Cglib來生成代理。在我們的例子中，顯然使用的是Cglib。如圖3

　　　　　　　　　　　　               圖3

　　為什麼我們配置了Biz的bean，得到的卻不是Biz的實例呢?這和Spring對xml文件的標簽解析策略有關。對於AOP相關的bean的解析，在AopNamespaceHandler類裡面有相關代碼，感興趣的同學可以去研究下。

　　我們繼續往下麵單步調試，發現進入了CglibAopProxy類裡面。

 1 public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
 2             Object oldProxy = null;
 3             boolean setProxyContext = false;
 4             Class<?> targetClass = null;
 5             Object target = null;
 6             try {
 7                 if (this.advised.exposeProxy) {
 8                     // Make invocation available if necessary.
 9                     oldProxy = AopContext.setCurrentProxy(proxy);
10                     setProxyContext = true;
11                 }
12                 // May be null. Get as late as possible to minimize the time we
13                 // "own" the target, in case it comes from a pool...
14                 target = getTarget();
15                 if (target != null) {
16                     targetClass = target.getClass();
17                 }
18                 List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
19                 Object retVal;
20                 // Check whether we only have one InvokerInterceptor: that is,
21                 // no real advice, but just reflective invocation of the target.
22                 if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) {
23                     // We can skip creating a MethodInvocation: just invoke the target directly.
24                     // Note that the final invoker must be an InvokerInterceptor, so we know
25                     // it does nothing but a reflective operation on the target, and no hot
26                     // swapping or fancy proxying.
27                     Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
28                     retVal = methodProxy.invoke(target, argsToUse);
29                 }
30                 else {
31                     // We need to create a method invocation...
32                     retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();
33                 }
34                 retVal = processReturnType(proxy, target, method, retVal);
35                 return retVal;
36             }
37             finally {
38                 if (target != null) {
39                     releaseTarget(target);
40                 }
41                 if (setProxyContext) {
42                     // Restore old proxy.
43                     AopContext.setCurrentProxy(oldProxy);
44                 }
45             }
46         }

　　無恥的把代碼直接貼出來。我們重點關註下下麵這一行

　  retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed(); 

　　在本文例子的場景下，會在此創建一個CglibMethodInvocation執行上下文，並執行proceed()方法。

　　　　　　　　　　　　　　　　　　　　　　　　　圖4

最終執行AdviceTest中invoke()方法的調用。在AdviceTest的invoke方法中，我們可以自定義自己想要執行的增強邏輯invocation.proceed()來執行目標類的方法。

　　　　　　　　　　　　　　　　　　　　　　　圖5

5 總結

　　Spring AOP為許多與業務無關的邏輯的執行，提供了一種很好的解決思路。本文也只是拋磚引玉，在實際的Spring源碼中，還是比較複雜的，還需要細細研究才行。

參考文獻：

　《Spring In Action》

　《Spring源碼深度解析》