一、前言
最近在複習Spring的相關內容，剛剛大致研究了一下Spring中，AOP的實現原理。這篇部落格就來簡單地聊一聊Spring的AOP是如何實現的，並通過一個簡單的測試用例來驗證一下。廢話不多說，直接開始。
二、正文
2.1 Spring AOP的實現原理
Spring的AOP實現原理其實很簡單，就是通過動態代理實現的。如果我們為Spring的某個bean配置了切面，那麼Spring在建立這個bean的時候，實際上建立的是這個bean的一個代理物件，我們後續對bean中方法的呼叫，實際上呼叫的是代理類重寫的代理方法。而Spring的AOP使用了兩種動態代理，分別是JDK的動態代理，以及CGLib的動態代理。
（一）JDK動態代理
Spring預設使用JDK的動態代理實現AOP，類如果實現了介面，Spring就會使用這種方式實現動態代理。熟悉Java語言的應該會對JDK動態代理有所瞭解。JDK實現動態代理需要兩個元件，首先第一個就是InvocationHandler介面。我們在使用JDK的動態代理時，需要編寫一個類，去實現這個介面，然後重寫invoke方法，這個方法其實就是我們提供的代理方法。然後JDK動態代理需要使用的第二個元件就是Proxy這個類，我們可以通過這個類的newProxyInstance方法，返回一個代理物件。生成的代理類實現了原來那個類的所有介面，並對介面的方法進行了代理，我們通過代理物件呼叫這些方法時，底層將通過反射，呼叫我們實現的invoke方法。
（二）CGLib動態代理
JDK的動態代理存在限制，那就是被代理的類必須是一個實現了介面的類，代理類需要實現相同的介面，代理介面中宣告的方法。若需要代理的類沒有實現介面，此時JDK的動態代理將沒有辦法使用，於是Spring會使用CGLib的動態代理來生成代理物件。CGLib直接操作位元組碼，生成類的子類，重寫類的方法完成代理。
以上就是Spring實現動態的兩種方式，下面我們具體來談一談這兩種生成動態代理的方式。
2.2 JDK的動態代理
（一）實現原理
JDK的動態代理是基於反射實現。JDK通過反射，生成一個代理類，這個代理類實現了原來那個類的全部介面，並對介面中定義的所有方法進行了代理。當我們通過代理物件執行原來那個類的方法時，代理類底層會通過反射機制，回撥我們實現的InvocationHandler介面的invoke方法。並且這個代理類是Proxy類的子類（記住這個結論，後面測試要用）。這就是JDK動態代理大致的實現方式。
（二）優點
JDK動態代理是JDK原生的，不需要任何依賴即可使用；- 通過反射機制生成代理類的速度要比
CGLib操作位元組碼生成代理類的速度更快；
（三）缺點
- 如果要使用
JDK動態代理，被代理的類必須實現了介面，否則無法代理； JDK動態代理無法為沒有在介面中定義的方法實現代理，假設我們有一個實現了介面的類，我們為它的一個不屬於介面中的方法配置了切面，Spring仍然會使用JDK的動態代理，但是由於配置了切面的方法不屬於介面，為這個方法配置的切面將不會被織入。JDK動態代理執行代理方法時，需要通過反射機制進行回撥，此時方法執行的效率比較低；
2.3 CGLib動態代理
（一）實現原理
CGLib實現動態代理的原理是，底層採用了ASM位元組碼生成框架，直接對需要代理的類的位元組碼進行操作，生成這個類的一個子類，並重寫了類的所有可以重寫的方法，在重寫的過程中，將我們定義的額外的邏輯（簡單理解為Spring中的切面）織入到方法中，對方法進行了增強。而通過位元組碼操作生成的代理類，和我們自己編寫並編譯後的類沒有太大區別。
（二）優點
- 使用
CGLib代理的類，不需要實現介面，因為CGLib生成的代理類是直接繼承自需要被代理的類； CGLib生成的代理類是原來那個類的子類，這就意味著這個代理類可以為原來那個類中，所有能夠被子類重寫的方法進行代理；CGLib生成的代理類，和我們自己編寫並編譯的類沒有太大區別，對方法的呼叫和直接呼叫普通類的方式一致，所以CGLib執行代理方法的效率要高於JDK的動態代理；
（三）缺點
- 由於
CGLib的代理類使用的是繼承，這也就意味著如果需要被代理的類是一個final類，則無法使用CGLib代理； - 由於
CGLib實現代理方法的方式是重寫父類的方法，所以無法對final方法，或者private方法進行代理，因為子類無法重寫這些方法； CGLib生成代理類的方式是通過操作位元組碼，這種方式生成代理類的速度要比JDK通過反射生成代理類的速度更慢；
2.4 通過程式碼進行測試
（一）測試JDK動態代理
下面我們通過一個簡單的例子，來驗證上面的說法。首先我們需要一個介面和它的一個實現類，然後再為這個實現類的方法配置切面，看看Spring是否真的使用的是JDK的動態代理。假設介面的名稱為Human，而實現類為Student：
public interface Human {
void display();
}
@Component
public class Student implements Human {
@Override
public void display() {
System.out.println("I am a student");
}
}
然後我們定義一個切面，將這個display方法作為切入點，為它配置一個前置通知，程式碼如下：
@Aspect
@Component
public class HumanAspect {
// 為Student這個類的所有方法，配置這個前置通知
@Before("execution(* cn.tewuyiang.pojo.Student.*(..))")
public void before() {
System.out.println("before student");
}
}
下面可以開始測試了，我們通過Java類的方式進行配置，然後編寫一個單元測試方法：
// 配置類
@Configuration
@ComponentScan(basePackages = "cn.tewuyiang")
@EnableAspectJAutoProxy
public class AOPConfig {
}
// 測試方法
@Test
public void testProxy() {
ApplicationContext context =
new AnnotationConfigApplicationContext(AOPConfig.class);
// 注意，這裡只能通過Human.class獲取，而無法通過Student.class，因為在Spirng容器中，
// 因為使用JDK動態代理，Ioc容器中，儲存的是一個型別為Human的代理物件
Human human = context.getBean(Human.class);
human.display();
// 輸出代理類的父類，以此判斷是JDK還是CGLib
System.out.println(human.getClass().getSuperclass());
}
注意看上面程式碼中，最長的那一句註釋。由於我們需要代理的類實現了介面，則Spring會使用JDK的動態代理，生成的代理類會實現相同的介面，然後建立一個代理物件儲存在Spring容器中。這也就是說，在Spring容器中，這個代理bean的型別不是Student型別，而是Human型別，所以我們不能通過Student.class獲取，只能通過Human.class（或者通過它的名稱獲取）。這也證明了我們上面說過的另一個問題，JDK動態代理無法代理沒有定義在介面中的方法。假設Student這個類有另外一個方法，它不是Human介面定義的方法，此時就算我們為它配置了切面，也無法將切面織入。而且由於在Spring容器中儲存的代理物件並不是Student型別，而是Human型別，這就導致我們連那個不屬於Human的方法都無法呼叫。這也說明了JDK動態代理的侷限性。
我們前面說過，JDK動態代理生成的代理類繼承了Proxy這個類，而CGLib生成的代理類，則繼承了需要進行代理的那個類，於是我們可以通過輸出代理物件所屬類的父類，來判斷Spring使用了何種代理。下面是輸出結果：
before student
I am a student
class java.lang.reflect.Proxy // 注意看，父類是Proxy
通過上面的輸出結果，我們發現，代理類的父類是Proxy，也就意味著果然使用的是JDK的動態代理。
（二）測試CGLib動態代理
好，測試完JDK動態代理，我們開始測試CGLib動態代理。我們前面說過，只有當需要代理的類沒有實現介面時，Spring才會使用CGLib動態代理，於是我們修改Student這個類的定義，不讓他實現介面：
@Component
public class Student {
public void display() {
System.out.println("I am a student");
}
}
由於Student沒有實現介面，所以我們的測試方法也需要做一些修改。之前我們是通過Human.class這個型別從Spring容器中獲取代理物件，但是現在，由於沒有實現介面，所以我們不能再這麼寫了，而是要寫成Student.class，如下：
@Test
public void testProxy() {
ApplicationContext context =
new AnnotationConfigApplicationContext(AOPConfig.class);
// 修改為Student.class
Student student = context.getBean(Student.class);
student.display();
// 同樣輸出父類
System.out.println(student.getClass().getSuperclass());
}
因為CGLib動態代理是生成了Student的一個子類，所以這個代理物件也是Student型別（子類也是父類型別），所以可以通過Student.class獲取。下面是輸出結果：
before student
I am a student
class cn.tewuyiang.pojo.Student // 此時，父類是Student
可以看到，AOP成功生效，並且代理物件所屬類的父類是Student，驗證了我們之前的說法。下面我們修改一下Student類的定義，將display方法加上final修飾符，再看看效果：
@Component
public class Student {
// 加上final修飾符
public final void display() {
System.out.println("I am a student");
}
}
// 輸出結果如下：
I am a student
class cn.tewuyiang.pojo.Student
可以看到，輸出的父類仍然是Student，也就是說Spring依然使用了CGLib生成代理。但是我們發現，我們為display方法配置的前置通知並沒有執行，也就是代理類並沒有為display方法進行代理。這也驗證了我們之前的說法，CGLib無法代理final方法，因為子類無法重寫父類的final方法。下面我們可以試著為Student類加上final修飾符，讓他無法被繼承，此時看看結果。執行的結果會丟擲異常，因為無法生成代理類，這裡就不貼出來了，可以自己去試試。
2.5 強制Spring使用CGLib
通過上面的測試我們會發現，CGLib的動態代理好像更加強大，而JDK的動態代理卻限制頗多。而且前面也提過，CGLib的代理物件，執行代理方法的速度更快，只是生成代理類的效率較低。但是我們使用到的bean大部分都是單例的，並不需要頻繁建立代理類，也就是說CGLib應該會更合適。但是為什麼Spring預設使用JDK呢？這我也不太清楚，網上也沒有找到相關的描述（如果有人知道，麻煩告訴我）。但是據說SpringBoot現在已經預設使用CGLib作為AOP的實現了。
那我們可以強制Spring使用CGLib，而不使用JDK的動態代理嗎？答案當然是可以的。我們知道，如果要使用註解（@Aspect）方式配置切面，則需要在xml檔案中配置下面一行開啟AOP：
<aop:aspectj-autoproxy />
如果我們希望只使用CGLib實現AOP，則可以在上面的這一行加點東西：
<!-- 將proxy-target-class配置設定為true -->
<aop:aspectj-autoproxy proxy-target-class="true"/>
當然，如果我們是使用Java類進行配置，比如說我們上面用到的AOPConfig這個類，如果是通過這種方式配置，則強制使用CGLib的方式如下：
@Configuration
@ComponentScan(basePackages = "cn.tewuyiang")
// 如下：@EnableAspectJAutoProxy開啟AOP，
// 而proxyTargetClass = true就是強制使用CGLib
@EnableAspectJAutoProxy(proxyTargetClass = true)
public class AOPConfig {
}
如果我們是在xml檔案中配置切面，則可以通過以下方式來強制使用CGLib：
<!-- aop:config用來在xml中配置切面，指定proxy-target-class="true" -->
<aop:config proxy-target-class="true">
<!-- 在其中配置AOP -->
</aop:config>
三、總結
上面我們就對Spring中AOP的實現原理做了一個大致的介紹。歸根到底，Spring AOP的實現是通過動態代理，並且有兩種實現方式，分別是JDK動態代理和CGLib動態代理。Spring預設使用JDK動態代理，只有在類沒有實現介面時，才會使用CGLib。
上面的內容若存在錯誤或者不足，歡迎指正或補充。也希望這篇部落格對需要了解Spring AOP的人有所幫助。