摘要：又是什么其實(shí)就是一種實(shí)現(xiàn)動(dòng)態(tài)代理的技術(shù)，利用了開(kāi)源包，先將代理對(duì)象類的文件加載進(jìn)來(lái)，之后通過(guò)修改其字節(jié)碼并且生成子類。

在實(shí)際研發(fā)中，Spring是我們經(jīng)常會(huì)使用的框架，畢竟它們太火了，也因此Spring相關(guān)的知識(shí)點(diǎn)也是面試必問(wèn)點(diǎn)，今天我們就大話Aop。
特地在周末推文，因?yàn)樵撈恼麻喿x起來(lái)還是比較輕松詼諧的，當(dāng)然了，更主要的是周末的我也在充電學(xué)習(xí)，希望有追求的朋友們也盡量不要放過(guò)周末時(shí)間，適當(dāng)充電，為了走上人生巔峰，迎娶白富美。【話說(shuō)有沒(méi)有白富美介紹(o???)】

接下來(lái)，直接進(jìn)入正文。

我們都知道Java是一種面向?qū)ο缶幊獭疽簿褪荗OP】的語(yǔ)言，不得不說(shuō)面向?qū)ο缶幊淌且环N及其優(yōu)秀的設(shè)計(jì)，但是任何語(yǔ)言都無(wú)法十全十美，對(duì)于OOP語(yǔ)言來(lái)說(shuō)，當(dāng)需要為部分對(duì)象引入公共部分的時(shí)候，OOP就會(huì)引入大量的重復(fù)代碼【這些代碼我們可以稱之為橫切代碼】。而這也是Aop出現(xiàn)的原因，沒(méi)錯(cuò)，Aop就是被設(shè)計(jì)出來(lái)彌補(bǔ)OOP短板的。Aop便是將這些橫切代碼封裝到一個(gè)可重用模塊中，繼而降低模塊間的耦合度，這樣也有利于后面維護(hù)。

學(xué)過(guò)Spring的都知道，Spring內(nèi)比較核心的功能便是Ioc和Aop，Ioc的主要作用是應(yīng)用對(duì)象之間的解耦，而Aop則可以實(shí)現(xiàn)橫切代碼【如權(quán)限、日志等】與他們綁定的對(duì)象之間的解耦，舉個(gè)淺顯易懂的小栗子，在用戶調(diào)用很多接口的地方，我們都需要做權(quán)限認(rèn)證，判斷用戶是否有調(diào)用該接口的權(quán)限，如果每個(gè)接口都要自己去做類似的處理，未免有點(diǎn)sb了，也不夠裝x，因此Aop就可以派上用場(chǎng)了，將這些處理的代碼放到切片中，定義一下切片、連接點(diǎn)和通知，刷刷刷跑起來(lái)就ojbk了。

想要了解Aop，就要先理解以下幾個(gè)術(shù)語(yǔ)，如PointCut、Advice、JoinPoint。接下來(lái)盡量用白話文描述下。

PointCut【切點(diǎn)】
其實(shí)切點(diǎn)的概念很好理解，你想要去切某個(gè)東西之前總得先知道要在哪里切入是吧，切點(diǎn)格式如下：execution( com.nuofankj.springdemo.aop.Service.*(..))
可以看出來(lái)，格式使用了正常表達(dá)式來(lái)定義那個(gè)范圍內(nèi)的類、那些接口會(huì)被當(dāng)成切點(diǎn)，簡(jiǎn)單明了。

Advice
Advice行內(nèi)很多人都定義成了通知，但是我總覺(jué)得有點(diǎn)勉強(qiáng)。所謂的Advice其實(shí)就是定義了Aop何時(shí)被調(diào)用，確實(shí)有種通知的感覺(jué)，何時(shí)調(diào)用其實(shí)也不過(guò)以下幾種：

Before 在方法被調(diào)用之前調(diào)用

After 在方法完成之后調(diào)用

After-returning 在方法成功執(zhí)行之后調(diào)用

After-throwing 在方法拋出異常之后調(diào)用

Around 在被通知的方法調(diào)用之前和調(diào)用之后調(diào)用

JoinPoint【連接點(diǎn)】
JoinPoint連接點(diǎn)，其實(shí)很好理解，上面又有通知、又有切點(diǎn)，那和具體業(yè)務(wù)的連接點(diǎn)又是什么呢？沒(méi)錯(cuò)，其實(shí)就是對(duì)應(yīng)業(yè)務(wù)的方法對(duì)象，因?yàn)槲覀冊(cè)跈M切代碼中是有可能需要用到具體方法中的具體數(shù)據(jù)的，而連接點(diǎn)便可以做到這一點(diǎn)。

先給出兩個(gè)業(yè)務(wù)內(nèi)的接口，一個(gè)是聊天，一個(gè)是購(gòu)買東西


接下來(lái)該給出說(shuō)了那么久的切片了

可以從中看到PointCut【切點(diǎn)】是

execution( com.nuofankj.springdemo.aop.Service.*(..))

Advice是

Before

JoinPoint【連接點(diǎn)】是

MethodSignature signature = (MethodSignature) joinPoint.getSignature();

Method method = signature.getMethod();

代碼淺顯易懂，其實(shí)就是將ChatService和BuyService里邊給userId做權(quán)限校驗(yàn)的邏輯抽出來(lái)做成切片。

那么如何拿到具體業(yè)務(wù)方法內(nèi)的具體參數(shù)呢？
這里是定義了一個(gè)新的注解

作用可以直接看注釋，使用地方如下

可以看到對(duì)應(yīng)接口使用了AuthPermission的注解，而取出的地方在于

是的，這樣便可以取出來(lái)對(duì)應(yīng)的接口傳遞的userId具體是什么了，而校驗(yàn)邏輯可以自己處理。

送佛送到西，不對(duì)，擼碼擼整套，接下來(lái)給出運(yùn)行的主類

可以看到，上面有一個(gè)接口傳遞的userId是1，另一個(gè)是123，而上面權(quán)限認(rèn)證只有1才說(shuō)通過(guò)，否則會(huì)拋出異常。

運(yùn)行結(jié)果如下

運(yùn)行結(jié)果可想而知，1的通過(guò)驗(yàn)證，123的失敗。

首先給出Main類

可以看到我這里用的是AnnotationConfigApplicationContext，解釋下

AnnotationConfigApplicationContext是一個(gè)用來(lái)管理注解bean的容器，所以我可以用該容器取得我定義了@Service注解的類的實(shí)例。

打斷點(diǎn)后，啟動(dòng)程序，我們可以看到TestDemo的實(shí)例在idea的表現(xiàn)是這樣的

而B(niǎo)uyService的實(shí)例卻不同

我們可以從看到BuyService是SpringCGLIB強(qiáng)化過(guò)的一個(gè)實(shí)例，那么問(wèn)題來(lái)了

為什么BuyService被強(qiáng)化過(guò)而TestDemo沒(méi)有？

SpringCGLIB又是什么？

Spring是在什么時(shí)候生成一個(gè)強(qiáng)化后的實(shí)例的？

帶著這些疑問(wèn)，讓我們一步步從Spring源碼中找到答案。

為什么BuyService被強(qiáng)化過(guò)而TestDemo沒(méi)有？

這個(gè)問(wèn)題比較簡(jiǎn)單，我們可以看回上面我對(duì)切片的定義

可以從代碼中看出，我定義的切點(diǎn)是*Service命名的類，而TestDemo很明顯不符合這個(gè)設(shè)定，因此TestDemo逃過(guò)被強(qiáng)化的命運(yùn)。

SpringCGLIB又是什么？

CGLIB其實(shí)就是一種實(shí)現(xiàn)動(dòng)態(tài)代理的技術(shù)，利用了ASM開(kāi)源包，先將代理對(duì)象類的class文件加載進(jìn)來(lái)，之后通過(guò)修改其字節(jié)碼并且生成子類。結(jié)合demo來(lái)解讀便是SpringCGLIB會(huì)先將BuyService加載到內(nèi)存中，之后通過(guò)修改字節(jié)碼生成BuyService的子類，該子類便是強(qiáng)化后的BuyService，上文看到的強(qiáng)化后的實(shí)例便是該子類的實(shí)例。

Spring是在什么時(shí)候生成一個(gè)強(qiáng)化后的實(shí)例的？

這個(gè)便厲害了，首先，我們要先從Spring如何加載切片入手。

【思考Time】 為什么我會(huì)選擇從切片入手呢？原因很簡(jiǎn)單，Spring就是因?yàn)榘l(fā)現(xiàn)了切片，并且對(duì)切片進(jìn)行解析后才知道了要強(qiáng)化哪些類。

切片的處理第一步便是要加上@Aspect注解，學(xué)過(guò)注解的都知道，注解的作用更多的是標(biāo)志識(shí)別，也就是告訴Spring這個(gè)類要做相關(guān)特殊處理，因此我們可以基于該認(rèn)識(shí)，反調(diào)該注解使用的地方

可以從截圖看出，我反調(diào)了@Aspect后定位到了AbstractAspectJAdvisorFactory類中的hasAspectAnnotation函數(shù)，并且攜帶參數(shù)clazz，因此我猜測(cè)該接口就是用來(lái)識(shí)別clazz是否使用了注解@Aspect的地方，于是我打上了斷點(diǎn)，并且加了條件 clazz == AuthAspect.class ，重新啟動(dòng)后

我們看到確實(shí)被斷點(diǎn)到了，可以得出我的猜測(cè)是對(duì)的。
我們先看下斷點(diǎn)后做了什么事情，之后再看下具體是哪里進(jìn)行了掃描。在斷點(diǎn)處按F8繼續(xù)往下走，最后發(fā)現(xiàn)

沒(méi)錯(cuò)，可以看到最終是構(gòu)建成了一個(gè)Advisor對(duì)象 ，并且放入了BeanFactoryAspectJAdvisorsBuilder中的advisorsCache中，這樣意味著Spring最終會(huì)將使用了@Aspect注解的類構(gòu)建成Advisor對(duì)象后保存進(jìn)BeanFactoryAspectJAdvisorsBuilder.advisorsCache中。

接下來(lái)我們看看具體是哪里進(jìn)行了使用@Aspect注解的相關(guān)類的掃描，這次我斷點(diǎn)的地方在BeanFactoryAspectJAdvisorsBuilder中的advisorsCache調(diào)用了put的地方。

【思考Time】 為什么我會(huì)選擇在advisorsCache調(diào)用了put的地方打斷點(diǎn)呢？原因很簡(jiǎn)單，因?yàn)槲覀兩厦嬉呀?jīng)分析出@Aspect注解的類構(gòu)建成Advisor對(duì)象后保存進(jìn)BeanFactoryAspectJAdvisorsBuilder.advisorsCache中，而我通過(guò)反調(diào)知道put的地方只有一個(gè)，因此我可以斷定在此處打斷點(diǎn)可以知道到底哪里進(jìn)行了掃描的操作。

通過(guò)打斷點(diǎn)后我從idea的Frames面板中看到

沒(méi)錯(cuò)，做了掃描@Aspect注解的掃描器是AbstractAutoProxyCreator類

我們可以從中看到AbstractAutoProxyCreator最終實(shí)現(xiàn)了InstantiationAwareBeanPostProcessor接口。

【思考Time】 這個(gè)接口有什么作用呢？具體可以看我前陣子寫的一篇文章：https://mp.weixin.qq.com/s/r2...

現(xiàn)在已經(jīng)找到了掃描注解的地方，并且我們也看到了最終是生成了Advisor對(duì)象 ，并且放入了BeanFactoryAspectJAdvisorsBuilder中的advisorsCache中，那么Spring是在什么時(shí)候生成強(qiáng)化后的實(shí)例的呢？
接下來(lái)我的切入點(diǎn)是AbstractAutoProxyCreator中的postProcessAfterInitialization接口。

【思考Time】 之所以會(huì)選擇AbstractAutoProxyCreator為切入點(diǎn)，是因?yàn)橥ㄟ^(guò)命名可以看出這是SpringAop用來(lái)構(gòu)建代理[強(qiáng)化]對(duì)象的地方，并且由于SpringCGLIB是先將目標(biāo)類加載到內(nèi)存中，之后通過(guò)修改字節(jié)碼生成目標(biāo)類的子類，因此我猜測(cè)強(qiáng)化是在目標(biāo)類實(shí)例化后觸發(fā)postProcessAfterInitialization的時(shí)候進(jìn)行的。

因此我在postProcessAfterInitialization接口中做了斷點(diǎn)，并且加了調(diào)試條件。

可以看到我這里斷點(diǎn)到了ChatService這個(gè)類。

【思考Time】  為什么專門斷點(diǎn)ChatService這個(gè)類？之所以會(huì)專門定位這個(gè)類，因?yàn)槲业那忻娴哪繕?biāo)類就包含了ChatService，通過(guò)定位到該類，我們可以一步步捕捉Spring的強(qiáng)化操作。

我們可以看到，生成強(qiáng)化后的對(duì)象就藏在wrapIfNecessary中。

【思考Time】 為什么我會(huì)知道是生成強(qiáng)化后的對(duì)象就藏在wrapIfNecessary中呢？因?yàn)槲彝ㄟ^(guò)調(diào)試發(fā)現(xiàn)，在調(diào)用了wrapIfNecessary接口后，返回的對(duì)象是強(qiáng)化后的對(duì)象。

那么問(wèn)題來(lái)了，為什么Spring會(huì)知道ChatService類需要進(jìn)行進(jìn)行強(qiáng)化呢？我們可以從wrapIfNecessary中走入更深一層，通過(guò)調(diào)試，可以看到

在此處會(huì)從advisorsCache中根據(jù)aspectName取出對(duì)應(yīng)的Advisor。拿到Advisor后，便是進(jìn)行過(guò)濾的地方了，通過(guò)F8往后走，可以看到過(guò)濾的地方在AopUtils.canApply接口中。

可以看到此處傳進(jìn)來(lái)的targetClass符合切面的要求，因此可以進(jìn)行構(gòu)建強(qiáng)化對(duì)象。
接下來(lái)讓我們看下真正產(chǎn)生強(qiáng)化對(duì)象的地方了

我們可以看到在AbstractAutoProxyCreator的createProxy函數(shù)中看到，最后會(huì)構(gòu)造出一個(gè)強(qiáng)化后的chatService。
那么createProxy又做了什么呢？通過(guò)斷點(diǎn)一層層深入后，發(fā)現(xiàn)最后會(huì)到達(dá)

通過(guò)源碼分析，我們發(fā)現(xiàn)在AbstractAutoProxyCreator構(gòu)建強(qiáng)化對(duì)象的時(shí)候是調(diào)用了createAopProxy函數(shù)，重點(diǎn)來(lái)了，我們可以看到針對(duì)targetClass，也就是ChatService做了判斷，如果targetClass有實(shí)現(xiàn)接口或者targetClass是Proxy的子類，那么使用的是JDK的動(dòng)態(tài)代理實(shí)現(xiàn)AOP，如果不是才會(huì)使用CGLIB實(shí)現(xiàn)動(dòng)態(tài)代理。

那么JDK實(shí)現(xiàn)的動(dòng)態(tài)代理和CGLIB實(shí)現(xiàn)的動(dòng)態(tài)代理有什么區(qū)別嗎？
首先動(dòng)態(tài)代理可以分為兩種：JDK動(dòng)態(tài)代理和CGLIB動(dòng)態(tài)代理。從文中我們也可以看出，當(dāng)目標(biāo)類有接口的時(shí)候才會(huì)使用JDK動(dòng)態(tài)代理，其實(shí)是因?yàn)镴DK動(dòng)態(tài)代理無(wú)法代理一個(gè)沒(méi)有接口的類。JDK動(dòng)態(tài)代理是利用反射機(jī)制生成一個(gè)實(shí)現(xiàn)代理接口的匿名類，而CGLIB是針對(duì)類實(shí)現(xiàn)代理，主要是對(duì)指定的類生成一個(gè)子類，并且覆蓋其中的方法。

本來(lái)想一篇文章說(shuō)完源碼跟蹤分析Aop和Aop的實(shí)現(xiàn)機(jī)制代理模式，發(fā)現(xiàn)源碼跟蹤分析已經(jīng)很占篇幅了，因此沒(méi)辦法只能再開(kāi)一篇文章專門闡述Aop的實(shí)現(xiàn)機(jī)制代理模式，期待下篇文章。

大家都知道，我有個(gè)習(xí)慣，在動(dòng)手寫一篇文章之前會(huì)先將該文章相關(guān)的資料仔細(xì)琢磨一遍，然后再結(jié)合源碼再調(diào)試一遍，結(jié)果，說(shuō)好的

看源碼也確實(shí)是

源碼確實(shí)有進(jìn)行了是否是接口的判斷，但是問(wèn)題來(lái)了，我調(diào)試的時(shí)候發(fā)現(xiàn)無(wú)論代理類是否有接口，最終都會(huì)被強(qiáng)制使用CGLIB代理，沒(méi)辦法，只能翻看SpringBoot的相關(guān)文檔，最終發(fā)現(xiàn)原來(lái)SpringBoot從2.0開(kāi)始就默認(rèn)使用Cglib代理了，好家伙，怪不得我調(diào)試半天找不到原因。

那么如何解決呢？肯定是通過(guò)配置啦，按照如下配置即可

在application.properties文件中配置 spring.aop.proxy-target-class=false

即可。

【劃重點(diǎn)】 曾經(jīng)遇見(jiàn)過(guò)面試官問(wèn)，SpringBoot默認(rèn)代理類型是什么？看完該篇文章，我們就可以果斷的回答是Cglib代理了。通過(guò)調(diào)試代碼發(fā)現(xiàn)的規(guī)則，我想我這輩子都不會(huì)忘記這個(gè)默認(rèn)規(guī)則。

簡(jiǎn)單來(lái)說(shuō)，就是在運(yùn)行的時(shí)候?yàn)槟繕?biāo)類動(dòng)態(tài)生成代理類，而在操作的時(shí)候都是操作代理類，代理模式有個(gè)顯而易見(jiàn)的好處，那便是可以在不改變對(duì)象方法的情況下對(duì)方法進(jìn)行增強(qiáng)。試想下，我們?cè)谀惚仨氁腟pring-Aop之應(yīng)用篇有提到使用Aop來(lái)做權(quán)限認(rèn)證，如果不用Aop，那么我們就必須要為所有需要權(quán)限認(rèn)證的方法都加上權(quán)限認(rèn)證代碼，聽(tīng)起來(lái)就覺(jué)得蛋疼，你覺(jué)得對(duì)不對(duì)？

靜態(tài)代理類不是說(shuō)不可以用，如果只有一個(gè)類需要被代理，那么自然可以用，如
這是在你必須要懂的Spring-Aop之應(yīng)用篇使用的一個(gè)例子類，該類的作用只是打印出我要買東西。

代理類如下

可以看到這個(gè)BuyProxy代理類只是塞了一個(gè)IBuyServcie接口進(jìn)行，而且自身也實(shí)現(xiàn)了接口IBuyService，而在buyItem方法被調(diào)用的時(shí)候會(huì)先做自己的操作，再調(diào)用塞進(jìn)去的接口的buyItem方法。
測(cè)試類很簡(jiǎn)單，如下

運(yùn)行后很自然而然的打印出

靜態(tài)代理就是簡(jiǎn)單，但是弊端也很明顯，如果有多個(gè)類都需要同樣的代理，都實(shí)現(xiàn)了同樣的接口，那么如果使用靜態(tài)代理的話，我們就要構(gòu)造多個(gè)Proxy類，就會(huì)造成類爆炸。
而使用了Aop后，也就是動(dòng)態(tài)代理后，便可以一次性解決該問(wèn)題了，具體可以看你必須要懂的Spring-Aop之應(yīng)用篇中的操作方法。

這里給出一個(gè)JDK動(dòng)態(tài)代理的demo
首先給出一個(gè)簡(jiǎn)單的業(yè)務(wù)類，Hello類和接口

真正實(shí)現(xiàn)了類的代理功能的其實(shí)就是這個(gè)實(shí)現(xiàn)了接口InvocationHandler的JdkProxy類

我們可以看到其中必須實(shí)現(xiàn)的方法是invoke，可以看到invoke方法的參數(shù)帶有Method對(duì)象，這個(gè)就是我們的目標(biāo)Method，現(xiàn)在我們的目的就是要在這個(gè)Method在被調(diào)用前后實(shí)現(xiàn)我們的業(yè)務(wù)，可以看到在method.invoke反調(diào)前后實(shí)現(xiàn)了before和after業(yè)務(wù)。

這里再給出一個(gè)Main測(cè)試類，作用是取得Hello的代理類，然后調(diào)用其中的say方法。

運(yùn)行結(jié)果如下

原理很簡(jiǎn)單 在JdkProxyMain中hello調(diào)用say的時(shí)候，由于Hello已經(jīng)被“代理”了，所以在調(diào)用say函數(shù)的時(shí)候其實(shí)是調(diào)用JdkProxy類中的invoke函數(shù)，而在invoke函數(shù)中先是實(shí)現(xiàn)了before函數(shù)才實(shí)現(xiàn)Object result = method.invoke(target, args)，這一句其實(shí)是調(diào)用say函數(shù)，而后才實(shí)現(xiàn)after函數(shù)，于是這樣就可以不必在改動(dòng)目標(biāo)類的前提下實(shí)現(xiàn)代理了，并且不會(huì)像靜態(tài)代理那樣導(dǎo)致類爆炸。

先給出一個(gè)Cglib動(dòng)態(tài)代理的demo

核心類是實(shí)現(xiàn)了MethodInterceptor的CGlibProxy類

可以看到其中實(shí)現(xiàn)了方法intercept，先是在目標(biāo)函數(shù)被調(diào)用前實(shí)現(xiàn)自己的業(yè)務(wù)，比如before()和after()，之后再通過(guò) proxy.invokeSuper(obj, args) 觸發(fā)目標(biāo)函數(shù)。

最后給出入口類

最后給出運(yùn)行類，運(yùn)行類如下

可以看到運(yùn)行結(jié)果

原理很簡(jiǎn)單 在CglibProxyMain中hello調(diào)用say的時(shí)候，由于Hello已經(jīng)被“代理”了，所以在調(diào)用say函數(shù)的時(shí)候其實(shí)是調(diào)用CGlibProxy類中的intercept函數(shù)。