摘要?jiǎng)討B(tài)代理是 Java 生態(tài)中最核心的底層技術(shù)之一Spring AOP、MyBatis Mapper、RPC 框架、服務(wù)治理等都建立在它之上。Java 中實(shí)現(xiàn)動(dòng)態(tài)代理主要有兩種方式基于接口的 JDK 動(dòng)態(tài)代理以及基于繼承的 CGLIB 動(dòng)態(tài)代理。本文從代理模式出發(fā)系統(tǒng)深入地剖析 JDK 動(dòng)態(tài)代理與 CGLIB 的工作原理、底層源碼機(jī)制、類結(jié)構(gòu)差異、性能表現(xiàn)、適用場(chǎng)景及其各自的優(yōu)缺點(diǎn)并給出完整的代碼示例、運(yùn)行分析、反編譯演示、框架應(yīng)用案例和面試高頻考點(diǎn)力求幫助讀者從原理到實(shí)戰(zhàn)全面掌握動(dòng)態(tài)代理技術(shù)。1. 為什么需要?jiǎng)討B(tài)代理在理解 JDK 動(dòng)態(tài)代理和 CGLIB 之前必須首先回答一個(gè)根本性問題為什么需要?jiǎng)討B(tài)代理這個(gè)問題看似簡(jiǎn)單卻直接決定了后續(xù)技術(shù)選型的邏輯和深度。如果不能理解動(dòng)態(tài)代理要解決的痛點(diǎn)后續(xù)的源碼分析和性能對(duì)比也就失去了意義。在傳統(tǒng)軟件開發(fā)中我們經(jīng)常面臨這樣的需求在不修改原始類代碼的前提下為某個(gè)類的某些方法增加額外邏輯比如日志記錄、性能統(tǒng)計(jì)、事務(wù)管理、權(quán)限校驗(yàn)、緩存處理、異常統(tǒng)一處理等。這類邏輯橫切在多個(gè)業(yè)務(wù)方法之間如果直接寫在業(yè)務(wù)代碼里會(huì)導(dǎo)致大量重復(fù)代碼同時(shí)使業(yè)務(wù)邏輯與橫切關(guān)注點(diǎn)嚴(yán)重耦合。一旦日志格式、事務(wù)策略或權(quán)限規(guī)則發(fā)生變化開發(fā)人員就不得不在大量業(yè)務(wù)類中逐一修改極易遺漏和出錯(cuò)。1.1 靜態(tài)代理的基本思路最直觀的解決方案是靜態(tài)代理。所謂靜態(tài)代理就是開發(fā)人員手工編寫一個(gè)代理類讓代理類實(shí)現(xiàn)與目標(biāo)類相同的接口或者繼承目標(biāo)類然后在代理類中調(diào)用目標(biāo)對(duì)象的方法并在調(diào)用前后加入額外邏輯。下面是一個(gè)典型示例javapublic interface UserService { void save(String name); User findById(Long id); } public class UserServiceImpl implements UserService { Override public void save(String name) { System.out.println(保存用戶 name); } Override public User findById(Long id) { System.out.println(查詢用戶 id); return new User(id, 張三); } } public class UserServiceProxy implements UserService { private final UserService target; public UserServiceProxy(UserService target) { this.target target; } Override public void save(String name) { System.out.println(開始記錄日志); try { target.save(name); System.out.println(保存成功); } catch (Exception e) { System.out.println(保存失敗 e.getMessage()); throw e; } finally { System.out.println(結(jié)束記錄日志); } } Override public User findById(Long id) { System.out.println(開始記錄日志); try { User user target.findById(id); System.out.println(查詢成功); return user; } catch (Exception e) { System.out.println(查詢失敗 e.getMessage()); throw e; } finally { System.out.println(結(jié)束記錄日志); } } }1.2 靜態(tài)代理的局限與動(dòng)態(tài)代理的價(jià)值靜態(tài)代理的優(yōu)點(diǎn)是直觀、容易理解、便于調(diào)試。但它的局限性也極其明顯代碼重復(fù)嚴(yán)重當(dāng)一個(gè)接口有幾十個(gè)方法時(shí)代理類中的日志、事務(wù)等邏輯會(huì)在每個(gè)方法中重復(fù)出現(xiàn)代理類代碼會(huì)非常冗長(zhǎng)。維護(hù)成本高如果系統(tǒng)中有幾百個(gè)類都需要加日志就要手工編寫幾百個(gè)代理類工作量大且極易出錯(cuò)?？蓴U(kuò)展性差當(dāng)接口新增方法時(shí)目標(biāo)類和代理類都要同步修改。任何遺漏都可能導(dǎo)致代理失效或運(yùn)行時(shí)錯(cuò)誤。代理邏輯分散相同的橫切邏輯分散在不同代理類中難以統(tǒng)一管理和升級(jí)。動(dòng)態(tài)代理正是為了解決這些問題而誕生。它允許開發(fā)人員在運(yùn)行時(shí)動(dòng)態(tài)生成代理類無(wú)需手工編寫代理類源碼。代理類由虛擬機(jī)在運(yùn)行期自動(dòng)創(chuàng)建并加載同一套代理邏輯可以應(yīng)用到任意數(shù)量的類上從而極大減少重復(fù)代碼使橫切關(guān)注點(diǎn)的管理變得集中、靈活、可復(fù)用。Java 生態(tài)中動(dòng)態(tài)代理的實(shí)現(xiàn)方式主要有兩種JDK 動(dòng)態(tài)代理從 JDK 1.3 開始引入位于java.lang.reflect包中要求目標(biāo)類必須實(shí)現(xiàn)接口代理類與目標(biāo)類實(shí)現(xiàn)相同接口以接口為契約進(jìn)行方法攔截。CGLIB 動(dòng)態(tài)代理CGLIBCode Generation Library是強(qiáng)大的字節(jié)碼生成庫(kù)通過繼承目標(biāo)類并在子類中攔截方法調(diào)用來(lái)實(shí)現(xiàn)代理不要求目標(biāo)類實(shí)現(xiàn)接口。兩者各有優(yōu)劣。真正理解它們的原理、差異和適用場(chǎng)景是深入掌握 Spring、MyBatis、Dubbo 等框架的基礎(chǔ)。下面將按“理論準(zhǔn)備 → JDK 原理 → CGLIB 原理 → 對(duì)比分析 → 框架應(yīng)用 → 面試解析”的順序逐步展開。2. 代理模式的理論基礎(chǔ)動(dòng)態(tài)代理是代理模式的一種高級(jí)實(shí)現(xiàn)形態(tài)。要真正理解動(dòng)態(tài)代理必須先把代理模式本身弄清楚因?yàn)閯?dòng)態(tài)代理只是把代理模式中“手工編寫代理類”這一環(huán)節(jié)自動(dòng)化了。2.1 代理模式的定義代理模式Proxy Pattern是 GoF 設(shè)計(jì)模式中的一種結(jié)構(gòu)型模式。其定義是為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問。通俗地說代理對(duì)象就像目標(biāo)對(duì)象的替身客戶端通過代理對(duì)象間接訪問目標(biāo)對(duì)象代理對(duì)象可以在訪問前后做額外處理也可以決定是否真正調(diào)用目標(biāo)對(duì)象。代理模式的核心角色有三個(gè)抽象主題Subject定義目標(biāo)對(duì)象和代理對(duì)象共同遵循的接口客戶端面向這個(gè)抽象主題編程。真實(shí)主題RealSubject實(shí)現(xiàn)抽象主題接口承載真正的業(yè)務(wù)邏輯也就是被代理的目標(biāo)對(duì)象。代理主題Proxy同樣實(shí)現(xiàn)抽象主題接口內(nèi)部持有真實(shí)主題引用在調(diào)用真實(shí)主題方法前后增加額外邏輯。代理模式的類圖關(guān)系可以表達(dá)為客戶端依賴 Subject 接口RealSubject 與 Proxy 都實(shí)現(xiàn) Subject 接口Proxy 內(nèi)部聚合 RealSubject 并在調(diào)用前后插入控制邏輯。2.2 代理模式的常見類型根據(jù)代理用途不同代理模式通常分為以下幾類遠(yuǎn)程代理為位于不同地址空間的對(duì)象提供本地代表封裝網(wǎng)絡(luò)通信細(xì)節(jié)讓調(diào)用者感覺像在調(diào)用本地對(duì)象。RMI、各類 RPC 框架是典型代表。虛擬代理延遲加載開銷較大的對(duì)象在真正需要使用時(shí)才創(chuàng)建或初始化。例如大型圖片、復(fù)雜報(bào)表的懶加載。保護(hù)代理控制對(duì)目標(biāo)對(duì)象的訪問權(quán)限根據(jù)調(diào)用者身份決定是否放行。例如權(quán)限校驗(yàn)組件。緩存代理在代理中緩存目標(biāo)方法返回結(jié)果避免重復(fù)執(zhí)行昂貴計(jì)算或重復(fù)查詢數(shù)據(jù)庫(kù)。智能引用代理在訪問對(duì)象時(shí)附加額外動(dòng)作如引用計(jì)數(shù)、日志記錄、資源釋放等。這些不同類型本質(zhì)上都是通過在代理對(duì)象中包裝目標(biāo)對(duì)象并在調(diào)用鏈路上加入自定義邏輯實(shí)現(xiàn)的。動(dòng)態(tài)代理的意義在于它將“代理類的生成”從編譯期推遲到運(yùn)行期使開發(fā)人員不必為每一種代理場(chǎng)景手寫代理類。2.3 靜態(tài)代理與動(dòng)態(tài)代理的本質(zhì)區(qū)別靜態(tài)代理的處理邏輯在編譯前就已確定開發(fā)人員明確知道要代理哪個(gè)類、要添加什么邏輯。動(dòng)態(tài)代理則不同它在運(yùn)行期才能確定目標(biāo)對(duì)象和代理邏輯帶來(lái)了巨大靈活性但代價(jià)是引入反射或字節(jié)碼操作帶來(lái)一定性能開銷和實(shí)現(xiàn)復(fù)雜度。從實(shí)現(xiàn)層面看兩者的根本區(qū)別在于靜態(tài)代理類由程序員編寫動(dòng)態(tài)代理類由框架或 JDK 在運(yùn)行期生成。正是這種生成時(shí)機(jī)與生成方式的差異決定了兩種代理方式的適用場(chǎng)景和優(yōu)缺點(diǎn)。后面的分析將圍繞“生成什么、如何生成、調(diào)用如何分發(fā)、有什么限制”四個(gè)問題逐層展開。3. JDK 動(dòng)態(tài)代理深入剖析3.1 JDK 動(dòng)態(tài)代理的定位與核心思想JDK 動(dòng)態(tài)代理是 Java 標(biāo)準(zhǔn)庫(kù)提供的動(dòng)態(tài)代理實(shí)現(xiàn)從 JDK 1.3 版本引入位于java.lang.reflect包中核心類包括Proxy和InvocationHandler。它的最大特點(diǎn)是基于接口進(jìn)行代理被代理的目標(biāo)類必須實(shí)現(xiàn)至少一個(gè)接口。JDK 動(dòng)態(tài)代理在運(yùn)行期動(dòng)態(tài)生成一個(gè)代理類的字節(jié)碼這個(gè)代理類實(shí)現(xiàn)目標(biāo)對(duì)象所實(shí)現(xiàn)的所有接口。代理類中的每個(gè)接口方法在被調(diào)用時(shí)都會(huì)把方法調(diào)用分發(fā)給統(tǒng)一的InvocationHandler處理器由該處理器統(tǒng)一執(zhí)行附加邏輯再通過反射調(diào)用目標(biāo)對(duì)象的對(duì)應(yīng)方法。其設(shè)計(jì)思想是把所有接口方法的調(diào)用匯聚到InvocationHandler.invoke一個(gè)入口中從而實(shí)現(xiàn)橫切邏輯的集中管理。開發(fā)人員只需實(shí)現(xiàn)一次InvocationHandler即可代理任意實(shí)現(xiàn)了接口的目標(biāo)對(duì)象。3.2 核心 API 介紹JDK 動(dòng)態(tài)代理主要涉及三個(gè)要素java.lang.reflect.Proxy代理類工廠類提供newProxyInstance靜態(tài)方法創(chuàng)建代理實(shí)例。java.lang.reflect.InvocationHandler調(diào)用處理器接口只有一個(gè)invoke方法代理對(duì)象的所有方法調(diào)用都會(huì)被轉(zhuǎn)發(fā)到這里。目標(biāo)接口被代理對(duì)象實(shí)現(xiàn)的接口代理類會(huì)實(shí)現(xiàn)這些接口。Proxy.newProxyInstance方法簽名如下javapublic static Object newProxyInstance(ClassLoader loader, Class?[] interfaces, InvocationHandler h) throws IllegalArgumentException其中l(wèi)oader是類加載器用于加載動(dòng)態(tài)生成的代理類interfaces是要代理的接口數(shù)組h是調(diào)用處理器所有方法調(diào)用都會(huì)進(jìn)入它的invoke方法。3.3 一個(gè)完整的 JDK 動(dòng)態(tài)代理示例下面給出完整示例演示如何用 JDK 動(dòng)態(tài)代理為UserService添加日志與耗時(shí)統(tǒng)計(jì)。第一步定義目標(biāo)接口和實(shí)現(xiàn)類javapublic interface UserService { void save(String name); User findById(Long id); } public class UserServiceImpl implements UserService { Override public void save(String name) { System.out.println(業(yè)務(wù)邏輯保存用戶 name); } Override public User findById(Long id) { System.out.println(業(yè)務(wù)邏輯查詢用戶 id); return new User(id, 張三); } }第二步編寫調(diào)用處理器javaimport java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; public class LogInvocationHandler implements InvocationHandler { private final Object target; public LogInvocationHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println(【日志】開始調(diào)用方法 method.getName()); long start System.currentTimeMillis(); try { Object result method.invoke(target, args); return result; } finally { long cost System.currentTimeMillis() - start; System.out.println(【日志】方法 method.getName() 執(zhí)行完成耗時(shí) cost ms); } } }第三步創(chuàng)建代理對(duì)象并使用javaimport java.lang.reflect.Proxy; public class JdkProxyDemo { public static void main(String[] args) { UserService target new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), new LogInvocationHandler(target) ); proxy.save(李四); User user proxy.findById(1L); System.out.println(查詢結(jié)果 user.getName()); } }運(yùn)行后可以看到業(yè)務(wù)方法執(zhí)行前后都自動(dòng)加入了日志和耗時(shí)統(tǒng)計(jì)而UserServiceImpl本身沒有任何修改。3.4 JDK 動(dòng)態(tài)代理的底層工作流程當(dāng)調(diào)用Proxy.newProxyInstance時(shí)內(nèi)部大致經(jīng)歷以下流程參數(shù)校驗(yàn)檢查interfaces是否合法包括數(shù)組是否為空、接口是否可被類加載器訪問、是否存在重復(fù)接口等。查找或生成代理類先檢查代理類緩存看是否為“同一接口組合與類加載器”生成過代理類。緩存命中則復(fù)用未命中則通過ProxyGenerator生成代理類字節(jié)碼。加載代理類使用傳入的ClassLoader將字節(jié)碼加載到 JVM 中得到代理類的Class對(duì)象。創(chuàng)建代理實(shí)例反射獲取代理類中以InvocationHandler為參數(shù)的構(gòu)造方法并調(diào)用創(chuàng)建代理對(duì)象實(shí)例。生成的代理類結(jié)構(gòu)大致如下下面給出簡(jiǎn)化示意代碼javapublic final class $Proxy0 extends Proxy implements UserService { private static Method m0; // hashCode private static Method m1; // equals private static Method m2; // toString private static Method m3; // save private static Method m4; // findById public $Proxy0(InvocationHandler handler) { super(handler); } Override public final void save(String name) { try { super.h.invoke(this, m3, new Object[]{name}); } catch (Throwable e) { throw new RuntimeException(e); } } Override public final User findById(Long id) { try { return (User) super.h.invoke(this, m4, new Object[]{id}); } catch (Throwable e) { throw new RuntimeException(e); } } }從示意代碼可見$Proxy0繼承了Proxy類并實(shí)現(xiàn)了UserService接口。每個(gè)接口方法都打包Method對(duì)象和參數(shù)統(tǒng)一交給InvocationHandler.invoke處理。由于 Java 是單繼承代理類已經(jīng)繼承了Proxy因此 JDK 動(dòng)態(tài)代理只能代理接口無(wú)法代理普通類這是它的根本性限制。3.5 InvocationHandler 的 invoke 方法詳解InvocationHandler接口只有一個(gè)方法javaObject invoke(Object proxy, Method method, Object[] args) throws Throwable;三個(gè)參數(shù)的含義如下proxy當(dāng)前代理對(duì)象。特別需要注意的是如果在invoke內(nèi)部再次調(diào)用proxy上的方法會(huì)觸發(fā)無(wú)限遞歸因?yàn)槊看握{(diào)用都會(huì)再次進(jìn)入invoke。真正的目標(biāo)對(duì)象需要開發(fā)人員自己保存并調(diào)用。method當(dāng)前被調(diào)用方法對(duì)應(yīng)的Method對(duì)象可獲取方法名、參數(shù)類型、返回類型、注解等信息。args調(diào)用方法的實(shí)際參數(shù)數(shù)組無(wú)參時(shí)為null。在invoke中可自由編排邏輯調(diào)用前做權(quán)限檢查、參數(shù)校驗(yàn)調(diào)用后處理返回值、記錄日志過程中捕獲異常統(tǒng)一處理甚至可以完全攔截而不調(diào)用目標(biāo)方法。對(duì)于Object的hashCode、equals、toString代理類也會(huì)轉(zhuǎn)發(fā)到invoke編寫時(shí)通常對(duì)它們直接放行。3.6 查看 JDK 生成的代理類字節(jié)碼理解 JDK 動(dòng)態(tài)代理的直觀方法是把生成的代理類字節(jié)碼導(dǎo)出并反編譯?？梢酝ㄟ^系統(tǒng)屬性sun.misc.ProxyGenerator.saveGeneratedFiles實(shí)現(xiàn)javapublic class SaveProxyClassDemo { public static void main(String[] args) { System.setProperty(sun.misc.ProxyGenerator.saveGeneratedFiles, true); UserService target new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), new LogInvocationHandler(target) ); proxy.save(測(cè)試); } }在 JDK 8 中該屬性有效生成的 class 文件保存在當(dāng)前工作目錄對(duì)應(yīng)包路徑下。反編譯后可以直觀看到代理類的繼承結(jié)構(gòu)、方法實(shí)現(xiàn)、靜態(tài) Method 字段初始化邏輯。JDK 9 之后由于模塊化限制該屬性可能失效可改用-Djdk.proxy.ProxyGenerator.saveGeneratedFilestrue或使用 Arthas、HSDB 等工具查看。3.7 JDK 動(dòng)態(tài)代理的優(yōu)缺點(diǎn)優(yōu)點(diǎn)JDK 原生支持屬于 Java 標(biāo)準(zhǔn)庫(kù)無(wú)需引入第三方依賴穩(wěn)定性和兼容性有官方保障。接口契約清晰代理類與目標(biāo)類實(shí)現(xiàn)相同接口客戶端可完全面向接口編程符合依賴倒置原則。生成效率高代理類基于接口生成生成邏輯相對(duì)簡(jiǎn)單類結(jié)構(gòu)不復(fù)雜。適合面向接口編程的框架Spring AOP 默認(rèn)對(duì)接口代理使用 JDK 動(dòng)態(tài)代理MyBatis Mapper 接口也依賴它。缺點(diǎn)只能代理接口目標(biāo)類必須實(shí)現(xiàn)接口無(wú)法代理沒有接口的普通類這是最根本的限制。反射調(diào)用開銷方法調(diào)用通過Method.invoke完成雖然 JDK 持續(xù)優(yōu)化但在極端高頻場(chǎng)景下仍有一定開銷。調(diào)試相對(duì)復(fù)雜代理類動(dòng)態(tài)生成運(yùn)行時(shí)類名形如$Proxy0出現(xiàn)問題時(shí)排查難度略高。對(duì) Object 方法處理需謹(jǐn)慎hashCode、equals、toString也會(huì)進(jìn)入invoke需要妥善處理否則可能引發(fā)意外行為。4. CGLIB 動(dòng)態(tài)代理深入剖析4.1 CGLIB 的定位與核心思想CGLIBCode Generation Library是一個(gè)強(qiáng)大的、高性能的字節(jié)碼生成庫(kù)它通過 ASM 框架在運(yùn)行期動(dòng)態(tài)生成目標(biāo)類的子類并在子類中覆蓋目標(biāo)類的方法從而在方法調(diào)用前后插入增強(qiáng)邏輯。與 JDK 動(dòng)態(tài)代理不同CGLIB 不要求目標(biāo)類實(shí)現(xiàn)接口因此可以代理普通類。CGLIB 的核心思想是繼承代理類繼承目標(biāo)類成為目標(biāo)類的子類然后重寫父類中需要被代理的方法。在重寫方法中先調(diào)用方法攔截器MethodInterceptor.intercept再由攔截器決定是否調(diào)用父類方法、如何增強(qiáng)。這樣客戶端調(diào)用代理類的方法時(shí)實(shí)際進(jìn)入的是子類的重寫方法從而被攔截器捕獲。4.2 CGLIB 的核心 APICGLIB 主要涉及以下幾個(gè)核心接口和類EnhancerCGLIB 的核心類用于生成代理類。通過設(shè)置父類、回調(diào)等參數(shù)調(diào)用create()方法生成代理實(shí)例。MethodInterceptor方法攔截器接口只有一個(gè)intercept方法。所有被代理的方法調(diào)用都會(huì)進(jìn)入這個(gè)方法開發(fā)人員在這里編寫增強(qiáng)邏輯。MethodProxy方法代理對(duì)象提供invokeSuper方法用于調(diào)用父類即目標(biāo)類的原始方法。它是 CGLIB 高性能的關(guān)鍵避免了反射調(diào)用。Callback回調(diào)接口的頂層接口MethodInterceptor是它的子接口。CGLIB 還提供了FixedValue、NoOp、LazyLoader等多種回調(diào)類型。MethodInterceptor接口定義如下javapublic interface MethodInterceptor extends Callback { Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable; }四個(gè)參數(shù)的含義obj代理對(duì)象本身即 CGLIB 生成的子類實(shí)例。method被調(diào)用的方法對(duì)應(yīng)的Method對(duì)象。args調(diào)用方法的實(shí)際參數(shù)數(shù)組。proxy方法代理對(duì)象用于調(diào)用父類的原始方法。4.3 一個(gè)完整的 CGLIB 動(dòng)態(tài)代理示例第一步引入 CGLIB 依賴。在 Maven 項(xiàng)目中添加xmldependency groupIdcglib/groupId artifactIdcglib/artifactId version3.3.0/version /dependency如果使用 Spring 框架Spring 已經(jīng)內(nèi)置了重新打包的 CGLIB無(wú)需單獨(dú)引入。第二步定義目標(biāo)類無(wú)需實(shí)現(xiàn)接口javapublic class UserService { public void save(String name) { System.out.println(業(yè)務(wù)邏輯保存用戶 name); } public User findById(Long id) { System.out.println(業(yè)務(wù)邏輯查詢用戶 id); return new User(id, 張三); } }第三步編寫方法攔截器javaimport net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; import java.lang.reflect.Method; public class LogMethodInterceptor implements MethodInterceptor { Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { System.out.println(【日志】開始調(diào)用方法 method.getName()); long start System.currentTimeMillis(); try { Object result proxy.invokeSuper(obj, args); return result; } finally { long cost System.currentTimeMillis() - start; System.out.println(【日志】方法 method.getName() 執(zhí)行完成耗時(shí) cost ms); } } }第四步使用 Enhancer 創(chuàng)建代理對(duì)象javaimport net.sf.cglib.proxy.Enhancer; public class CglibProxyDemo { public static void main(String[] args) { Enhancer enhancer new Enhancer(); enhancer.setSuperclass(UserService.class); enhancer.setCallback(new LogMethodInterceptor()); UserService proxy (UserService) enhancer.create(); proxy.save(李四); User user proxy.findById(1L); System.out.println(查詢結(jié)果 user.getName()); } }運(yùn)行后UserService的方法調(diào)用被攔截器捕獲日志和耗時(shí)統(tǒng)計(jì)自動(dòng)加入而UserService本身沒有任何修改。4.4 CGLIB 的底層工作流程CGLIB 生成代理類的過程大致如下創(chuàng)建 Enhancer 并配置設(shè)置父類目標(biāo)類、回調(diào)攔截器、是否實(shí)現(xiàn)接口等參數(shù)。生成代理類字節(jié)碼CGLIB 使用 ASM 框架動(dòng)態(tài)生成目標(biāo)類的子類字節(jié)碼。子類會(huì)重寫父類中所有非 final、非 private、非 static 的方法。加載代理類通過自定義的 ClassLoader 把生成的字節(jié)碼加載到 JVM 中得到代理類的 Class 對(duì)象。創(chuàng)建代理實(shí)例反射調(diào)用代理類構(gòu)造方法傳入 Callback 數(shù)組創(chuàng)建代理對(duì)象。方法調(diào)用攔截當(dāng)調(diào)用代理對(duì)象的某個(gè)方法時(shí)實(shí)際進(jìn)入子類重寫的方法。該方法會(huì)調(diào)用MethodInterceptor.intercept由攔截器決定增強(qiáng)邏輯和是否調(diào)用父類方法。生成的代理類結(jié)構(gòu)大致如下簡(jiǎn)化示意javapublic class UserService$$EnhancerByCGLIB$$xxxx extends UserService implements Factory { private MethodInterceptor interceptor; Override public void save(String name) { MethodProxy proxy MethodProxy.create(UserService.class, UserService$$EnhancerByCGLIB$$xxxx.class, (Ljava/lang/String;)V, save, CGLIB$save$0); interceptor.intercept(this, method, new Object[]{name}, proxy); } Override public User findById(Long id) { MethodProxy proxy MethodProxy.create(UserService.class, UserService$$EnhancerByCGLIB$$xxxx.class, (Ljava/lang/Long;)Lcom/example/User;, findById, CGLIB$findById$1); return (User) interceptor.intercept(this, method, new Object[]{id}, proxy); } final void CGLIB$save$0(String name) { super.save(name); } final User CGLIB$findById$1(Long id) { return super.findById(id); } }可以看到CGLIB 生成的代理類繼承自目標(biāo)類重寫了需要被代理的方法。重寫方法中調(diào)用interceptor.intercept并把MethodProxy傳入。攔截器通過proxy.invokeSuper(obj, args)調(diào)用父類原始方法從而完成增強(qiáng)。4.5 CGLIB 的限制與注意事項(xiàng)CGLIB 雖然強(qiáng)大但也有若干限制和注意事項(xiàng)無(wú)法代理 final 類因?yàn)?CGLIB 通過繼承實(shí)現(xiàn)代理如果目標(biāo)類被final修飾就無(wú)法生成子類代理失敗。無(wú)法代理 final 方法被final修飾的方法不能被子類重寫因此無(wú)法被攔截。無(wú)法代理 private 方法private 方法不參與繼承子類無(wú)法訪問也無(wú)法攔截。無(wú)法代理 static 方法static 方法屬于類本身不屬于對(duì)象不能通過繼承攔截。構(gòu)造方法不被代理CGLIB 生成的代理類會(huì)調(diào)用父類構(gòu)造方法但構(gòu)造方法本身不被攔截。因此如果目標(biāo)類只有帶參構(gòu)造方法且沒有默認(rèn)構(gòu)造需要顯式指定構(gòu)造參數(shù)。性能考量CGLIB 生成代理類的速度比 JDK 動(dòng)態(tài)代理慢但一旦生成完成后續(xù)方法調(diào)用性能優(yōu)于 JDK 反射調(diào)用。因此 CGLIB 適合「代理類生成不頻繁、方法調(diào)用頻繁」的場(chǎng)景。4.6 CGLIB 的優(yōu)缺點(diǎn)優(yōu)點(diǎn)不要求接口可以代理沒有實(shí)現(xiàn)任何接口的普通類覆蓋面更廣。調(diào)用性能好通過MethodProxy.invokeSuper直接調(diào)用父類方法避免反射調(diào)用性能接近直接調(diào)用。與 Spring AOP 深度集成Spring AOP 對(duì)無(wú)接口的目標(biāo)類默認(rèn)使用 CGLIB 代理。支持多種回調(diào)除MethodInterceptor外還支持FixedValue、NoOp、LazyLoader等回調(diào)適配多種場(chǎng)景。缺點(diǎn)無(wú)法代理 final 類和 final 方法這是繼承機(jī)制帶來(lái)的根本限制。生成代理類較慢需要生成字節(jié)碼并加載首次創(chuàng)建代理類開銷高于 JDK 動(dòng)態(tài)代理?？赡苡绊戭悓哟未眍愂悄繕?biāo)類的子類可能影響getClass()、instanceof等行為。需要額外依賴在非 Spring 環(huán)境中需要顯式引入 CGLIB 依賴。調(diào)試難度增加代理類名形如UserService$$EnhancerByCGLIB$$xxxx堆棧信息較復(fù)雜。5. JDK 動(dòng)態(tài)代理與 CGLIB 的對(duì)比5.1 核心差異對(duì)比維度JDK 動(dòng)態(tài)代理CGLIB 動(dòng)態(tài)代理代理方式基于接口實(shí)現(xiàn)基于繼承實(shí)現(xiàn)目標(biāo)類要求必須實(shí)現(xiàn)接口無(wú)需接口但不能是 final 類代理類結(jié)構(gòu)實(shí)現(xiàn)目標(biāo)接口繼承 Proxy繼承目標(biāo)類方法調(diào)用反射調(diào)用Method.invokeMethodProxy.invokeSuper生成速度較快較慢調(diào)用性能反射調(diào)用JDK 8 優(yōu)化后接近直接調(diào)用接近直接調(diào)用通常略優(yōu)于反射限制只能代理接口不能代理 final 類、final 方法、private 方法、static 方法依賴JDK 原生需引入 CGLIB 或使用 Spring 內(nèi)置版本調(diào)試難度代理類名$Proxy0較易識(shí)別代理類名較長(zhǎng)堆棧略復(fù)雜5.2 性能對(duì)比從性能維度看兩者各有側(cè)重代理類生成速度JDK 動(dòng)態(tài)代理通常快于 CGLIB因?yàn)榛诮涌谏蛇壿嬒鄬?duì)簡(jiǎn)單。方法調(diào)用速度CGLIB 通過MethodProxy直接調(diào)用父類方法避免反射開銷在高頻調(diào)用場(chǎng)景下通常優(yōu)于 JDK 反射調(diào)用。但在 JDK 8 之后Method.invoke經(jīng)過大量?jī)?yōu)化兩者差距已明顯縮小。內(nèi)存占用CGLIB 生成的代理類通常比 JDK 代理類更大因?yàn)樾枰^承目標(biāo)類并生成方法代理。實(shí)際選型時(shí)性能不應(yīng)作為唯一標(biāo)準(zhǔn)。更重要的是看目標(biāo)類是否實(shí)現(xiàn)接口、是否有 final 限制、框架默認(rèn)行為等因素。5.3 選型建議目標(biāo)類實(shí)現(xiàn)了接口且接口穩(wěn)定優(yōu)先使用 JDK 動(dòng)態(tài)代理原生支持、無(wú)額外依賴。目標(biāo)類沒有實(shí)現(xiàn)接口使用 CGLIB 動(dòng)態(tài)代理。目標(biāo)類被 final 修飾兩者都無(wú)法代理需要考慮其他方案如裝飾器模式、AspectJ 編譯期織入。目標(biāo)方法被 final 修飾JDK 動(dòng)態(tài)代理不受影響接口方法CGLIB 無(wú)法攔截。Spring 項(xiàng)目Spring AOP 默認(rèn)規(guī)則是「有接口用 JDK無(wú)接口用 CGLIB」可通過proxyTargetClass強(qiáng)制使用 CGLIB。Spring Boot 2.x 及以后默認(rèn)proxyTargetClasstrue即默認(rèn)使用 CGLIB 代理。6. 動(dòng)態(tài)代理在主流框架中的應(yīng)用6.1 Spring AOPSpring AOP 是動(dòng)態(tài)代理最經(jīng)典的應(yīng)用場(chǎng)景。它通過AopProxy接口封裝代理創(chuàng)建邏輯根據(jù)目標(biāo)類是否實(shí)現(xiàn)接口選擇 JDK 動(dòng)態(tài)代理或 CGLIB。JdkDynamicAopProxy基于 JDK 動(dòng)態(tài)代理實(shí)現(xiàn)InvocationHandler在invoke中織入通知邏輯。CglibAopProxy基于 CGLIB實(shí)現(xiàn)MethodInterceptor在intercept中織入通知邏輯。Spring AOP 的代理創(chuàng)建流程大致如下解析切面配置收集所有 Advisor。通過AnnotationAwareAspectJAutoProxyCreator在 Bean 初始化后判斷是否需要代理。如果需要代理根據(jù)目標(biāo)類是否實(shí)現(xiàn)接口選擇代理方式。創(chuàng)建代理對(duì)象替換原始 Bean。方法調(diào)用時(shí)代理對(duì)象攔截并執(zhí)行通知鏈。6.2 MyBatis MapperMyBatis 的 Mapper 接口沒有實(shí)現(xiàn)類但可以通過 JDK 動(dòng)態(tài)代理在運(yùn)行期生成實(shí)現(xiàn)。MapperProxyFactory負(fù)責(zé)創(chuàng)建 Mapper 代理MapperProxy實(shí)現(xiàn)InvocationHandler在invoke中根據(jù)方法簽名找到對(duì)應(yīng)的MappedStatement執(zhí)行 SQL 并返回結(jié)果。javapublic class MapperProxyT implements InvocationHandler, Serializable { Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { if (Object.class.equals(method.getDeclaringClass())) { return method.invoke(this, args); } MapperMethod mapperMethod cachedMapperMethod(method); return mapperMethod.execute(sqlSession, args); } }6.3 RPC 框架Dubbo、gRPC 等 RPC 框架通過動(dòng)態(tài)代理為遠(yuǎn)程服務(wù)生成本地代理。調(diào)用方注入接口后實(shí)際拿到的是代理對(duì)象調(diào)用代理方法時(shí)代理會(huì)封裝網(wǎng)絡(luò)請(qǐng)求、序列化參數(shù)、發(fā)送到遠(yuǎn)端、接收響應(yīng)并反序列化讓調(diào)用方感覺像在調(diào)用本地方法。Dubbo 默認(rèn)使用 Javassist 字節(jié)碼生成代理但也支持 JDK 動(dòng)態(tài)代理。Spring Cloud 中的 Feign 則基于 JDK 動(dòng)態(tài)代理為聲明式接口生成 HTTP 客戶端。6.4 其他應(yīng)用事務(wù)管理SpringTransactional通過 AOP 代理織入事務(wù)邏輯。緩存Spring Cache 通過代理攔截方法調(diào)用命中緩存時(shí)直接返回未命中時(shí)執(zhí)行方法并寫入緩存。權(quán)限校驗(yàn)通過代理在方法調(diào)用前校驗(yàn)權(quán)限。日志與監(jiān)控通過代理記錄方法調(diào)用日志、耗時(shí)、異常等信息。Mock 框架Mockito 等測(cè)試框架通過動(dòng)態(tài)代理生成 Mock 對(duì)象。7. 面試高頻考點(diǎn)解析7.1 為什么 JDK 動(dòng)態(tài)代理只能代理接口JDK 動(dòng)態(tài)代理生成的代理類已經(jīng)繼承了java.lang.reflect.Proxy。由于 Java 是單繼承語(yǔ)言一個(gè)類只能有一個(gè)父類因此代理類無(wú)法再繼承目標(biāo)類只能通過實(shí)現(xiàn)目標(biāo)類所實(shí)現(xiàn)的接口來(lái)完成類型匹配。這是 JDK 動(dòng)態(tài)代理只能代理接口的根本原因。7.2 CGLIB 為什么不能代理 final 類和方法CGLIB 通過生成目標(biāo)類的子類來(lái)實(shí)現(xiàn)代理。如果目標(biāo)類被final修飾則無(wú)法被繼承自然無(wú)法生成子類。如果方法被final修飾則無(wú)法被子類重寫也就無(wú)法被攔截。同理private 方法無(wú)法被子類訪問static 方法屬于類本身都無(wú)法被 CGLIB 代理。7.3 Spring AOP 如何選擇代理方式Spring AOP 的默認(rèn)規(guī)則是如果目標(biāo)類實(shí)現(xiàn)了至少一個(gè)接口默認(rèn)使用 JDK 動(dòng)態(tài)代理。如果目標(biāo)類沒有實(shí)現(xiàn)任何接口使用 CGLIB 動(dòng)態(tài)代理。可以通過EnableAspectJAutoProxy(proxyTargetClass true)或配置spring.aop.proxy-target-classtrue強(qiáng)制使用 CGLIB。Spring Boot 2.x 開始默認(rèn)proxyTargetClasstrue即默認(rèn)使用 CGLIB。7.4 JDK 動(dòng)態(tài)代理和 CGLIB 的性能差異需要分兩個(gè)維度看代理類生成速度JDK 動(dòng)態(tài)代理通常更快因?yàn)榛诮涌谏蛇壿嫼?jiǎn)單。方法調(diào)用速度CGLIB 通過MethodProxy直接調(diào)用父類方法通?？煊?JDK 的反射調(diào)用。但 JDK 8 之后Method.invoke經(jīng)過優(yōu)化差距已不明顯。實(shí)際場(chǎng)景中代理類通常只生成一次方法調(diào)用可能發(fā)生成千上萬(wàn)次因此調(diào)用性能更值得關(guān)注。但在現(xiàn)代 JVM 上兩者差距通常不足以成為選型的決定性因素。7.5 為什么在 InvocationHandler 中調(diào)用 proxy 的方法會(huì)導(dǎo)致死循環(huán)InvocationHandler.invoke中的proxy參數(shù)是代理對(duì)象本身。如果在invoke中調(diào)用proxy.someMethod()這個(gè)調(diào)用會(huì)再次進(jìn)入invoke形成無(wú)限遞歸。正確做法是保存目標(biāo)對(duì)象引用通過method.invoke(target, args)調(diào)用目標(biāo)方法而不是調(diào)用代理對(duì)象的方法。7.6 如何查看 JDK 動(dòng)態(tài)生成的代理類可以通過以下方式JDK 8設(shè)置系統(tǒng)屬性sun.misc.ProxyGenerator.saveGeneratedFilestrue。JDK 9設(shè)置jdk.proxy.ProxyGenerator.saveGeneratedFilestrue或使用--add-opens參數(shù)。使用 Arthas 的jad命令反編譯代理類。使用 HSDB 或 JProfiler 等工具在運(yùn)行時(shí)查看。7.7 CGLIB 的 MethodProxy 和 Method 有什么區(qū)別Method是 JDK 反射 API調(diào)用method.invoke(target, args)需要傳入目標(biāo)對(duì)象通過反射執(zhí)行。MethodProxy是 CGLIB 提供的代理對(duì)象調(diào)用proxy.invokeSuper(obj, args)會(huì)直接調(diào)用父類的原始方法避免反射開銷。CGLIB 在生成代理類時(shí)會(huì)為每個(gè)被代理方法生成一個(gè)對(duì)應(yīng)的CGLIB$method$index方法MethodProxy內(nèi)部通過 FastClass 機(jī)制定位并調(diào)用這個(gè)方法從而實(shí)現(xiàn)高性能調(diào)用。8. 總結(jié)動(dòng)態(tài)代理是 Java 生態(tài)中極其重要的底層技術(shù)Spring AOP、MyBatis Mapper、RPC 框架等都建立在其之上。Java 提供了兩種主要的動(dòng)態(tài)代理實(shí)現(xiàn)JDK 動(dòng)態(tài)代理基于接口JDK 原生支持無(wú)需額外依賴代理類實(shí)現(xiàn)目標(biāo)接口并繼承Proxy方法調(diào)用統(tǒng)一分發(fā)到InvocationHandler.invoke。限制是目標(biāo)類必須實(shí)現(xiàn)接口。CGLIB 動(dòng)態(tài)代理基于繼承通過 ASM 生成目標(biāo)類的子類并重寫方法方法調(diào)用進(jìn)入MethodInterceptor.intercept。不要求接口但無(wú)法代理 final 類、final 方法、private 方法和 static 方法。兩者在生成速度、調(diào)用性能、限制條件、依賴成本上各有優(yōu)劣。實(shí)際選型時(shí)應(yīng)根據(jù)目標(biāo)類是否實(shí)現(xiàn)接口、是否有 final 限制、框架默認(rèn)行為等因素綜合判斷。在 Spring 生態(tài)中Spring AOP 已經(jīng)封裝了兩種代理方式并根據(jù)目標(biāo)類自動(dòng)選擇開發(fā)者通常無(wú)需直接操作底層 API。理解動(dòng)態(tài)代理的原理不僅能幫助我們?cè)诿嬖囍袕娜輵?yīng)對(duì)更能讓我們?cè)谂挪?Spring 事務(wù)失效、AOP 不生效、MyBatis Mapper 注入失敗等問題時(shí)快速定位根因。掌握這一技術(shù)是從「會(huì)用框架」走向「理解框架」的重要一步。