2. 程式人生 > >[AOP] 2. AOP的兩種實現-Spring AOP以及AspectJ

[AOP] 2. AOP的兩種實現-Spring AOP以及AspectJ

阿新 • • 發佈：2019-01-05

在接觸Spring以及種類繁多的Java框架時，很多開發人員(至少包括我)都會覺得註解是個很奇妙的存在，為什麼加上了@Transactional之後，方法會在一個事務的上下文中被執行呢？為什麼加上了@Cacheable之後，方法的返回值會被記錄到快取中，從而讓下次的重複呼叫能夠直接利用快取的結果呢？

隨著對AOP的逐漸應用和了解，才明白註解只是一個表象，在幕後Spring AOP/AspectJ做了大量的工作才得以實現這些神奇的功能。

那麼，本文就來聊一聊Spring AOP和AspectJ的那些事，它們究竟有什麼魔力才讓這一切成為現實。

Spring AOP

基於代理(Proxy)的AOP實現

首先，這是一種基於代理(Proxy)的實現方式。下面這張圖很好地表達了這層關係：

這張圖反映了參與到AOP過程中的幾個關鍵元件(以@Before Advice為例)：

  1. 呼叫者Beans - 即呼叫發起者，它只知道目標方法所在Bean，並不清楚代理以及Advice的存在
  2. 目標方法所在Bean - 被呼叫的目標方法
  3. 生成的代理 - 由Spring AOP為目標方法所在Bean生成的一個代理物件
  4. Advice - 切面的執行邏輯

它們之間的呼叫先後次序反映在上圖的序號中：

  1. 呼叫者Bean嘗試呼叫目標方法，但是被生成的代理截了胡
  2. 代理根據Advice的種類(本例中是@Before Advice)，對Advice首先進行呼叫
  3. 代理呼叫目標方法
  4. 返回呼叫結果給呼叫者Bean(由代理返回，沒有體現在圖中)

為了理解清楚這張圖的意思和代理在中間扮演的角色，不妨看看下面的程式碼：

@Component
public class SampleBean {

  public void advicedMethod() {

  }

  public void invokeAdvicedMethod() {
    advicedMethod();
  }

}

@Aspect
@Component
public class SampleAspect {

  @Before("execution(void advicedMethod())"
 
)
  public void logException() {
    System.out.println("Aspect被呼叫了");
  }

}

sampleBean.invokeAdvicedMethod(); // 會打印出 "Aspect被呼叫了" 嗎？

SampleBean扮演的就是目標方法所在Bean的角色，而SampleAspect扮演的則是Advice的角色。很顯然，被AOP修飾過的方法是advicedMethod()，而非invokeAdvicedMethod()。然而，invokeAdvicedMethod()方法在內部呼叫了advicedMethod()。那麼會打印出來Advice中的輸出嗎？

答案是不會。

如果想不通為什麼會這樣，不妨再去仔細看看上面的示意圖。

這是在使用Spring AOP的時候可能會遇到的一個問題。類似這種間接呼叫不會觸發Advice的原因在於呼叫發生在目標方法所在Bean的內部，和外面的代理物件可是沒有半毛錢的關係哦。我們可以把這個代理想象成一箇中介，只有它知道Advice的存在，呼叫者Bean和目標方法所在Bean知道彼此的存在，但是對於代理或者是Advice卻是一無所知的。因此，沒有通過代理的呼叫是絕無可能觸發Advice的邏輯的。如下圖所示：

Spring AOP的兩種實現方式

Spring AOP有兩種實現方式：

  • 基於介面的動態代理(Dynamic Proxy)
  • 基於子類化的CGLIB代理

我們在使用Spring AOP的時候，一般是不需要選擇具體的實現方式的。Spring AOP能根據上下文環境幫助我們選擇一種合適的。那麼是不是每次都能夠這麼”智慧”地選擇出來呢？也不盡然，下面的例子就反映了這個問題：

@Component
public class SampleBean implements SampleInterface {

  public void advicedMethod() {

  }

  public void invokeAdvicedMethod() {
    advicedMethod();
  }

}

public interface SampleInterface {}

在上述程式碼中，我們為原來的Bean實現了一個新的介面SampleInterface，這個介面中並沒有定義任何方法。這個時候，再次執行相關測試程式碼的時候就會出現異常(摘錄了部分異常資訊)：

org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'com.destiny1020.SampleBeanTest': 
Injection of autowired dependencies failedCaused by: 
org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No qualifying bean of type [com.destiny1020.SampleBean] found for dependency: 
expected at least 1 bean which qualifies as autowire candidate for this dependency.

也就是說在Test類中對於Bean的Autowiring失敗了，原因是建立SampleBeanTest Bean的時候發生了異常。那麼為什麼會出現建立Bean的異常呢？從異常資訊來看並不明顯，實際上這個問題的根源在於Spring AOP在建立代理的時候出現了問題。

這個問題的根源可以在這裡得到一些線索：

文件中是這樣描述的(每段後加上了翻譯)：

Spring AOP defaults to using standard JDK dynamic proxies for AOP proxies. This enables any interface (or set of interfaces) to be proxied.

Spring AOP預設使用標準的JDK動態代理來實現AOP代理。這能使任何藉口(或者一組介面)被代理。

Spring AOP can also use CGLIB proxies. This is necessary to proxy classes rather than interfaces. CGLIB is used by default if a business object does not implement an interface. As it is good practice to program to interfaces rather than classes; business classes normally will implement one or more business interfaces. It is possible to force the use of CGLIB, in those (hopefully rare) cases where you need to advise a method that is not declared on an interface, or where you need to pass a proxied object to a method as a concrete type.

Spring AOP也使用CGLIB代理。對於代理classes而非介面這是必要的。如果一個業務物件沒有實現任何介面，那麼預設會使用CGLIB。由於面向介面而非面向classes程式設計是一個良好的實踐；業務物件通常都會實現一個或者多個業務介面。強制使用CGLIB也是可能的(希望這種情況很少)，此時你需要advise的方法沒有被定義在介面中，或者你需要向方法中傳入一個具體的物件作為代理物件。

因此，上面異常的原因在於：

強制使用CGLIB也是可能的(希望這種情況很少)，此時你需要advise的方法沒有被定義在介面中。

我們需要advise的方法是SampleBean中的advicedMethod方法。而在新增介面後，這個方法並沒有被定義在該介面中。所以正如文件所言，我們需要強制使用CGLIB來避免這個問題。

強制使用CGLIB很簡單：

@Configuration
@EnableAspectJAutoProxy(proxyTargetClass = true)
@ComponentScan(basePackages = "com.destiny1020")
public class CommonConfiguration {}

向@EnableAspectJAutoProxy註解中新增屬性proxyTargetClass = true即可。
CGLIB實現AOP代理的原理是通過動態地建立一個目標Bean的子類來實現的，該子類的例項就是AOP代理，它建立起了目標Bean到Advice的聯絡。

當然還有另外一種解決方案，那就是將方法定義宣告在新建立的介面中並且去掉之前新增的proxyTargetClass = true：

@Component
public class SampleBean implements SampleInterface {

  @Override
  public void advicedMethod() {

  }

  @Override
  public void invokeAdvicedMethod() {
    advicedMethod();
  }

}

public interface SampleInterface {

  void invokeAdvicedMethod();

  void advicedMethod();

}

@Configuration
@EnableAspectJAutoProxy
@ComponentScan(basePackages = "com.destiny1020")
public class CommonConfiguration {}

這樣就讓業務物件實現了一個介面，從而能夠使用基於標準JDK的動態代理來完成Spring AOP代理物件的建立。

從Debug Stacktrace的角度也可以看出這兩種AOP實現方式上的區別：

  • JDK動態代理

  • CGLIB

關於動態代理和CGLIB這兩種方式的簡要總結如下：

  • JDK動態代理(Dynamic Proxy)

    • 基於標準JDK的動態代理功能
    • 只針對實現了介面的業務物件

  • CGLIB

    • 通過動態地對目標物件進行子類化來實現AOP代理，上面截圖中的SampleBean$$EnhancerByCGLIB$$1767dd4b即為動態建立的一個子類
    • 需要指定@EnableAspectJAutoProxy(proxyTargetClass = true)來強制使用
    • 當業務物件沒有實現任何介面的時候預設會選擇CGLIB

AspectJ

AspectJ是Eclipse旗下的一個專案。至於它和Spring AOP的關係，不妨可將Spring AOP看成是Spring這個龐大的整合框架為了整合AspectJ而出現的一個模組。

畢竟很多地方都是直接用到AspectJ裡面的程式碼。典型的比如@Aspect，@Around，@Pointcut註解等等。而且從相關概念以及語法結構上而言，兩者其實非常非常相似。比如Pointcut的表示式語法以及Advice的種類，都是一樣一樣的。

那麼，它們的區別在哪裡呢？

最大的區別在於兩者實現AOP的底層原理不太一樣：

  • Spring AOP: 基於代理(Proxying)
  • AspectJ: 基於位元組碼操作(Bytecode Manipulation)

用一張圖來表示AspectJ使用的位元組碼操作，就一目瞭然了：

通過編織階段(Weaving Phase)，對目標Java型別的位元組碼進行操作，將需要的Advice邏輯給編織進去，形成新的位元組碼。畢竟JVM執行的都是Java原始碼編譯後得到的位元組碼，所以AspectJ相當於在這個過程中做了一點手腳，讓Advice能夠參與進來。

而編織階段可以有兩個選擇，分別是載入時編織(也可以成為執行時編織)和編譯時編織：

載入時編織(Load-Time Weaving)

顧名思義，這種編織方式是在JVM載入類的時候完成的。

使用它需要進行相關的配置，舉例如下：

在類路徑的META-INF目錄下建立一個檔名為aop.xml:

<aspectj>
  <weaver>
    <include within="com.destiny1020..*" />
  </weaver>
  <aspects>
    <aspect name="com.destiny1020.SampleAspect" />
  </aspects>
</aspectj>

然後新增啟動引數，直接使用AspectJ提供的或者使用Spring提供的工具：

# AspectJ
-javaagent:path_to/aspectjweaver-{version}.jar

# Spring
-javaagent:path_to/org.springframework.instrument-{version}.jar

當使用Spring提供的工具時，還需要進行一些配置，以JavaConfig為例：

@Configuration
@EnableLoadTimeWeaving
@ComponentScan(basePackages = "com.destiny1020")
public class CommonConfiguration {}

重點就是上述的@EnableLoadTimeWeaving。

編譯時編織(Compile-Time Weaving)

需要使用AspectJ的編譯器來替換JDK的編譯器。可以藉助Maven AspectJ來實現，下面是一例：

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <version>1.4</version>
    <dependencies>
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjrt</artifactId>
            <version>${aspectj.version}</version>
        </dependency>
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjtools</artifactId>
            <version>${aspectj.version}</version>
        </dependency>
    </dependencies>
    <executions>
        <execution>
            <phase>process-sources</phase>
            <goals>
                <goal>compile</goal>
                <goal>test-compile</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <outxml>true</outxml>
        <source>${java.version}</source>
        <target>${java.version}</target>
    </configuration>
</plugin>

然後直接通過mvn test進行測試：

自定義的編譯錯誤/警告

舉個例子，有兩個Service1和Service2分別位於兩個包Package1和Package2下，只能在Package2中呼叫來自本包內部的方法，在Service1中呼叫Service2中提供的方法會導致編譯錯誤(能夠用訪問控制符解決的問題強行用這種方式來解決，當然只是為了說明問題：）)：

@Aspect
public class EmitCompilationErrorAspect {

  @DeclareError("call (* com.destiny1020.biz.package2..*.*(..))"
      + "&& !within(com.destiny1020.biz.package2..*)")
  public static final String notInBizPackage2 = "只能在Package2中呼叫來自Package2的方法";

}
package com.destiny1020.biz.package1;

import com.destiny1020.biz.package2.ServiceInPackage2;

public class ServiceInPackage1 {

  ServiceInPackage2 service2 = new ServiceInPackage2();

  public void invokeMethodInPackage2() {
    service2.doBizInPackage2();  // 這裡理應會出現編譯錯誤
  }

}

實際情況也正式如此：

在宣告編譯錯誤Pointcut的時候，出現了兩個新概念：

  • call
  • within

這兩個新出現的Pointcut原語只能在使用AspectJ作為AOP實現的時候才可用。它們表達的是什麼意思呢：

  • call：針對所有的呼叫者(caller)，即哪裡呼叫了Pointcut表示式匹配的方法，在該方法被執行之前就會被匹配到；而我們經常使用的execution則是針對所有的被呼叫方法，而不會care是誰呼叫的該方法
  • within：這個很好理解，它的Pointcut表示式是一個用來匹配完整限定類名的表示式，比如上例中的!within(com.destiny1020.biz.package2..*)意味不在包com.destiny1020.biz.package2中的類。

在使用AspectJ的編譯時編織功能時，由於使用了AspectJ Compiler來完成程式碼的編譯，因此可以根據編碼規範新增相應的編譯錯誤/警告，來進一步地讓程式碼更加規範。這個特性對於輔助實現大型專案的編碼規範還是很有益處的。

哪種方式更好

先下結論：It Depends.

得根據具體需求，不過我個人認為在對AOP的需求不那麼深入和迫切的時候，使用Spring AOP足矣。

畢竟Spring作為一個以整合起家的框架，在設計Spring AOP的時候也是為了減輕開發人員負擔而做了不少努力的。它提供的開箱即用(Out-of-the-box)的眾多AOP功能讓很多開發人員甚至都不知道什麼是AOP，就算知道了AOP是Spring的一大基石或者@Transactional和@Cacheable等等常用註解是藉助了AOP的力量，但是再深入恐怕就有點勉為其難了。這是優點也是缺點，當需要對AOP的實現做出精細化調整的時候，就會有力不從心的感覺。

這個時候，就可以考慮使用AspectJ。AspectJ的功能更加全面和強大。支援全部的Pointcut型別。

這裡進行了一個簡單的比較，摘錄並簡單翻譯(括號內是我新增的補充)如下：

Spring-AOP Pros

  • 比AspectJ更簡單，不需要使用Load-Time Weaving以及AspectJ編譯器(為了Compile-Time Weaving)
  • 當使用@Aspect註解時可以很方便的遷移到AspectJ AOP實現
  • 使用代理模式和裝飾模式

Spring-AOP Cons

  • 由於是基於代理的AOP，所以基本上只能選擇方法execution這一個Pointcut原語
  • 在類本身中呼叫另一個方法的時候Aspects不會生效
  • 有一點執行時的額外開銷
  • 無法為不是從Spring Factory中建立的物件新增Aspect(只對Spring Bean有效)

AspectJ Pros

  • 支援所有的Pointcut原語，這意味著你可以做任何事情
  • 執行時開銷比Spring AOP少
  • 能夠新增各種編譯錯誤來保障程式碼質量(這一條是我自己新增的)

AspectJ Cons

  • 當心。檢查是否發生了意料之外的Weaving操作
  • 使用Compile-Time Weaving時需要額外的構建步驟(使用AspectJ Compiler)，在使用Load-Time Weaving時需要一些配置(-javaassist)

參考資料

相關推薦

[AOP] 2. AOP的兩種實現-Spring AOP以及AspectJ

在接觸Spring以及種類繁多的Java框架時，很多開發人員(至少包括我)都會覺得註解是個很奇妙的存在，為什麼加上了@Transactional之後，方法會在一個事務的上下文中被執行呢？為什麼加上了@Cacheable之後，方法的返回值會被記錄到快取中，從而讓下

使用aspectJ實現Spring AOP的兩種方式

classpath .org 導入 ntc www. 之前 oid 方式 public 方式一:基於aspectJ的XML配置 方式二:基於aspectJ的註解方式 基於aspectJ的XML配置 1) 引入相關jar包 2) 創建Spr

spring ----> aop的兩種實現方式

select imp ack exe readv expr gpo for public 實現1：基於xml 1 package com.rr.spring3.interf; //接口 2 3 public interface SayHello { 4 5

spring中AOP的兩種實現方式

1.方法一:註解實現 介面類 public interface User { public void work(); } 具體實現類 public class IUser implements User { public void work() {

Spring 詳解（二）------- AOP關鍵概念以及兩種實現方式

目錄 1. AOP 關鍵詞 2. AOP 的作用 3. AOP 的通知型別 4. 基於 xml 的配置方式 5. 基於註解的配置方式 6. 切面的優先順序 7. 重用切點表示式 8. 兩種方式的比較（摘自 spring 官方文件） 1. AOP 關鍵詞

Spring 詳解（二）------- AOP概念以及兩種實現方式

　　target：目標類，需要被代理的類。例如：ArithmeticCalculator 　　 　　Joinpoint(連線點)：所謂連線點是指那些可能被攔截到的方法。例如：所有的方法 　　 　　PointCut 切入點：已經被增強的連線點。例如：add() 　　 　　advice：通知/增強，增強

Spring AOP 之AspectJ註解和XML配置兩種實現(Maven構建)

xml配置 1.介面和實現類 public interface UserManager { public String findUserById(int userId); } @Service public class UserManage

基於aspectj實現AOP操作的兩種方式——xml配置

aop ont 方式 alt 分享圖片 文件 分享 spa 技術分享 1. 要導入的 jar 包： 常用的aspectj表達式： 權限修飾符可以省略，以下表示：返回值類型為任意，com.chy.service包以及其子包下的、任意類的、參數任意的、任意方法 ex

aop兩種實現

  *JDK 的動態代理只能對實現了介面的目標類進行代理，而不實現介面的類就不能使用 JDK 的動態代理 *CGLIB 是針對類來實現代理，當沒有實現介面的類需要代理時就需要通過 CGLIB 來實現代理了，他的原理是對指定的目標類生成一個子類，並覆蓋其中方法實現增強，但是

Spring AOP的實現:Spring AOP攔截器呼叫的實現

上次我說到關於ProxyFactoryBean物件的getObject方法返回了一個代理物件。剩下的AOP實現過程就和jdk的代理模式相同。通過呼叫這個代理物件的方法(這個方法和目標物件是相同的)，但是實際上是呼叫了invoke方法，通過反射來實現方法的增強。 關於jdk如何實現代理模式的反

反射實現 AOP 動態代理模式例項說明(Spring AOP 的實現 原理)

說明以下，spring aop的實現原理不是用java的動態代理。是用代理模式和CGLib (Code GenerationLibrary), 不過現在不用CGLib(Code Generation Library)，直接用ASM框架來操作位元組碼了。 好長時間沒有用過S

手寫實現Spring AOP

Spring IOC、AOP可謂是spring中兩大王牌 上次我們手寫了IOC，那麼今天我們來手寫一下AOP 我是學習他的寫法，然後將一些我不懂的程式碼進行了註釋解釋，應該可以更加適合小白學習吧。 一.準備 首先我們都知道Spring AOP的核心技

自己實現Spring AOP（一）環境搭建及知識準備

前言 這個專案是基於JSpring IoC的，所以在看下去之前，你要確保看過之前實現JSpring IoC的文章（這些文章在我的部落格分類JSpring IoC），不然也不看不出什麼意思來，就不用浪費時間往下看了。 在做這個專案的時候發生了一件有趣的事，我發

自己實現Spring AOP（二）JDK代理實現AOP

前言 上一篇文章自己實現Spring AOP（一）環境搭建及知識準備，我搭建好了專案也寫了一個例子，接下來我就要實現這個例子中的AOP功能。 在Spring中如果目標物件實現了介面，預設情況下會採用JDK的動態代理實現AOP，如果目標物件沒有實現介面，必須採

Spring AOP及MethodInterceptor攔截器實現方法攔截以及切入點函式阻止執行

package com.rhxy.utils; import com.rhxy.bean_new.personnel.Employee; import com.rhxy.bean_new.personnel.User; import com.rhxy.dao_new.EmployeeDAO; import c

AOP，OOP兩種程式設計思想聯絡

AOP與OOP是面向不同領域的兩種設計思想。 　AOP為Aspect Oriented Programming的縮寫，意為：面向切面程式設計，通過預編譯方式和執行期動態代理實現程式功能的統一維護的一種技術。 　　OOP（面向物件程式設計）針對業務處理過程的實

mybatis學習筆記（2）兩種配置實現增刪改查

第二天學習mybatis，發現框架的存在確實是省了我們很多時間，我們完全可以把一些操作簡化，或者實現簡單的封裝提供我們使用。昨天是跟著教程雲裡霧裡的實現了配置，今天再次使用就方便很多。 String resource="conf.xml"; //使用類載入myba

Spring AOP: 0 formal unbound in pointcut(Spring AOP)

 @Pointcut("execution(* com.user.action.AopController.*(..))")     public  void controllerAspect() {       }&n

spring-data-mongodb兩種實現方式對比

  之前介紹過springboot和mongodb整合，使用了spring-data-mongodb，因為springboot註解和自動化配置，我們少了很多配置，這裡介紹spring整合mongodb，使用的仍然是spring-data-mongodb，這裡需要配置一個spring-mo

【SSH進階之路】Spring的IOC逐層深入——依賴注入的兩種實現型別(四)

        上篇博文，我們介紹了為什麼使用IOC容器，和IOC的設計思想以及IOC容器的優缺點，並且給大家轉載了一篇介紹IOC原理的博文，我們這篇主要給大家依賴注入的兩種方式，以及他們的優缺點。