基于代理(Proxy)的AOP實(shí)現(xiàn)

首先，這是一種基于代理(Proxy)的實(shí)現(xiàn)方式。下面這張圖很好地表達(dá)了這層關(guān)系：

這張圖反映了參與到AOP過程中的幾個(gè)關(guān)鍵組件(以@Before Advice為例)：

調(diào)用者Beans - 即調(diào)用發(fā)起者，它只知道目標(biāo)方法所在Bean，并不清楚代理以及Advice的存在

目標(biāo)方法所在Bean - 被調(diào)用的目標(biāo)方法

生成的代理 - 由Spring AOP為目標(biāo)方法所在Bean生成的一個(gè)代理對(duì)象

Advice - 切面的執(zhí)行邏輯

它們之間的調(diào)用先后次序反映在上圖的序號(hào)中：

調(diào)用者Bean嘗試調(diào)用目標(biāo)方法，但是被生成的代理截了胡

代理根據(jù)Advice的種類(本例中是@Before Advice)，對(duì)Advice首先進(jìn)行調(diào)用

代理調(diào)用目標(biāo)方法

返回調(diào)用結(jié)果給調(diào)用者Bean(由代理返回，沒有體現(xiàn)在圖中)

為了理解清楚這張圖的意思和代理在中間扮演的角色，不妨看看下面的代碼：

@Componentpublic class SampleBean { public void advicedMethod() { } public void invokeAdvicedMethod() { advicedMethod(); }}@Aspect@Componentpublic class SampleAspect { @Before("execution(void advicedMethod())") public void logException() { System.out.println("Aspect被調(diào)用了"); }}sampleBean.invokeAdvicedMethod(); // 會(huì)打印出 "Aspect被調(diào)用了" 嗎？

SampleBean扮演的就是目標(biāo)方法所在Bean的角色，而SampleAspect扮演的則是Advice的角色。很顯然，被AOP修飾過的方法是advicedMethod()，而非invokeAdvicedMethod()。然而，invokeAdvicedMethod()方法在內(nèi)部調(diào)用了advicedMethod()。那么會(huì)打印出來Advice中的輸出嗎？

答案是不會(huì)。

如果想不通為什么會(huì)這樣，不妨再去仔細(xì)看看上面的示意圖。

這是在使用Spring AOP的時(shí)候可能會(huì)遇到的一個(gè)問題。類似這種間接調(diào)用不會(huì)觸發(fā)Advice的原因在于調(diào)用發(fā)生在目標(biāo)方法所在Bean的內(nèi)部，和外面的代理對(duì)象可是沒有半毛錢的關(guān)系哦。我們可以把這個(gè)代理想象成一個(gè)中介，只有它知道Advice的存在，調(diào)用者Bean和目標(biāo)方法所在Bean知道彼此的存在，但是對(duì)于代理或者是Advice卻是一無所知的。因此，沒有通過代理的調(diào)用是絕無可能觸發(fā)Advice的邏輯的。如下圖所示：

Spring AOP的兩種實(shí)現(xiàn)方式

Spring AOP有兩種實(shí)現(xiàn)方式：

• 基于接口的動(dòng)態(tài)代理(Dynamic Proxy)
• 基于子類化的CGLIB代理

我們?cè)谑褂肧pring AOP的時(shí)候，一般是不需要選擇具體的實(shí)現(xiàn)方式的。Spring AOP能根據(jù)上下文環(huán)境幫助我們選擇一種合適的。那么是不是每次都能夠這么”智能”地選擇出來呢？也不盡然，下面的例子就反映了這個(gè)問題：

@Componentpublic class SampleBean implements SampleInterface { public void advicedMethod() { } public void invokeAdvicedMethod() { advicedMethod(); }}public interface SampleInterface {}

在上述代碼中，我們?yōu)樵瓉淼腂ean實(shí)現(xiàn)了一個(gè)新的接口SampleInterface，這個(gè)接口中并沒有定義任何方法。這個(gè)時(shí)候，再次運(yùn)行相關(guān)測試代碼的時(shí)候就會(huì)出現(xiàn)異常(摘錄了部分異常信息)：

org.springframework.beans.factory.BeanCreationException: Error ceating bean with name 'com.destiny1020.SampleBeanTest': Injection of autowired dependencies failedCaused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [com.destiny1020.SampleBean] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency.

也就是說在Test類中對(duì)于Bean的Autowiring失敗了，原因是創(chuàng)建SampleBeanTest Bean的時(shí)候發(fā)生了異常。那么為什么會(huì)出現(xiàn)創(chuàng)建Bean的異常呢？從異常信息來看并不明顯，實(shí)際上這個(gè)問題的根源在于Spring AOP在創(chuàng)建代理的時(shí)候出現(xiàn)了問題。

這個(gè)問題的根源可以在這里得到一些線索：

Spring AOP Reference - AOP Proxies

文檔中是這樣描述的(每段后加上了翻譯)：

Spring AOP defaults to using standard JDK dynamic proxies for AOP proxies. This enables any interface (or set of interfaces) to be proxied.Spring AOP默認(rèn)使用標(biāo)準(zhǔn)的JDK動(dòng)態(tài)代理來實(shí)現(xiàn)AOP代理。這能使任何借口(或者一組接口)被代理。Spring AOP can also use CGLIB proxies. This is necessary to proxy classes rather than interfaces. CGLIB is used by default if a business object does not implement an interface. As it is good practice to program to interfaces rather than classes; business classes normally will implement one or more business interfaces. It is possible to force the use of CGLIB, in those (hopefully rare) cases where you need to advise a method that is not declared on an interface, or where you need to pass a proxied object to a method as a concrete type.Spring AOP也使用CGLIB代理。對(duì)于代理classes而非接口這是必要的。如果一個(gè)業(yè)務(wù)對(duì)象沒有實(shí)現(xiàn)任何接口，那么默認(rèn)會(huì)使用CGLIB。由于面向接口而非面向classes編程是一個(gè)良好的實(shí)踐；業(yè)務(wù)對(duì)象通常都會(huì)實(shí)現(xiàn)一個(gè)或者多個(gè)業(yè)務(wù)接口。強(qiáng)制使用CGLIB也是可能的(希望這種情況很少)，此時(shí)你需要advise的方法沒有被定義在接口中，或者你需要向方法中傳入一個(gè)具體的對(duì)象作為代理對(duì)象。

因此，上面異常的原因在于：

強(qiáng)制使用CGLIB也是可能的(希望這種情況很少)，此時(shí)你需要advise的方法沒有被定義在接口中。

我們需要advise的方法是SampleBean中的advicedMethod方法。而在添加接口后，這個(gè)方法并沒有被定義在該接口中。所以正如文檔所言，我們需要強(qiáng)制使用CGLIB來避免這個(gè)問題。

強(qiáng)制使用CGLIB很簡單：

@Configuration@EnableAspectJAutoProxy(proxyTargetClass = true)@ComponentScan(basePackages = "com.destiny1020")public class CommonConfiguration {}

向@EnableAspectJAutoProxy注解中添加屬性proxyTargetClass = true即可。

CGLIB實(shí)現(xiàn)AOP代理的原理是通過動(dòng)態(tài)地創(chuàng)建一個(gè)目標(biāo)Bean的子類來實(shí)現(xiàn)的，該子類的實(shí)例就是AOP代理，它建立起了目標(biāo)Bean到Advice的聯(lián)系。

當(dāng)然還有另外一種解決方案，那就是將方法定義聲明在新創(chuàng)建的接口中并且去掉之前添加的proxyTargetClass = true：

@Componentpublic class SampleBean implements SampleInterface { @Override public void advicedMethod() { } @Override public void invokeAdvicedMethod() { advicedMethod(); }}public interface SampleInterface { void invokeAdvicedMethod(); void advicedMethod();}@Configuration@EnableAspectJAutoProxy@ComponentScan(basePackages = "com.destiny1020")public class CommonConfiguration {}

• 從Debug Stacktrace的角度也可以看出這兩種AOP實(shí)現(xiàn)方式上的區(qū)別：
• JDK動(dòng)態(tài)代理

• CGLIB

• 關(guān)于動(dòng)態(tài)代理和CGLIB這兩種方式的簡要總結(jié)如下：
• JDK動(dòng)態(tài)代理(Dynamic Proxy)
• 基于標(biāo)準(zhǔn)JDK的動(dòng)態(tài)代理功能
• 只針對(duì)實(shí)現(xiàn)了接口的業(yè)務(wù)對(duì)象
• CGLIB
• 通過動(dòng)態(tài)地對(duì)目標(biāo)對(duì)象進(jìn)行子類化來實(shí)現(xiàn)AOP代理，上面截圖中的SampleBean$$EnhancerByCGLIB$$1767dd4b即為動(dòng)態(tài)創(chuàng)建的一個(gè)子類
• 需要指定@EnableAspectJAutoProxy(proxyTargetClass = true)來強(qiáng)制使用
• 當(dāng)業(yè)務(wù)對(duì)象沒有實(shí)現(xiàn)任何接口的時(shí)候默認(rèn)會(huì)選擇CGLIB

總結(jié)

以上是生活随笔為你收集整理的springaop实现原理_spring AOP的实现原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。