該系列文章是本人在學習 Spring 的過程中總結下來的,裡面涉及到相關原始碼,可能對讀者不太友好,請結合我的原始碼註釋 Spring 原始碼分析 GitHub 地址 進行閱讀。
Spring 版本:5.1.14.RELEASE
在開始閱讀 Spring AOP 原始碼之前,需要對 Spring IoC 有一定的瞭解,可檢視我的 《死磕Spring之IoC篇 - 文章導讀》 這一系列文章
該系列其他文章請檢視:《死磕 Spring 之 AOP 篇 - 文章導讀》
- 什麼是 AOP?
- 為什麼要引入 AOP?
- 簡述 AOP 的使用場景?
- 簡述 AOP 中幾個比較重要的概念
- 你知道哪幾種 AOP 框架?
- 什麼是 AOP 代理?
- 講講 JDK 動態代理?
- 講講 CGLIB 動態代理?
- JDK 動態代理和 CGLIB 動態代理有什麼不同?
- Spring AOP 和 AspectJ 有什麼關聯?
- Spring AOP 中有哪些 Advice 型別?
- Spring AOP 中 Advisor 介面是什麼?
- 簡述 Spring AOP 自動代理的實現
- 請解釋 Spring @EnableAspectJAutoProxy 的原理?
- Spring Configuration Class CGLIB 提升與 AOP 類代理關係?
- Sping AOP 應用到哪些設計模式?
- Spring AOP 在 Spring Framework 內部有哪些應用?
什麼是 AOP?
官方文件:
AspectJ:Aspect-oriented programming is a way of modularizing crosscutting concerns much like object-oriented programming is a way of modularizing common concerns.
Spring:Aspect-oriented Programming (AOP) complements Object-oriented Programming (OOP) by providing another way of thinking about program structure. The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect. Aspects enable the modularization of concerns (such as transaction management) that cut across multiple types and objects. (Such concerns are often termed “crosscutting” concerns in AOP literature.)
AOP(Aspect-oriented Programming)面向切面程式設計,是一種開發理念,是 OOP 物件導向程式設計的補充。我們知道,Java 就是一門物件導向程式設計的語言,在 OOP 中最小的單元就是“Class 物件”,但是在 AOP 中最小的單元是“切面”。一個“切面”可以包含很多種型別和物件,對它們進行模組化管理,例如事務管理。
為什麼要引入 AOP?
Java OOP 存在哪些侷限性?
- 靜態化語言:類結構一旦定義,不容易被修改
- 侵入性擴充套件:通過繼承或組合組織新的類結構
通過 AOP 我們可以把一些非業務邏輯的程式碼(比如安全檢查、監控等程式碼)從業務中抽取出來,以非入侵的方式與原方法進行協同。這樣可以使得原方法更專注於業務邏輯,程式碼介面會更加清晰,便於維護。
簡述 AOP 的使用場景?
日誌場景
- 診斷上下文,如:log4j 或 logback 中的 _x0008_MDC
- 輔助資訊,如:方法執行時間
統計場景
- 方法呼叫次數
- 執行異常次數
- 資料抽樣
- 數值累加
安防場景
- 熔斷,如:Netflix Hystrix
- 限流和降級:如:Alibaba Sentinel
- 認證和授權,如:Spring Security
- 監控,如:JMX
效能場景
- 快取,如 Spring Cache
- 超時控制
可以說在我們的日常開發環境中都是離不開 AOP 的。
簡述 AOP 中幾個比較重要的概念
在 AOP 中有以下幾個概念:
-
AspectJ:切面,只是一個概念,沒有具體的介面或類與之對應,是 Join point,Advice 和 Pointcut 的一個統稱。
-
Join point:連線點,指程式執行過程中的一個點,例如方法呼叫、異常處理等。在 Spring AOP 中,僅支援方法級別的連線點。
-
Advice:通知,即我們定義的一個切面中的橫切邏輯,有“around”,“before”和“after”三種型別。在很多的 AOP 實現框架中,Advice 通常作為一個攔截器,也可以包含許多個攔截器作為一條鏈路圍繞著 Join point 進行處理。
-
Pointcut:切點,用於匹配連線點,一個 AspectJ 中包含哪些 Join point 需要由 Pointcut 進行篩選。
-
Introduction:引介,讓一個切面可以宣告被通知的物件實現任何他們沒有真正實現的額外的介面。例如可以讓一個代理物件代理兩個目標類。
-
Weaving:織入,在有了連線點、切點、通知以及切面,如何將它們應用到程式中呢?沒錯,就是織入,在切點的引導下,將通知邏輯插入到目標方法上,使得我們的通知邏輯在方法呼叫時得以執行。
-
AOP proxy:AOP 代理,指在 AOP 實現框架中實現切面協議的物件。在 Spring AOP 中有兩種代理,分別是 JDK 動態代理和 CGLIB 動態代理。
-
Target object:目標物件,就是被代理的物件。
你知道哪幾種 AOP 框架?
主流 AOP 框架:
- AspectJ:完整的 AOP 實現框架
- Spring AOP:非完整的 AOP 實現框架
Spring AOP 是基於 JDK 動態代理和 Cglib 提升實現的,兩種代理方式都屬於執行時的一個方式,所以它沒有編譯時的一個處理,那麼因此 Spring 是通過 Java 程式碼實現的。AspectJ 自己有一個編譯器,在編譯時期可以修改 .class 檔案,在執行時也會進行處理。
Spring AOP 有別於其他大多數 AOP 實現框架,目的不是提供最完整的 AOP 實現(儘管 Spring AOP 相當強大);相反,其目的是在 AOP 實現和 Spring IoC 之間提供緊密的整合,以提供企業級核心特性。
Spring AOP 從未打算與 AspectJ 競爭以提供全面的 AOP 解決方案,我們認為 Spring AOP 等基於代理實現的框架和 AspectJ 等成熟的框架都是有價值的,並且它們是互補的,而不是競爭關係。Spring 將 Spring AOP 和 IoC 與 AspectJ 無縫整合,以實現 AOP 的所有功能都可以在一個 Spring 應用中。這種整合不會影響 Spring AOP API 或 AOP Alliance API,保持向後相容。
什麼是 AOP 代理?
代理模式是一種結構性設計模式,通過代理類為其他物件提供一種代理以控制對這個物件的訪問。AOP 代理是 AOP 框架中 AOP 的實現,主要分為靜態代理和動態代理,如下:
- 靜態代理:代理類需要實現被代理類所實現的介面,同時持有被代理類的引用,新增處理邏輯,進行攔截處理,不過方法還是由被代理類的引用所執行。靜態代理通常需要由開發人員在編譯階段就定義好,不易於維護。
- 常用 OOP 繼承和組合相結合
- AspectJ,在編輯階段會織入 Java 位元組碼,且在執行期間會進行增強。
- 動態代理:不會修改位元組碼,而是在 JVM 記憶體中根據目標物件新生成一個 Class 物件,這個物件包含了被代理物件的全部方法,並且在其中進行了增強。
- JDK 動態代理
- 位元組碼提升,例如 CGLIB
講講 JDK 動態代理?
基於介面代理,通過反射機制生成一個實現代理介面的類,在呼叫具體方法時會呼叫 InvocationHandler 來處理。
需要藉助 JDK 的 java.lang.reflect.Proxy
來建立代理物件,呼叫 Proxy.newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h)
方法建立一個代理物件,方法的三個入參分別是:
ClassLoader loader
:用於載入代理物件的 Class 類載入器Class<?>[] interfaces
:代理物件需要實現的介面InvocationHandler h
:代理物件的處理器
新生成的代理物件的 Class 物件會繼承 Proxy
,且實現所有的入參 interfaces
中的介面,在實現的方法中實際是呼叫入參 InvocationHandler
的 invoke(..)
方法。
為什麼 JDK 動態代理只能基於介面代理,不能基於類代理?
因為 JDK 動態代理生成的代理物件需要繼承
Proxy
這個類,在 Java 中類只能是單繼承關係,無法再繼承一個代理類,所以只能基於介面代理。
為什麼 InvocationHandler 不直接宣告到這個代理物件裡面,而是放入繼承的
Proxy
父類中?我覺得代理類既然是 JDK 動態生成的,那麼 JDK 就需要識別出哪些類是生成的代理類,哪些是非代理類,或者說 JDK 需要對代理類做統一的處理,這時如果沒有一個統一的類 Proxy 來進行引用根本無法處理。這只是筆者的想法,具體為什麼這麼做不知道有小夥伴知道不 ~
講講 CGLIB 動態代理?
JDK 動態代理的目標物件必須是一個介面,在我們日常生活中,無法避免開發人員不寫介面直接寫類,或者根本不需要介面,直接用類進行表達。這個時候我們就需要通過一些位元組碼提升的手段,來幫助做這個事情,在執行時,非編譯時,來建立一個新的 Class 物件,這種方式稱之為位元組碼提升。在 Spring 內部有兩個位元組碼提升的框架,ASM(過於底層,直接操作位元組碼)和 CGLIB(相對於前者更加簡便)。
CGLIB 動態代理則是基於類代理(位元組碼提升),通過 ASM(Java 位元組碼的操作和分析框架)將被代理類的 class 檔案載入進來,修改其位元組碼生成一個子類。
需要藉助於 CGLIB 的 org.springframework.cglib.proxy.Enhancer
類來建立代理物件,設定以下幾個屬性:
Class<?> superClass
:被代理的類Callback callback
:回撥介面
新生成的代理物件的 Class 物件會繼承 superClass
被代理的類,在重寫的方法中會呼叫 callback
回撥介面(方法攔截器)進行處理。
如果你想設定一個 Callback[] 陣列去處理不同的方法,那麼需要設定一個 CallbackFilter 篩選器,用於選擇具體的方法使用陣列中的哪個 Callback 去處理
JDK 動態代理和 CGLIB 動態代理有什麼不同?
兩者都是在 JVM 執行時期新建立一個 Class 物件,例項化一個代理物件,對目標類(或介面)進行代理。JDK 動態代理只能基於介面進行代理,生成的代理類實現了這些介面;而 CGLIB 動態代理則是基於類進行代理的,生成的代理類繼承目標類,但是不能代理被 final 修飾的類,也不能重寫 final 或者 private 修飾的方法。
CGLIB 動態代理比 JDK 動態代理複雜許多,效能也相對比較差。
Spring AOP 和 AspectJ 有什麼關聯?
Spring AOP 和 AspectJ 都是 AOP 的實現框架,AspectJ 是 AOP 的完整實現,Spring AOP 則是部分實現。AspectJ 有一個很好的程式設計模型,包含了註解的方式,也包含了特殊語法。Spring 認為 AspectJ 的實現在 AOP 體系裡面是完整的,不需要在做自己的一些實現。
Spring AOP 整合 AspectJ 註解與 Spring IoC 容器,比 AspectJ 的使用更加簡單,也支援 API 和 XML 的方式進行使用。不過 Spring AOP 僅支援方法級別的 Pointcut 攔截。
為什麼 Spring AOP 底層沒有使用 AspectJ 動態代理建立代理物件?
我覺得是因為 AspectJ 的特殊語法對於 Spring 或者 Java 開發人員來說不是很友好,使用起來可能有點困難。Spring 也選擇整合 AspectJ 的註解,使用起來非常方便。
Spring AOP 中有哪些 Advice 型別?
- Around Advice,圍繞型通知器,需要主動去觸發目標方法的執行,這樣可以在觸發的前後進行相關相關邏輯處理
- Before Advice,前置通知器,在目標方法執行前會被呼叫
- After Advice,後置通知器
- AfterReturning,在目標方法執行後被呼叫(方法執行過程中出現異常不會被呼叫)
- After,在目標方法執行後被呼叫(執行過程出現異常也會被呼叫)
- AfterThrowing,執行過程中丟擲異常後會被呼叫(如果異常型別匹配)
執行順序(Spring 5.2.7 之前的版本):Around “前處理” > Before > 方法執行 > Around “後處理” > After > AfterReturning|AfterThrowing
執行順序(Spring 5.2.7 開始):Around “前處理” > Before > 方法執行 > AfterReturning|AfterThrowing > After > Around “後處理”
如下(在後續文章會進行分析,Spring 5.1.14):
Spring AOP 中 Advisor 介面是什麼?
Advisor 是 Advice 的一個容器介面,與 Advice 是一對一的關係,它的子介面 PointcutAdvisor 是 Pointcut 和 Advice 的容器介面,將 Pointcut 過濾 Joinpoint 的能力和 Advice 進行整合,這樣一來就將兩者進行關聯起來了。
Pointcut 提供 ClassFilter 和 MethedMatcher,分別支援篩選類和方法,通過 PointcutAdvisor 和 Advice 進行整合,可以說是形成了一個“切面”。
簡述 Spring AOP 自動代理的實現
在我們有了 Join point(連線點)、Pointcut(切點)、Advice(通知)以及 AspectJ(切面)後,我們應該如何將他們“織入”我們的應用呢?在 Sping AOP 中提供了自動代理的實現,底層藉助 JDK 動態代理和 CGLIB 動態代理建立物件。
回顧 Spring IoC 中 Bean 的載入過程,在整個過程中,Bean 的例項化前和初始化後等生命週期階段都提供了擴充套件點,會呼叫相應的 BeanPostProcessor 處理器對 Bean 進行處理。當我們開啟了 AspectJ 自動代理(例如通過 @EnableAspectJAutoProxy
註解),則會往 IoC 容器中註冊一個 AbstractAutoProxyCreator
自動代理物件,該物件實現了幾種 BeanPostProcessor,例如在每個 Bean 初始化後會被呼叫,解析出當前 Spring 上下文中所有的 Advisor(會快取),如果這個 Bean 需要進行代理,則會通過 JDK 動態代理或者 CGLIB 動態代理建立一個代理物件並返回,所以得到的這個 Bean 實際上是一個代理物件。這樣一來,開發人員只需要配置好 AspectJ 相關資訊,Spring 則會進行自動代理,和 Spring IoC 完美地整合在一起。
參考:《死磕Spring之IoC篇 - Bean 的建立過程》
請解釋 Spring @EnableAspectJAutoProxy 的原理?
使用了 @EnableAspectJAutoProxy
註解則會開啟 Spring AOP 自動代理,該註解上面有一個 @Import(AspectJAutoProxyRegistrar.class)
註解,AspectJAutoProxyRegistrar
實現了 ImportBeanDefinitionRegistrar
這個介面,在實現的方法中會註冊一個 AnnotationAwareAspectJAutoProxyCreator
自動代理物件(如果沒有註冊的話),且將其優先順序設定為最高,同時解析 @EnableAspectJAutoProxy
註解的配置並進行設定。這個自動代理物件是一個 BeanPostProcessor 處理器,在 Spring 載入一個 Bean 的過程中,如果它需要被代理,那麼會建立一個代理物件(JDK 動態代理或者 CGLIB 動態代理)。
除了註解的方式,也可以通過 <aop:aspectj-autoproxy />
標籤開啟 Spring AOP 自動代理,原理和註解相同,同樣是註冊一個自動代理物件。
@Import
註解的原理參考:《死磕Spring之IoC篇 - @Bean 等註解的實現原理》
XML 自定義標籤的原理參考:《死磕Spring之IoC篇 - 解析自定義標籤(XML 檔案)》
Spring Configuration Class CGLIB 提升與 AOP 類代理關係?
在 Spring 底層 IoC 容器初始化後,會通過 BeanDefinitionRegistryPostProcessor
對其進行後置處理,其中會有一個 ConfigurationClassPostProcessor
處理器會對 @Configuration
標註的 BeanDefinition 進行處理,進行 CGLIB 提升,這樣一來對於後續的 Spring AOP 工作就非常簡單了,因為這個 Bean 天然就是一個 CGLIB 代理。
在 Spring 5.2 開始 @Configuration
註解中新增了一個 proxyBeanMethods
屬性(預設為 true),支援顯示的配置是否進行 CGLIB 提升,畢竟進行 CGLIB 提升在啟動過程會有一定的效能損耗,且建立的代理物件會佔有一定的記憶體,通過該配置進行關閉,可以減少不必要的麻煩,對 Java 雲原生有一定的提升。
@Configuration
註解的 Bean 進行 CGLIB 提升後有什麼作用呢?舉個例子,大多數情況下,
@Configuration
Class 會通過@Bean
註解為 Bean 定義,比如 @Bean User user() { return new User(); },那這樣是不是每次主動呼叫這個方法都會返回一個新的 User 物件呢?不是的,
@Configuration
Class 在得到 CGLIB 提升後,會設定一個攔截器專門對@Bean
方法進行攔截處理,通過依賴查詢的方式從 IoC 容器中獲取 Bean 物件,如果是單例 Bean,那麼每次都是返回同一個物件,所以當主動呼叫這個方法時獲取到的都是同一個 User 物件。
參考:《死磕Spring之IoC篇 - @Bean 等註解的實現原理》
Sping AOP 應用到哪些設計模式?
如下:
- 建立型模式:抽象工廠模式、工廠方法模式、構建器模式、單例模式、原型模式
- 結構型模式:介面卡模式、組合模式、裝飾器模式、享元模式、代理模式
- 行為型模式:模板方法模式、責任鏈模式、觀察者模式、策略模式、命令模式、狀態模式
關於每種設計模式,以及在 Spring AOP 中的應用在後續文章會進行簡單的介紹。
Spring AOP 在 Spring Framework 內部有哪些應用?
Spring 事件、Spring 事務、Spring 資料、Spring 快取抽象、Spring 本地排程、Spring 整合、Spring 遠端呼叫
在後續文章進行分析。