Spring AOP 實現原理與CGLIB應用

　　

　　簡介 AOP（Aspect Orient Programming）也就是面向方面編程作為面向對象編程的一種補充專門用於處理系統中分布於各個模塊（不同方法）中的交叉關注點的問題在 Java EE 應用中常常通過 AOP 來處理一些具有橫切性質的系統級服務如事務管理安全檢查緩存對象池管理等AOP 實現的關鍵就在於 AOP 框架自動創建的 AOP 代理AOP 代理主要分為靜態代理和動態代理兩大類靜態代理以 AspectJ 為代表而動態代理則以 Spring AOP 為代表本文會從 AspectJ 分析起逐漸深入並介紹 CGLIB 來介紹 Spring AOP 框架的實現原理

　　AOP（Aspect Orient Programming）作為面向對象編程的一種補充廣泛應用於處理一些具有橫切性質的系統級服務如事務管理安全檢查緩存對象池管理等 AOP 實現的關鍵就在於 AOP 框架自動創建的 AOP 代理AOP 代理則可分為靜態代理和動態代理兩大類其中靜態代理是指使用 AOP 框架提供的命令進行編譯從而在編譯階段就可生成 AOP 代理類因此也稱為編譯時增強而動態代理則在運行時借助於 JDK 動態代理CGLIB 等在內存中臨時生成 AOP 動態代理類因此也被稱為運行時增強

　　

　　AOP 的存在價值

　　在傳統 OOP 編程裡以對象為核心整個軟件系統由系列相互依賴的對象所組成而這些對象將被抽象成一個一個的類並允許使用類繼承來管理類與類之間一般到特殊的關系隨著軟件規模的增大應用的逐漸升級慢慢出現了一些 OOP 很難解決的問題

　　我們可以通過分析抽象出一系列具有一定屬性與行為的對象並通過這些對象之間的協作來形成一個完整的軟件功能由於對象可以繼承因此我們可以把具有相同功能或相同特性的屬性抽象到一個層次分明的類結構體系中隨著軟件規范的不斷擴大專業化分工越來越系列以及 OOP 應用實踐的不斷增多隨之也暴露出了一些 OOP 無法很好解決的問題

　　現在假設系統中有 段完全相似的代碼這些代碼通常會采用復制粘貼方式來完成通過這種復制粘貼方式開發出來的軟件如圖 所示

　　圖 多個地方包含相同代碼的軟件

　　

　　看到如圖 所示的示意圖可能有的讀者已經發現了這種做法的不足之處如果有一天圖 中的深色代碼段需要修改那是不是要打開 個地方的代碼進行修改？如果不是 個地方包含這段代碼而是 個地方甚至是 個地方包含這段代碼段那會是什麼後果？

　　為了解決這個問題我們通常會采用將如圖 所示的深色代碼部分定義成一個方法然後在 個代碼段中分別調用該方法即可在這種方式下軟件系統的結構如圖 所示

　　圖 通過方法調用實現系統功能

　　

　　對於如圖 所示的軟件系統如果需要修改深色部分的代碼只要修改一個地方即可不管整個系統中有多少地方調用了該方法程序無須修改這些地方只需修改被調用的方法即可通過這種方式大大降低了軟件後期維護的復雜度

　　對於如圖 所示的方法 方法 方法 依然需要顯式調用深色方法這樣做能夠解決大部分應用場景但對於一些更特殊的情況應用需要方法 方法 方法 徹底與深色方法分離方法 方法 方法 無須直接調用深色方法那如何解決？

    因為軟件系統需求變更是很頻繁的事情系統前期設計方法 方法 方法 時只實現了核心業務功能過了一段時間我們需要為方法 方法 方法 都增加事務控制又過了一段時間客戶提出方法 方法 方法 需要進行用戶合法性驗證只有合法的用戶才能執行這些方法又過了一段時間客戶又提出方法 方法 方法 應該增加日志記錄又過了一段時間客戶又提出……面對這樣的情況我們怎麼辦？通常有兩種做法

　　根據需求說明書直接拒絕客戶要求擁抱需求滿足客戶的需求

　　第一種做法顯然不好客戶是上帝我們應該盡量滿足客戶的需求通常會采用第二種做法那如何解決呢？是不是每次先定義一個新方法然後修改方法 方法 方法 增加調用新方法？這樣做的工作量也不小啊！我們希望有一種特殊的方法我們只要定義該方法無須在方法 方法 方法 中顯式調用它系統會自動執行該特殊方法

　　上面想法聽起來很神奇甚至有一些不切實際但其實是完全可以實現的實現這個需求的技術就是 AOPAOP 專門用於處理系統中分布於各個模塊（不同方法）中的交叉關注點的問題在 Java EE 應用中常常通過 AOP 來處理一些具有橫切性質的系統級服務如事務管理安全檢查緩存對象池管理等AOP 已經成為一種非常常用的解決方案

　　使用 AspectJ 的編譯時增強進行 AOP

　　AspectJ 是一個基於 Java 語言的 AOP 框架提供了強大的 AOP 功能其他很多 AOP 框架都借鑒或采納其中的一些思想

　　AspectJ 是 Java 語言的一個 AOP 實現其主要包括兩個部分第一個部分定義了如何表達定義 AOP 編程中的語法規范通過這套語言規范我們可以方便地用 AOP 來解決 Java 語言中存在的交叉關注點問題另一個部分是工具部分包括編譯器調試工具等

　　AspectJ 是最早功能比較強大的 AOP 實現之一對整套 AOP 機制都有較好的實現很多其他語言的 AOP 實現也借鑒或采納了 AspectJ 中很多設計在 Java 領域AspectJ 中的很多語法結構基本上已成為 AOP 領域的標准

　　下載安裝 AspectJ 比較簡單讀者登錄 AspectJ 官網（）即可下載到一個可執行的 JAR 包使用 java jar aspectjxxjar 命令多次單擊Next按鈕即可成功安裝 AspectJ

　　成功安裝了 AspectJ 之後將會在 E:\Java\AOP\aspectj 路徑下（AspectJ 的安裝路徑）看到如下文件結構

　　bin:該路徑下存放了 ajajajcajdocajbrowser 等命令其中 ajc 命令最常用它的作用類似於 javac用於對普通 Java 類進行編譯時增強

　　docs:該路徑下存放了 AspectJ 的使用說明參考手冊API 文檔等文檔

　　lib:該路徑下的 個 JAR 文件是 AspectJ 的核心類庫

　　相關授權文件

　　一些文檔AspectJ 入門書籍一談到使用 AspectJ就認為必須使用 Eclipse 工具似乎離開了該工具就無法使用 AspectJ 了

　　雖然 AspectJ 是 Eclipse 基金組織的開源項目而且提供了 Eclipse 的 AJDT 插件（AspectJ Development Tools）來開發 AspectJ 應用但 AspectJ 絕對無須依賴於 Eclipse 工具

　　實際上AspectJ 的用法非常簡單就像我們使用 JDK 編譯運行 Java 程序一樣下面通過一個簡單的程序來示范 AspectJ 的用法並分析 AspectJ 如何在編譯時進行增強

　　首先編寫一個簡單的 Java 類這個 Java 類用於模擬一個業務組件

　　清單 Hellojava

　　public class Hello   
    {   
    // 定義一個簡單方法模擬應用中的業務邏輯方法  
    public void sayHello()  
      {  
      Systemoutprintln(Hello AspectJ!);  
      }  
    // 主方法程序的入口  
    public static void main(String[] args)   
    {   
    Hello h = new Hello();   
    hsayHello();   
    }   
    } 

　　上面 Hello 類模擬了一個業務邏輯組件編譯運行該 Java 程序這個結果是沒有任何懸念的程序將在控制台打印Hello AspectJ字符串

　　假設現在客戶需要在執行 sayHello() 方法之前啟動事務當該方法執行結束時關閉事務在傳統編程模式下我們必須手動修改 sayHello() 方法——如果改為使用 AspectJ則可以無須修改上面的 sayHello() 方法

　　下面我們定義一個特殊的 Java 類

　　清單 TxAspectjava

　　public aspect TxAspect   
    {   
    // 指定執行 HellosayHello() 方法時執行下面代碼塊  
    void around():call(void HellosayHello())  
    {  
    Systemoutprintln(開始事務 );  
    proceed();  
    Systemoutprintln(事務結束 );  
    }  
    } 

　　可能讀者已經發現了上面類文件中不是使用 classinterfaceenum 在定義 Java 類而是使用了 aspect ——難道 Java 語言又新增了關鍵字？沒有！上面的 TxAspect 根本不是一個 Java 類所以 aspect 也不是 Java 支持的關鍵字它只是 AspectJ 才能識別的關鍵字

　　上面粗體字代碼也不是方法它只是指定當程序執行 Hello 對象的 sayHello() 方法時系統將改為執行粗體字代碼的花括號代碼塊其中 proceed() 代表回調原來的 sayHello() 方法

　　正如前面提到的Java 無法識別 TxAspectjava 文件的內容所以我們要使用 ajcexe 命令來編譯上面的 Java 程序為了能在命令行使用 ajcexe 命令需要把 AspectJ 安裝目錄下的 bin 路徑（比如 E:\Java\AOP\aspectj\bin 目錄）添加到系統的 PATH 環境變量中接下來執行如下命令進行編譯

　　

　　ajc d Hellojava TxAspectjava

　　我們可以把 ajcexe 理解成 javacexe 命令都用於編譯 Java 程序區別是 ajcexe 命令可識別 AspectJ 的語法從這個意義上看我們可以將 ajcexe 當成一個增強版的 javacexe 命令

　　運行該 Hello 類依然無須任何改變因為 Hello 類位於 lee 包下程序使用如下命令運行 Hello 類java leeHello

　　運行該程序將看到一個令人驚喜的結果

　　開始事務 …

　　Hello AspectJ!

　　事務結束 …

　　從上面運行結果來看我們完全可以不對 Hellojava 類進行任何修改同時又可以滿足客戶的需求上面程序只是在控制台打印開始事務 …結束事務 …來模擬了事務操作實際上我們可用實際的事務操作代碼來代替這兩行簡單的語句這就可以滿足客戶需求了

　　如果客戶再次提出新需求需要在 sayHello() 方法後增加記錄日志的功能那也很簡單我們再定義一個 LogAspect程序如下

　　清單 LogAspectjava

　　public aspect LogAspect  
    {  
    // 定義一個 PointCut其名為 logPointcut  
    // 該 PointCut 對應於指定 Hello 對象的 sayHello 方法  
        pointcut logPointcut() :execution(void HellosayHello());  
    // 在 logPointcut 之後執行下面代碼塊  
        after():logPointcut()  
        {  
    Systemoutprintln(記錄日志 );  
        }  
    } 

　　上面程序的粗體字代碼定義了一個 PointcutlogPointcut – 等同於執行 Hello 對象的 sayHello() 方法並指定在 logPointcut 之後執行簡單的代碼塊也就是說在 sayHello() 方法之後執行指定代碼塊使用如下命令來編譯上面的 Java 程序ajc d *java

　　再次運行 Hello 類將看到如下運行結果

　　

　　開始事務 …

　　Hello AspectJ!

　　記錄日志 …

　　事務結束 …

　　從上面運行結果來看通過使用 AspectJ 提供的 AOP 支持我們可以為 sayHello() 方法不斷增加新功能

　　為什麼在對 Hello 類沒有任何修改的前提下而 Hello 類能不斷地動態增加新功能呢？這看上去並不符合 Java 基本語法規則啊實際上我們可以使用 Java 的反編譯工具來反編譯前面程序生成的 Helloclass 文件發現 Helloclass 文件的代碼如下

　　清單 Helloclass

　　package lee;   
    import javaioPrintStream;   
    import orgaspectjruntimeinternalAroundClosure;   
      
    public class Hello   
    {   
     public void sayHello()   
     {   
       try 
       {   
         Systemoutprintln(Hello AspectJ!); } catch (Throwable localThrowable) {   
         LogAspectaspectOf()ajc$after$lee_LogAspect$$fddd(); throw localThrowable; }   
         LogAspectaspectOf()ajc$after$lee_LogAspect$$fddd();   
     }   
        
     private static final void sayHello_aroundBody$advice(Hello target   
                TxAspect ajc$aspectInstance AroundClosure ajc$aroundClosure)   
     {   
       Systemoutprintln(開始事務 );   
       AroundClosure localAroundClosure = ajc$aroundClosure; sayHello_aroundBody(target);   
       Systemoutprintln(事務結束 );   
     }   
    } 

　　不難發現這個 Helloclass 文件不是由原來的 Hellojava 文件編譯得到的該 Helloclass 裡新增了很多內容——這表明 AspectJ 在編譯時自動編譯得到了一個新類這個新類增強了原有的 Hellojava 類的功能因此 AspectJ 通常被稱為編譯時增強的 AOP 框架

　　提示與 AspectJ 相對的還有另外一種 AOP 框架它們不需要在編譯時對目標類進行增強而是運行時生成目標類的代理類該代理類要麼與目標類實現相同的接口要麼是目標類的子類——總之代理類的實例可作為目標類的實例來使用一般來說編譯時增強的 AOP 框架在性能上更有優勢——因為運行時動態增強的 AOP 框架需要每次運行時都進行動態增強

　　實際上AspectJ 允許同時為多個方法添加新功能只要我們定義 Pointcut 時指定匹配更多的方法即可如下片段

　　pointcut xxxPointcut()   
        :execution(void H*say*()); 

　　上面程序中的 xxxPointcut 將可以匹配所有以 H 開頭的類中所有以 say 開頭的方法但該方法返回的必須是 void如果不想匹配任意的返回值類型則可將代碼改為如下形式

　　pointcut xxxPointcut()  
   :execution(* H*say*());xxxPointcut() 

　　關於如何定義 AspectJ 中的 AspectPointcut 等讀者可以參考 AspectJ 安裝路徑下的 doc 目錄裡的 quickpdf 文件

　　使用 Spring AOP

　　與 AspectJ 相同的是Spring AOP 同樣需要對目標類進行增強也就是生成新的 AOP 代理類與 AspectJ 不同的是Spring AOP 無需使用任何特殊命令對 Java 源代碼進行編譯它采用運行時動態地在內存中臨時生成代理類的方式來生成 AOP 代理

　　Spring 允許使用 AspectJ Annotation 用於定義方面（Aspect）切入點（Pointcut）和增強處理（Advice）Spring 框架則可識別並根據這些 Annotation 來生成 AOP 代理Spring 只是使用了和 AspectJ 一樣的注解但並沒有使用 AspectJ 的編譯器或者織入器（Weaver）底層依然使用的是 Spring AOP依然是在運行時動態生成 AOP 代理並不依賴於 AspectJ 的編譯器或者織入器

　　簡單地說Spring 依然采用運行時生成動態代理的方式來增強目標對象所以它不需要增加額外的編譯也不需要 AspectJ 的織入器支持而 AspectJ 在采用編譯時增強所以 AspectJ 需要使用自己的編譯器來編譯 Java 文件還需要織入器

　　為了啟用 Spring 對 @AspectJ 方面配置的支持並保證 Spring 容器中的目標 Bean 被一個或多個方面自動增強必須在 Spring 配置文件中配置如下片段

　　    "" 
    xmlns:xsi="-instance" 
    xmlns:aop="" 
   xsi:schemaLocation=";  
   -beans-3.0.xsd  
     
   -aop-3.0.xsd">  
      
       
     

　　當然，如果我們希望完全啟動 Spring 的“零配置”功能，則還需要啟用 Spring 的“零配置”支持，讓 Spring 自動搜索指定路徑下 Bean 類。Tw.wiNGWit.Com

　　所謂自動增強，指的是 Spring 會判斷一個或多個方面是否需要對指定 Bean 進行增強，並據此自動生成相應的代理，從而使得增強處理在合適的時候被調用。

　　如果不打算使用 Spring 的 XML Schema 配置方式，則應該在 Spring 配置文件中增加如下片段來啟用 @AspectJ 支持。

　　上面配置文件中的 AnnotationAwareAspectJAutoProxyCreator 是一個 Bean 後處理器（BeanPostProcessor），該 Bean 後處理器將會為容器中 Bean 生成 AOP 代理，

　　當啟動了 @AspectJ 支持後，只要我們在 Spring 容器中配置一個帶 @Aspect 注釋的 Bean，Spring 將會自動識別該 Bean，並將該 Bean 作為方面 Bean 處理。

　　在 Spring 容器中配置方面 Bean（即帶 @Aspect 注釋的 Bean），與配置普通 Bean 沒有任何區別，一樣使用 元素進行配置，一樣支持使用依賴注入來配置屬性值；如果我們啟動了 Spring 的“零配置”特性，一樣可以讓 Spring 自動搜索，並裝載指定路徑下的方面 Bean。

　　使用 @Aspect 標注一個 Java 類，該 Java 類將會作為方面 Bean，如下面代碼片段所示：

　　// 使用 @Aspect 定義一個方面類  
    @Aspect 
    public class LogAspect   
    {   
    // 定義該類的其他內容  
    ...   
    } 

　　方面類（用 @Aspect 修飾的類）和其他類一樣可以有方法、屬性定義，還可能包括切入點、增強處理定義。

　　當我們使用 @Aspect 來修飾一個 Java 類之後，Spring 將不會把該 Bean 當成組件 Bean 處理，因此負責自動增強的後處理 Bean 將會略過該 Bean，不會對該 Bean 進行任何增強處理。

　　開發時無須擔心使用 @Aspect 定義的方面類被增強處理，當 Spring 容器檢測到某個 Bean 類使用了 @Aspect 標注之後，Spring 容器不會對該 Bean 類進行增強。

　　下面將會考慮采用 Spring AOP 來改寫前面介紹的例子：

　　下面例子使用一個簡單的 Chinese 類來模擬業務邏輯組件：

　　清單 5.Chinese.java

　　@Component 
    public class Chinese  
    {  
    // 實現 Person 接口的 sayHello() 方法  
        public String sayHello(String name)  
        {  
       System.out.println("-- 正在執行 sayHello 方法 --");  
    // 返回簡單的字符串  
            return name + " Hello , Spring AOP";  
        }  
    // 定義一個 eat() 方法  
        public void eat(String food)  
        {  
       System.out.println("我正在吃 :"+ food);  
        }  
    } 

　　提供了上面 Chinese 類之後，接下來假設同樣需要為上面 Chinese 類的每個方法增加事務控制、日志記錄，此時可以考慮使用 Around、AfterReturning 兩種增強處理。

　　先看 AfterReturning 增強處理代碼。

　　清單 6.AfterReturningAdviceTest.java

　　// 定義一個方面  
    @Aspect 
    public class AfterReturningAdviceTest   
    {   
    // 匹配 org.crazyit.app.service.impl 包下所有類的、  
    // 所有方法的執行作為切入點  
    @AfterReturning(returning="rvt", pointcut="execution(* org.crazyit.app.service.impl.*.*(..))")  
    public void log(Object rvt)   
    {   
    System.out.println("獲取目標方法返回值 :" + rvt);   
    System.out.println("模擬記錄日志功能 ...");   
    }   
    } 

　　上面 Aspect 類使用了 @Aspect 修飾，這樣 Spring 會將它當成一個方面 Bean 進行處理。其中程序中粗體字代碼指定將會在調用 org.crazyit.app.service.impl 包下的所有類的所有方法之後織入 log(Object rvt) 方法。

　　再看 Around 增強處理代碼：

　　清單 7.AfterReturningAdviceTest.java

　　// 定義一個方面  
    @Aspect 
    public class AroundAdviceTest  
    {  
    // 匹配 org.crazyit.app.service.impl 包下所有類的、  
    // 所有方法的執行作為切入點  
    @Around("execution(* org.crazyit.app.service.impl.*.*(..))")  
    public Object processTx(ProceedingJoinPoint jp)  
    throws java.lang.Throwable  
    {  
    System.out.println("執行目標方法之前，模擬開始事務 ...");  
    // 執行目標方法，並保存目標方法執行後的返回值  
    Object rvt = jp.proceed(new String[]{"被改變的參數"});  
    System.out.println("執行目標方法之後，模擬結束事務 ...");  
    return rvt + " 新增的內容";  
    }  
    } 

　　與前面的 AfterReturning 增強處理類似的，此處同樣使用了 @Aspect 來修飾前面 Bean，其中粗體字代碼指定在調用 org.crazyit.app.service.impl 包下的所有類的所有方法的“前後（Around）” 織入 processTx(ProceedingJoinPoint jp) 方法

　　需要指出的是，雖然此處只介紹了 Spring AOP 的 AfterReturning、Around 兩種增強處理，但實際上 Spring 還支持 Before、After、AfterThrowing 等增強處理，關於 Spring AOP 編程更多、更細致的編程細節，可以參考《輕量級 Java EE 企業應用實戰》一書。

　　本示例采用了 Spring 的零配置來開啟 Spring AOP，因此上面 Chinese 類使用了 @Component 修飾，而方面 Bean 則使用了 @Aspect 修飾，方面 Bean 中的 Advice 則分別使用了 @AfterReturning、@Around 修飾。接下來只要為 Spring 提供如下配置文件即可：

　　清單 8.bean.xml

　　    "" 
    xmlns:xsi="-instance" 
   xmlns:context="" 
   xmlns:aop=""xsi:schemaLocation="  
   -beans-3.0.xsd  
     
   -context-3.0.xsd  
     
   -aop-3.0.xsd">  
      
      
    package="org.crazyit.app.service  
    ,org.crazyit.app.advice">  
    "annotation" 
    expression="org.aspectj.lang.annotation.Aspect"/>      接下來按傳統方式來獲取 Spring 容器中 chinese Bean、並調用該 Bean 的兩個方法，程序代碼如下：

　　清單 9.BeanTest.java

　　public class BeanTest   
    {   
    public static void main(String[] args)   
    {   
    // 創建 Spring 容器  
    ApplicationContext ctx = new 
    ClassPathXmlApplicationContext("bean.xml");   
    Chinese p = ctx.getBean("chinese" ,Chinese.class);   
    System.out.println(p.sayHello("張三"));   
    p.eat("西瓜");   
    }   
    } 

　　從上面開發過程可以看出，對於 Spring AOP 而言，開發者提供的業務組件、方面 Bean 並沒有任何特別的地方。只是方面 Bean 需要使用 @Aspect 修飾即可。程序不需要使用特別的編譯器、織入器進行處理。

　　運行上面程序，將可以看到如下執行結果：

　　

　　執行目標方法之前，模擬開始事務 …

　　– 正在執行 sayHello 方法 –

　　執行目標方法之後，模擬結束事務 …

　　獲取目標方法返回值 : 被改變的參數 Hello , Spring AOP 新增的內容

　　模擬記錄日志功能 …

　　被改變的參數 Hello , Spring AOP 新增的內容

　　執行目標方法之前，模擬開始事務 …

　　我正在吃 : 被改變的參數

　　執行目標方法之後，模擬結束事務 …

　　獲取目標方法返回值 :null 新增的內容

　　模擬記錄日志功能 …

　　雖然程序是在調用 Chinese 對象的 sayHello、eat 兩個方法，但從上面運行結果不難看出：實際執行的絕對不是 Chinese 對象的方法，而是 AOP 代理的方法。也就是說，Spring AOP 同樣為 Chinese 類生成了 AOP 代理類。這一點可通過在程序中增加如下代碼看出：System.out.println(p.getClass());

　　上面代碼可以輸出 p 變量所引用對象的實現類，再次執行程序將可以看到上面代碼產生 class org.crazyit.app.service.impl.Chinese$$EnhancerByCGLIB$$290441d2 的輸出，這才是 p 變量所引用的對象的實現類，這個類也就是 Spring AOP 動態生成的 AOP 代理類。從 AOP 代理類的類名可以看出，AOP 代理類是由 CGLIB 來生成的。

　　如果將上面程序程序稍作修改：只要讓上面業務邏輯類 Chinese 類實現一個任意接口——這種做法更符合 Spring 所倡導的“面向接口編程”的原則。假設程序為 Chinese 類提供如下 Person 接口，並讓 Chinese 類實現該接口：

　　清單 10.Person.java

　　public interface Person  
    {  
    String sayHello(String name);  
    void eat(String food);  
    } 

　　接下來讓 BeanTest 類面向 Person 接口、而不是 Chinese 類編程。即將 BeanTest 類改為如下形式：

　　清單 11.BeanTest.java

　　public class BeanTest   
    {   
    public static void main(String[] args)   
    {   
    // 創建 Spring 容器  
    ApplicationContext ctx = new 
    ClassPathXmlApplicationContext("bean.xml");   
    Person p = ctx.getBean("chinese" ,Person.class);  
    System.out.println(p.sayHello("張三"));   
    p.eat("西瓜");   
    System.out.println(p.getClass());   
    }   
    } 

　　原來的程序是將面向 Chinese 類編程，現在將該程序改為面向 Person 接口編程，再次運行該程序，程序運行結果沒有發生改變。只是 System.out.println(p.getClass()); 將會輸出 class $Proxy7，這說明此時的 AOP 代理並不是由 CGLIB 生成的，而是由 JDK 動態代理生成的。

　　Spring AOP 框架對 AOP 代理類的處理原則是：如果目標對象的實現類實現了接口，Spring AOP 將會采用 JDK 動態代理來生成 AOP 代理類；如果目標對象的實現類沒有實現接口，Spring AOP 將會采用 CGLIB 來生成 AOP 代理類——不過這個選擇過程對開發者完全透明、開發者也無需關心。

　　Spring AOP 會動態選擇使用 JDK 動態代理、CGLIB 來生成 AOP 代理，如果目標類實現了接口，Spring AOP 則無需 CGLIB 的支持，直接使用 JDK 提供的 Proxy 和 InvocationHandler 來生成 AOP 代理即可。關於如何 Proxy 和 InvocationHandler 來生成動態代理不在本文介紹范圍之內，如果讀者對 Proxy 和 InvocationHandler 的用法感興趣則可自行參考 Java API 文檔或《瘋狂 Java 講義》。

　　Spring AOP 原理剖析

　　通過前面介紹可以知道：AOP 代理其實是由 AOP 框架動態生成的一個對象，該對象可作為目標對象使用。AOP 代理包含了目標對象的全部方法，但 AOP 代理中的方法與目標對象的方法存在差異：AOP 方法在特定切入點添加了增強處理，並回調了目標對象的方法.

　　AOP 代理所包含的方法與目標對象的方法示意圖如圖 3 所示。

　　圖 3.AOP 代理的方法與目標對象的方法

　　

　　Spring AOP 實現原理與 CGLIB 應用

　　Spring 的 AOP 代理由 Spring 的 IoC 容器負責生成、管理，其依賴關系也由 IoC 容器負責管理。因此，AOP 代理可以直接使用容器中的其他 Bean 實例作為目標，這種關系可由 IoC 容器的依賴注入提供。

　　縱觀 AOP 編程，其中需要程序員參與的只有 3 個部分：

　　● 定義普通業務組件。

　　● 定義切入點，一個切入點可能橫切多個業務組件。

　　● 定義增強處理，增強處理就是在 AOP 框架為普通業務組件織入的處理動作。

　　上面 3 個部分的第一個部分是最平常不過的事情，無須額外說明。那麼進行 AOP 編程的關鍵就是定義切入點和定義增強處理。一旦定義了合適的切入點和增強處理，AOP 框架將會自動生成 AOP 代理，而 AOP 代理的方法大致有如下公式：

　　代理對象的方法 = 增強處理 + 被代理對象的方法

　　在上面這個業務定義中，不難發現 Spring AOP 的實現原理其實很簡單：AOP 框架負責動態地生成 AOP 代理類，這個代理類的方法則由 Advice 和回調目標對象的方法所組成。

　　對於前面提到的圖 2 所示的軟件調用結構：當方法 1、方法 2、方法 3 ……都需要去調用某個具有“橫切”性質的方法時，傳統的做法是程序員去手動修改方法 1、方法 2、方法 3 ……、通過代碼來調用這個具有“橫切”性質的方法，但這種做法的可擴展性不好，因為每次都要改代碼。

　　於是 AOP 框架出現了，AOP 框架則可以“動態的”生成一個新的代理類，而這個代理類所包含的方法 1、方法 2、方法 3 ……也增加了調用這個具有“橫切”性質的方法——但這種調用由 AOP 框架自動生成的代理類來負責，因此具有了極好的擴展性。程序員無需手動修改方法 1、方法 2、方法 3 的代碼，程序員只要定義切入點即可—— AOP 框架所生成的 AOP 代理類中包含了新的方法 1、訪法 2、方法 3，而 AOP 框架會根據切入點來決定是否要在方法 1、方法 2、方法 3 中回調具有“橫切”性質的方法。

　　簡而言之：AOP 原理的奧妙就在於動態地生成了代理類，這個代理類實現了圖 2 的調用——這種調用無需程序員修改代碼。接下來介紹的 CGLIB 就是一個代理生成庫，下面介紹如何使用 CGLIB 來生成代理類。

　　使用 CGLIB 生成代理類

　　CGLIB（Code Generation Library），簡單來說，就是一個代碼生成類庫。它可以在運行時候動態是生成某個類的子類。

　　此處使用前面定義的 Chinese 類，現在改為直接使用 CGLIB 來生成代理，這個代理類同樣可以實現 Spring AOP 代理所達到的效果。

　　下面先為 CGLIB 提供一個攔截器實現類：

　　清單 12.AroundAdvice.java

　　public class AroundAdvice implements MethodInterceptor   
    {   
    public Object intercept(Object target, Method method   
    , Object[] args, MethodProxy proxy)   
    throws java.lang.Throwable   
    {   
    System.out.println("執行目標方法之前，模擬開始事務 ...");   
    // 執行目標方法，並保存目標方法執行後的返回值  
    Object rvt = proxy.invokeSuper(target, new String[]{"被改變的參數"});   
    System.out.println("執行目標方法之後，模擬結束事務 ...");   
    return rvt + " 新增的內容";   
    }   
    } 

　　上面這個 AroundAdvice.java 的作用就像前面介紹的 Around Advice，它可以在調用目標方法之前、調用目標方法之後織入增強處理。

　　接下來程序提供一個 ChineseProxyFactory 類，這個 ChineseProxyFactory 類會通過 CGLIB 來為 Chinese 生成代理類：

　　清單 13.ChineseProxyFactory.java

　　public class ChineseProxyFactory   
   {   
   public static Chinese getAuthInstance()   
   {   
   Enhancer en = new Enhancer();   
   // 設置要代理的目標類  
   en.setSuperclass(Chinese.class);  
   // 設置要代理的攔截器  
   en.setCallback(new AroundAdvice());  
   // 生成代理類的實例   
   return (Chinese)en.create();  
   }   
   } 

　　上面粗體字代碼就是使用 CGLIB 的 Enhancer 生成代理對象的關鍵代碼，此時的 Enhancer 將以 Chinese 類作為目標類，以 AroundAdvice 對象作為“Advice”，程序將會生成一個 Chinese 的子類，這個子類就是 CGLIB 生成代理類，它可作為 Chinese 對象使用，但它增強了 Chinese 類的方法。

　　測試 Chinese 代理類的主程序如下：

　　清單 14.Main.java

　　public class Main   
    {   
    public static void main(String[] args)   
    {   
    Chinese chin = ChineseProxyFactory.getAuthInstance();   
    System.out.println(chin.sayHello("孫悟空"));   
    chin.eat("西瓜");   
    System.out.println(chin.getClass());   
    }   
    } 

　　運行上面主程序，看到如下輸出結果：

　　

　　執行目標方法之前，模擬開始事務 …

　　– 正在執行 sayHello 方法 –

　　執行目標方法之後，模擬結束事務 …

　　被改變的參數 Hello , CGLIB 新增的內容

　　執行目標方法之前，模擬開始事務 …

　　我正在吃 : 被改變的參數

　　執行目標方法之後，模擬結束事務 …

　　class lee.Chinese$$EnhancerByCGLIB$$4bd097d9

　　從上面輸出結果來看，CGLIB 生成的代理完全可以作為 Chinese 對象來使用，而且 CGLIB 代理對象的 sayHello()、eat() 兩個方法已經增加了事務控制（只是模擬），這個 CGLIB 代理其實就是 Spring AOP 所生成的 AOP 代理。

　　通過程序最後的輸出，不難發現這個代理對象的實現類是 lee.Chinese$$EnhancerByCGLIB$$4bd097d9，這就是 CGLIB 所生成的代理類，這個代理類的格式與前面 Spring AOP 所生成的代理類的格式完全相同。

　　這就是 Spring AOP 的根本所在：Spring AOP 就是通過 CGLIB 來動態地生成代理對象，這個代理對象就是所謂的 AOP 代理，而 AOP 代理的方法則通過在目標對象的切入點動態地織入增強處理，從而完成了對目標方法的增強。

　　小結

　　AOP 廣泛應用於處理一些具有橫切性質的系統級服務，AOP 的出現是對 OOP 的良好補充，它使得開發者能用更優雅的方式處理具有橫切性質的服務。不管是那種 AOP 實現，不論是 AspectJ、還是 Spring AOP，它們都需要動態地生成一個 AOP 代理類，區別只是生成 AOP 代理類的時機不同：AspectJ 采用編譯時生成 AOP 代理類，因此具有更好的性能，但需要使用特定的編譯器進行處理；而 Spring AOP 則采用運行時生成 AOP 代理類，因此無需使用特定編譯器進行處理。由於 Spring AOP 需要在每次運行時生成 AOP 代理，因此性能略差一些

From:http://tw.wingwit.com/Article/program/Java/ky/201311/28367.html