淺析Spring中AOP的實作原理——動态代理

淺析Spring中AOP的實作原理——動态代理

1|0一、前言

最近在複習Spring的相關内容，剛剛大緻研究了一下Spring中，AOP的實作原理。這篇部落格就來簡單地聊一聊Spring的AOP是如何實作的，并通過一個簡單的測試用例來驗證一下。廢話不多說，直接開始。

2|0二、正文

2|12.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|22.2 JDK的動态代理

（一）實作原理

JDK的動态代理是基于反射實作。JDK通過反射，生成一個代理類，這個代理類實作了原來那個類的全部接口，并對接口中定義的所有方法進行了代理。當我們通過代理對象執行原來那個類的方法時，代理類底層會通過反射機制，回調我們實作的InvocationHandler接口的invoke方法。并且這個代理類是Proxy類的子類（記住這個結論，後面測試要用）。這就是JDK動态代理大緻的實作方式。

（二）優點

JDK動态代理是JDK原生的，不需要任何依賴即可使用；

通過反射機制生成代理類的速度要比CGLib操作位元組碼生成代理類的速度更快；

（三）缺點

如果要使用JDK動态代理，被代理的類必須實作了接口，否則無法代理；

JDK動态代理無法為沒有在接口中定義的方法實作代理，假設我們有一個實作了接口的類，我們為它的一個不屬于接口中的方法配置了切面，Spring仍然會使用JDK的動态代理，但是由于配置了切面的方法不屬于接口，為這個方法配置的切面将不會被織入。

JDK動态代理執行代理方法時，需要通過反射機制進行回調，此時方法執行的效率比較低；

2|32.3 CGLib動态代理

CGLib實作動态代理的原理是，底層采用了ASM位元組碼生成架構，直接對需要代理的類的位元組碼進行操作，生成這個類的一個子類，并重寫了類的所有可以重寫的方法，在重寫的過程中，将我們定義的額外的邏輯（簡單了解為Spring中的切面）織入到方法中，對方法進行了增強。而通過位元組碼操作生成的代理類，和我們自己編寫并編譯後的類沒有太大差別。

使用CGLib代理的類，不需要實作接口，因為CGLib生成的代理類是直接繼承自需要被代理的類；

CGLib生成的代理類是原來那個類的子類，這就意味着這個代理類可以為原來那個類中，所有能夠被子類重寫的方法進行代理；

CGLib生成的代理類，和我們自己編寫并編譯的類沒有太大差別，對方法的調用和直接調用普通類的方式一緻，是以CGLib執行代理方法的效率要高于JDK的動态代理；

由于CGLib的代理類使用的是繼承，這也就意味着如果需要被代理的類是一個final類，則無法使用CGLib代理；

由于CGLib實作代理方法的方式是重寫父類的方法，是以無法對final方法，或者private方法進行代理，因為子類無法重寫這些方法；

CGLib生成代理類的方式是通過操作位元組碼，這種方式生成代理類的速度要比JDK通過反射生成代理類的速度更慢；

2|42.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擷取。下面是輸出結果：

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|52.5 強制Spring使用CGLib

通過上面的測試我們會發現，CGLib的動态代理好像更加強大，而JDK的動态代理卻限制頗多。而且前面也提過，CGLib的代理對象，執行代理方法的速度更快，隻是生成代理類的效率較低。但是我們使用到的bean大部分都是單例的，并不需要頻繁建立代理類，也就是說CGLib應該會更合适。但是為什麼Spring預設使用JDK呢？這我也不太清楚，網上也沒有找到相關的描述（如果有人知道，麻煩告訴我）。但是據說SpringBoot現在已經預設使用CGLib作為AOP的實作了。

那我們可以強制Spring使用CGLib，而不使用JDK的動态代理嗎？答案當然是可以的。我們知道，如果要使用注解（@Aspect）方式配置切面，則需要在xml檔案中配置下面一行開啟AOP：

如果我們希望隻使用CGLib實作AOP，則可以在上面的這一行加點東西：

當然，如果我們是使用Java類進行配置，比如說我們上面用到的AOPConfig這個類，如果是通過這種方式配置，則強制使用CGLib的方式如下：

@Configuration @ComponentScan(basePackages = "cn.tewuyiang") // 如下：@EnableAspectJAutoProxy開啟AOP， // 而proxyTargetClass = true就是強制使用CGLib @EnableAspectJAutoProxy(proxyTargetClass = true) public class AOPConfig { }

如果我們是在xml檔案中配置切面，則可以通過以下方式來強制使用CGLib：

3|0三、總結

上面我們就對Spring中AOP的實作原理做了一個大緻的介紹。歸根到底，Spring AOP的實作是通過動态代理，并且有兩種實作方式，分别是JDK動态代理和CGLib動态代理。Spring預設使用JDK動态代理，隻有在類沒有實作接口時，才會使用CGLib。

上面的内容若存在錯誤或者不足，歡迎指正或補充。也希望這篇部落格對需要了解Spring AOP的人有所幫助。

4|0四、參考

Spring-4.3.21官方文檔——AOP

https://blog.csdn.net/xlgen157387/article/details/82497594

EOF

本文作者：特務依昂

本文連結：

https://www.cnblogs.com/tuyang1129/p/12878549.html