概述

spirng-aop模塊是spring框架中的核心模塊，雖然spring ioc container并不依賴aop，但aop給ioc的實現提供了一種強大而靈活的解決方案。

在spring framework中，aop主要是用于兩種目的：

• 提供一些 企業 級的聲明式服務，典型的應用如 declarative transaction management .
• 允許用戶實現自己的aspects，用aop的方式來幫助和補充oop的功能及實現

aop從功能的角度來講，可能看作oop編程方式的一種補充，提供了一種不同的代碼或者系統組織方式。oop中的核心概念是class，而在aop中則是aspect。

spirng-aop模塊是spring框架中的核心模塊，雖然spring ioc container并不依賴aop，但aop給ioc的實現提供了一種強大而靈活的解決方案。

在spring framework中，aop主要是用于兩種目的：

• 提供一些企業級的聲明式服務，典型的應用如 declarative transaction management.
• 允許用戶實現自己的aspects，用aop的方式來幫助和補充oop的功能及實現

spring aop由純java實現，無須特殊的編譯處理，也不需要控制類加載器的層次結構，所以它可以適用于servlet container和其它application server.

spring aop目前只支持方法級別的切換或攔截，屬性的攔截現在不支持，如果想要攔截屬性，可以考慮使用aspectj語言。
spring aop的使用不同于其它大多數aop框架。它的主要目的不是提供一套大而全的aop實現，而是集成aop不同實現協同spring ioc來幫助解決一些普遍性問題。

需要注意的是，一些細粒度的advised（如domain model）,spring aop往往不能提供很好的支持，這場景也還是考慮aspectj。即使如此，就普遍經驗來說spring aop的強大機制依然能夠解決大多數場景的問題。
那么該如何看待spring aop和aspectj，引用spring官方文檔的原文：

spring aop will never strive to compete with aspectj to provide a comprehensive aop solution. we believe that both proxy-based frameworks like spring aop and full-blown frameworks such as aspectj are valuable, and that they are complementary, rather than in competition. spring seamlessly integrates spring aop and ioc with aspectj, to enable all uses of aop to be catered for within a consistent spring-based application architecture. this integration does not affect the spring aop api or the aop alliance api: spring aop remains backward-compatible.

在spring框架所有的模塊設計中，始終遵守的核心信條之一是——無侵入性。

所以在使用spring aop時，不會強制我們在業務代碼中引入特定類或者接口，可以最大限度的保持代碼 clean and decouple。然而spring也提供了另一種選擇，如果有特定的場景需要的話，你可以在你的代碼中直接引入spring aop。幾乎所有spring框架中的模塊，在使用的方式上都會給你多種選擇，以便讓用戶選擇更適合自己場景的方式。使用aspectj還是spring aop，使用annotation方式還是xml的配置方式，depends on u。

了解了spring aop的初衷和使用場景，來看下它的大致實現原理

在軟件世界中的絕大多數問題，都可以通過加一層來解決。

這里所說的層，當然是廣義上的，可以是一層抽象，也可以是一層cache，大致含義是隔離和解耦的范疇。

在spring的世界里，每一個模塊的引入，或者第三方技術的集成，總會提供一個抽象層 ，對用戶提供統一的api，屏蔽了所有的實現細節以及不同實現的差異。例如spring-cache，spring-jdbc，spring-jms以及spirng-messaging等模塊都提供了一層抽象。

spring aop的實現是基于代理的機制，默認是采用jdk dynamic proxy，也可以采用cglib的proxy。兩者的區別主要是在于被代理的對象的不同。當目標對象是接口時，jdk dynamic proxy可以完成代理，但目標對象是沒有實現接口的類時(盡量少一些，面向接口編程是好習慣)，是需要采用cglib proxy來完成代理的，當然你也可以強制接口也采用cglib來代理；另外需要注入或引用具體類型時，如果引用的東西恰恰是代理過的對象，此時也需要采用cglib的方式。

功能設計和實現上來可以分為兩大塊

• aop基礎設施的創建，可以看作是aopproxy的生成
• aopproxy對象的調用時的處理攔截，即處理對目標對象的攔截器

aop的創建

生成代理對象的核心類，proxyfactorybean getobjecct()

下圖是生成代理時，是用jdk還是cglib的選擇邏輯：

找到了生成代理的具體執行者，那么這個操作是在什么時候被調用的呢，了解過spring bean生命周期的都應該知道，bean在創建的時候，有一系列的回調接口供用戶插入自定義的行為，來左右bean的一些特性，其中beanpostprocessor是接口中的一種。以往的文章有介紹過(玩轉spring bean的終極利器)。而spring aop正是利用這個契機，在創建bean的過程中插了一手，如果正在創建的bean是我們aop的target，則創建代理，并最終把代理對象返回給ioc。

abstractautoproxycreator 這個類是一個beanpostprocessor的實現，用來創建代理，來看這個處理器的后處理方法，最終是返回了createproxy()方法返回的代理

aop切面的增強的執行

可以理解成對目標對象上所有攔截器鏈的調用

由于spring aop的代理具體實現有兩種，jdk dynamic proxy和cglib，所以執行攔截器的方式有所不同，具體可以閱讀源碼jdkdynamicaopproxy類的invoke方法

對目標方法的調用最終是依靠reflectivemethodinvocation.

reflectivemethodinvocation中的proceed處理是采用遞歸的方式處理攔截器鏈

cglibaopproxy的 intercept方法

cglibmethodinvoation是繼承了reflectivemethodinvocation，處理攔截器鏈也是用的上邊的proceed()方法。

在使用spring aop時需要注意的兩點細節：

1、在類內部的方法調用時（self-invoke）,spring aop不起作用，原因是內部調用沒通過代理對象，直接使用的目標對象。解決方法有：

• 重構代碼，避免內部調用
• aopcontext.currentproxy()
• 或者干脆使用aspectj語言吧...

2、在注入bean時，如果想注入bean的具體的類型而不是接口，那么采用cglib吧

spring aop的功能很強大，設計巧妙，這里梳理了主要脈絡，細節不再一一討論。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。

原文鏈接：https://mp.weixin.qq.com/s/XkSpuDCrx3nWSOBhQqAm9g