死磕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，執行過程中拋出異常后會被調用（如果異常類型匹配）

執行順序（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 遠程調用

在后續文章進行分析。