1、簡(jiǎn)介

今天有多個(gè)可用的 AOP 庫, 它們需要能夠回答許多問題：

1、是否與用戶現(xiàn)有的或新的應(yīng)用程序兼容？

2、在哪里可以實(shí)現(xiàn) AOP？

3、與自己的應(yīng)用程序集成多快？

4、性能開銷是多少？

在本文中, 我們將研究如何回答這些問題, 并介紹 Spring aop 和 AspectJ, 這是 Java 的兩個(gè)最受歡迎的 aop 框架。

2、AOP概念

在開始之前, 讓我們對(duì)術(shù)語和核心概念進(jìn)行快速、高層次的審查:

Aspect —— 一種標(biāo)準(zhǔn)代碼/功能, 分散在應(yīng)用程序中的多個(gè)位置, 通常與實(shí)際的業(yè)務(wù)邏輯不同 (例如, 事務(wù)管理)。每個(gè)方面都側(cè)重于特定的跨裁剪功能

Joinpoint —— 它是執(zhí)行程序 (如方法執(zhí)行、構(gòu)造函數(shù)調(diào)用或字段分配) 期間的特定點(diǎn)

Advice —— 特定 joinpoint 中的方面所采取的行動(dòng)

Pointcut —— 與 joinpoint 匹配的正則表達(dá)式。每次連接點(diǎn)與切入點(diǎn)匹配時(shí), 都將執(zhí)行與該切入點(diǎn)關(guān)聯(lián)的指定建議。

Weaving —— 將各方面與目標(biāo)對(duì)象鏈接起來以創(chuàng)建建議對(duì)象的過程

3、Spring AOP 和 AspectJ

現(xiàn)在, 讓我們?cè)谝恍┚S度上討論 Spring AOP 和 AspectJ —— 例如功能、目標(biāo)、Weaving（織入）、內(nèi)部結(jié)構(gòu)、joinpoints 和簡(jiǎn)單性。

3.1、能力和目標(biāo)

簡(jiǎn)單地說, Spring AOP 和 AspectJ 有不同的目標(biāo)。

Spring aop 旨在提供一個(gè)跨 Spring IoC 的簡(jiǎn)單的 aop 實(shí)現(xiàn), 以解決程序員面臨的最常見問題。它不打算作為一個(gè)完整的 AOP 解決方案 —— 它只能應(yīng)用于由 Spring 容器管理的 bean。

另一方面, AspectJ 是原始的 aop 技術(shù), 目的是提供完整的 aop 解決方案。它更健壯, 但也比 Spring AOP 復(fù)雜得多。還值得注意的是, AspectJ 可以在所有域?qū)ο笾袘?yīng)用。

3.2、Weaving（織入）

AspectJ 和 Spring AOP 都使用不同類型的編織, 這會(huì)影響它們?cè)谛阅芎鸵子眯苑矫娴男袨椤?/p>

AspectJ 使用三種不同類型的Weaving:

編譯時(shí) Weaving: AspectJ 編譯器作為輸入我們的方面的源代碼和我們的應(yīng)用, 并產(chǎn)生一個(gè)織入類文件作為輸出；

編譯后 Weaving: 這也稱為二進(jìn)制織入。它是用來織入現(xiàn)有的類文件和 JAR 文件與我們的方面；

加載時(shí)間 Weaving: 這就像前二進(jìn)制織入, 不同的是織入被推遲, 直到類加載程序加載類文件到 JVM。

要了解更多關(guān)于 AspectJ 本身的詳細(xì)信息, 請(qǐng) 閱讀此文。

當(dāng) AspectJ 使用編譯時(shí)和class文件加載時(shí)織入時(shí)，Spring AOP 利用運(yùn)行時(shí)織入。

使用運(yùn)行時(shí)編織, 這些方面在使用目標(biāo)對(duì)象的代理執(zhí)行應(yīng)用程序時(shí)被編織-使用 JDK 動(dòng)態(tài)代理或 CGLIB 代理 (在下一點(diǎn)討論):

3.3、內(nèi)部結(jié)構(gòu)與應(yīng)用

Spring aop 是基于代理的 aop 框架。這意味著, 要實(shí)現(xiàn)目標(biāo)對(duì)象的各個(gè)方面, 它將創(chuàng)建該對(duì)象的代理。使用以下兩種方法之一實(shí)現(xiàn):

1、JDK 動(dòng)態(tài)代理 —— Spring AOP 的首選方式。只要目標(biāo)對(duì)象實(shí)現(xiàn)甚至一個(gè)接口, 就會(huì)使用 JDK 動(dòng)態(tài)代理；

2、CGLIB 代理 —— 如果目標(biāo)對(duì)象沒有實(shí)現(xiàn)接口, 則可以使用 CGLIB 代理。

我們可以從 官方文檔 中了解有關(guān) Spring AOP 代理機(jī)制的更多信息。

另一方面, AspectJ 在運(yùn)行時(shí)不做任何事情, 因?yàn)轭愂侵苯佑梅矫孢M(jìn)行編譯的。

與 Spring AOP 不同, 它不需要任何設(shè)計(jì)模式。為了編織代碼的各個(gè)方面, 它引入了稱為 AspectJ 編譯器 (ajc) 的編譯器, 通過它編譯我們的程序, 然后通過提供一個(gè)小型 (100K) 運(yùn)行時(shí)庫來運(yùn)行它。

3.4、Joinpoints

在3.3 節(jié)中, 我們顯示了 Spring AOP 是基于代理模式的。因此, 它需要將目標(biāo) Java 類分類, 并相應(yīng)地應(yīng)用交叉問題。

但這是有限制的。我們不能在 "最終" 類中應(yīng)用交叉問題 (或方面), 因?yàn)樗鼈儾荒鼙恢貙? 因此會(huì)導(dǎo)致運(yùn)行時(shí)異常。

同樣適用于靜態(tài)和最終方法。不能將 Spring 方面應(yīng)用于它們, 因?yàn)樗鼈儾荒鼙桓采w。因此, 由于這些限制, Spring AOP 只支持方法執(zhí)行連接點(diǎn)。

然而, AspectJ 在運(yùn)行前直接將橫切關(guān)注點(diǎn)編織到實(shí)際代碼中。與 Spring AOP 不同, 它不需要對(duì)目標(biāo)對(duì)象進(jìn)行子類, 因此也支持許多其他 joinpoints。

以下是支持的 joinpoints 的摘要：

還值得注意的是, 在 Spring AOP 中, aspects不應(yīng)用于在同一個(gè)類中相互調(diào)用的方法。

這顯然是因?yàn)楫?dāng)我們調(diào)用同一類中的方法時(shí), 我們就不會(huì)調(diào)用 Spring AOP 提供的代理的方法。如果我們需要這個(gè)功能, 那么我們必須在不同的 bean 中定義一個(gè)單獨(dú)的方法, 或者使用 AspectJ。

3.5、簡(jiǎn)單性

Spring AOP 顯然更簡(jiǎn)單, 因?yàn)樗粫?huì)在我們的構(gòu)建過程中引入任何額外的編譯器或織入。它使用運(yùn)行時(shí)編織, 因此它與我們通常的構(gòu)建過程無縫集成。雖然它看起來很簡(jiǎn)單, 但它只適用于由 Spring 管理的 bean。

但是, 要使用 AspectJ, 我們需要引入 AspectJ 編譯器 (ajc) 并重新打包所有的庫 (除非我們切換到編譯后或加載時(shí)間的織入)。

當(dāng)然, 這比前者更復(fù)雜, 因?yàn)樗肓?AspectJ Java 工具 (包括編譯器 (ajc)、調(diào)試器 (ajdb)、文檔生成器 (ajdoc)、程序結(jié)構(gòu)瀏覽器 (ajbrowser)), 我們需要將它們與我們的 IDE 或生成工具。

3.6、性能

就性能而言, 編譯時(shí)織入比運(yùn)行時(shí)織入快得多。Spring AOP 是基于代理的框架, 因此在應(yīng)用程序啟動(dòng)時(shí)會(huì)創(chuàng)建代理。另外, 每個(gè)方面還有一些方法調(diào)用, 這會(huì)對(duì)性能產(chǎn)生負(fù)面影響。

另一方面, AspectJ 在應(yīng)用程序執(zhí)行之前將這些方面編織到主代碼中, 因此沒有額外的運(yùn)行時(shí)開銷, 與 Spring AOP 不同。

基于這些原因, 基準(zhǔn)表明 AspectJ 的速度幾乎比 Spring AOP 快8到35倍。

4、總結(jié)

此快速表總結(jié)了 Spring AOP 和 AspectJ 之間的關(guān)鍵區(qū)別：

5、選擇正確的框架

如果我們分析了本節(jié)中提出的所有論點(diǎn), 我們就會(huì)開始理解, 一個(gè)框架比另一個(gè)架構(gòu)更好。

簡(jiǎn)單地說， 選擇很大程度上取決于我們的要求：

框架： 如果應(yīng)用程序沒有使用 spring 框架, 那么我們就別無選擇, 只能放棄使用 spring AOP 的想法, 因?yàn)樗鼰o法管理任何超出 spring 容器范圍的東西。但是, 如果我們的應(yīng)用程序是完全使用 spring 框架創(chuàng)建的, 那么我們可以使用 spring AOP, 因?yàn)樗呛?jiǎn)單的學(xué)習(xí)和應(yīng)用

靈活性： 由于有限的 joinpoint 支持, Spring aop 不是一個(gè)完整的 aop 解決方案, 但它解決了程序員面臨的最常見的問題。盡管如果我們想深入挖掘和開發(fā) AOP 以達(dá)到其最大能力, 并希望得到廣泛的可用 joinpoints 的支持, 那么最好選擇 AspectJ

性能： 如果我們使用的是有限的切面, 那么就會(huì)有細(xì)微的性能差異。但有時(shí), 應(yīng)用程序有成千上萬個(gè)切面的情況。我們不想在這樣的情況下使用運(yùn)行時(shí)編織, 所以最好選擇 AspectJ。AspectJ 已知的速度比 Spring AOP 快8到35倍

兩者的最佳之處： 這兩個(gè)框架都是完全兼容的。我們總是可以利用 Spring AOP； 只要有可能, 仍然可以在不支持前者的地方使用 AspectJ 獲得支持

6、結(jié)論

在本文中, 我們分析了 Spring AOP 和 AspectJ 的幾個(gè)關(guān)鍵領(lǐng)域。

我們比較了兩種 AOP 方法的靈活性, 以及它們將如何輕松地適應(yīng)我們的應(yīng)用程序。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。