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

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

這張圖反映了參與到AOP過程中的幾個關(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生成的一個代理對象

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

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

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

代理根據(jù)Advice的種類(本例中是@Before Advice)，對Advice首先進行調(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(); // 會打印出 "Aspect被調(diào)用了" 嗎？

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

答案是不會。

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

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

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

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

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

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

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

在上述代碼中，我們?yōu)樵瓉淼腂ean實現(xiàn)了一個新的接口SampleInterface，這個接口中并沒有定義任何方法。這個時候，再次運行相關(guān)測試代碼的時候就會出現(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類中對于Bean的Autowiring失敗了，原因是創(chuàng)建SampleBeanTest Bean的時候發(fā)生了異常。那么為什么會出現(xiàn)創(chuàng)建Bean的異常呢？從異常信息來看并不明顯，實際上這個問題的根源在于Spring AOP在創(chuàng)建代理的時候出現(xiàn)了問題。

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

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默認使用標(biāo)準(zhǔn)的JDK動態(tài)代理來實現(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代理。對于代理classes而非接口這是必要的。如果一個業(yè)務(wù)對象沒有實現(xiàn)任何接口，那么默認會使用CGLIB。由于面向接口而非面向classes編程是一個良好的實踐；業(yè)務(wù)對象通常都會實現(xiàn)一個或者多個業(yè)務(wù)接口。強制使用CGLIB也是可能的(希望這種情況很少)，此時你需要advise的方法沒有被定義在接口中，或者你需要向方法中傳入一個具體的對象作為代理對象。

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

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

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

強制使用CGLIB很簡單：

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

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

CGLIB實現(xiàn)AOP代理的原理是通過動態(tài)地創(chuàng)建一個目標(biāo)Bean的子類來實現(xiàn)的，該子類的實例就是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實現(xiàn)方式上的區(qū)別：
• JDK動態(tài)代理

• CGLIB

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

總結(jié)

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

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