死磕Spring之AOP篇 - Spring AOP常見面試題

死磕Spring之AOP篇 – Spring AOP常見面試題

該系列文章是本人在學習 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，執行過程中拋出異常後會被調用（如果異常類型匹配）

執行順序：Around 「前處理」 > Before > Around 「後處理」 > After > AfterReturning|AfterThrowing，如下（在後續文章會進行分析）：

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 遠程調用

在後續文章進行分析。

Tags: Spring AOP 死磕Spring之AOP篇源碼解析