當(dāng)前位置：首頁 > 编程语言 > java >内容正文

java

Java 动态代理机制分析及扩展--转

發(fā)布時(shí)間：2025/4/5 java 32 豆豆

生活随笔收集整理的這篇文章主要介紹了 Java 动态代理机制分析及扩展--转小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

http://www.ibm.com/developerworks/cn/java/j-lo-proxy1/#icomments

http://www.ibm.com/developerworks/cn/java/j-lo-proxy2/

引言

Java 動(dòng)態(tài)代理機(jī)制的出現(xiàn)，使得 Java 開發(fā)人員不用手工編寫代理類，只要簡單地指定一組接口及委托類對(duì)象，便能動(dòng)態(tài)地獲得代理類。代理類會(huì)負(fù)責(zé)將所有的方法調(diào)用分派到委托對(duì)象上反射執(zhí)行，在分派執(zhí)行的過程中，開發(fā)人員還可以按需調(diào)整委托類對(duì)象及其功能，這是一套非常靈活有彈性的代理框架。通過閱讀本文，讀者將會(huì)對(duì) Java 動(dòng)態(tài)代理機(jī)制有更加深入的理解。本文首先從 Java 動(dòng)態(tài)代理的運(yùn)行機(jī)制和特點(diǎn)出發(fā)，對(duì)其代碼進(jìn)行了分析，推演了動(dòng)態(tài)生成類的內(nèi)部實(shí)現(xiàn)。

回頁首

代理：設(shè)計(jì)模式

代理是一種常用的設(shè)計(jì)模式，其目的就是為其他對(duì)象提供一個(gè)代理以控制對(duì)某個(gè)對(duì)象的訪問。代理類負(fù)責(zé)為委托類預(yù)處理消息，過濾消息并轉(zhuǎn)發(fā)消息，以及進(jìn)行消息被委托類執(zhí)行后的后續(xù)處理。

圖 1. 代理模式

為了保持行為的一致性，代理類和委托類通常會(huì)實(shí)現(xiàn)相同的接口，所以在訪問者看來兩者沒有絲毫的區(qū)別。通過代理類這中間一層，能有效控制對(duì)委托類對(duì)象的直接訪問，也可以很好地隱藏和保護(hù)委托類對(duì)象，同時(shí)也為實(shí)施不同控制策略預(yù)留了空間，從而在設(shè)計(jì)上獲得了更大的靈活性。Java 動(dòng)態(tài)代理機(jī)制以巧妙的方式近乎完美地實(shí)踐了代理模式的設(shè)計(jì)理念。

回頁首

代理機(jī)制及其特點(diǎn)

首先讓我們來了解一下如何使用 Java 動(dòng)態(tài)代理。具體有如下四步驟：

通過實(shí)現(xiàn) InvocationHandler 接口創(chuàng)建自己的調(diào)用處理器；

通過為 Proxy 類指定 ClassLoader 對(duì)象和一組 interface 來創(chuàng)建動(dòng)態(tài)代理類；

通過反射機(jī)制獲得動(dòng)態(tài)代理類的構(gòu)造函數(shù)，其唯一參數(shù)類型是調(diào)用處理器接口類型；

通過構(gòu)造函數(shù)創(chuàng)建動(dòng)態(tài)代理類實(shí)例，構(gòu)造時(shí)調(diào)用處理器對(duì)象作為參數(shù)被傳入。

清單 3. 動(dòng)態(tài)代理對(duì)象創(chuàng)建過程

// InvocationHandlerImpl 實(shí)現(xiàn)了 InvocationHandler 接口，并能實(shí)現(xiàn)方法調(diào)用從代理類到委托類的分派轉(zhuǎn)發(fā) // 其內(nèi)部通常包含指向委托類實(shí)例的引用，用于真正執(zhí)行分派轉(zhuǎn)發(fā)過來的方法調(diào)用 InvocationHandler handler = new InvocationHandlerImpl(..); // 通過 Proxy 為包括 Interface 接口在內(nèi)的一組接口動(dòng)態(tài)創(chuàng)建代理類的類對(duì)象 Class clazz = Proxy.getProxyClass(classLoader, new Class[] { Interface.class, ... }); // 通過反射從生成的類對(duì)象獲得構(gòu)造函數(shù)對(duì)象 Constructor constructor = clazz.getConstructor(new Class[] { InvocationHandler.class }); // 通過構(gòu)造函數(shù)對(duì)象創(chuàng)建動(dòng)態(tài)代理類實(shí)例 Interface Proxy = (Interface)constructor.newInstance(new Object[] { handler });

實(shí)際使用過程更加簡單，因?yàn)?Proxy 的靜態(tài)方法 newProxyInstance 已經(jīng)為我們封裝了步驟 2 到步驟 4 的過程，所以簡化后的過程如下

清單 4. 簡化的動(dòng)態(tài)代理對(duì)象創(chuàng)建過程

// InvocationHandlerImpl 實(shí)現(xiàn)了 InvocationHandler 接口，并能實(shí)現(xiàn)方法調(diào)用從代理類到委托類的分派轉(zhuǎn)發(fā) InvocationHandler handler = new InvocationHandlerImpl(..); // 通過 Proxy 直接創(chuàng)建動(dòng)態(tài)代理類實(shí)例 Interface proxy = (Interface)Proxy.newProxyInstance( classLoader, new Class[] { Interface.class }, handler );

接下來讓我們來了解一下 Java 動(dòng)態(tài)代理機(jī)制的一些特點(diǎn)。

首先是動(dòng)態(tài)生成的代理類本身的一些特點(diǎn)。1）包：如果所代理的接口都是 public 的，那么它將被定義在頂層包（即包路徑為空），如果所代理的接口中有非 public 的接口（因?yàn)榻涌诓荒鼙欢x為 protect 或 private，所以除 public 之外就是默認(rèn)的 package 訪問級(jí)別），那么它將被定義在該接口所在包（假設(shè)代理了 com.ibm.developerworks 包中的某非 public 接口 A，那么新生成的代理類所在的包就是 com.ibm.developerworks），這樣設(shè)計(jì)的目的是為了最大程度的保證動(dòng)態(tài)代理類不會(huì)因?yàn)榘芾淼膯栴}而無法被成功定義并訪問；2）類修飾符：該代理類具有 final 和 public 修飾符，意味著它可以被所有的類訪問，但是不能被再度繼承；3）類名：格式是“$ProxyN”，其中 N 是一個(gè)逐一遞增的阿拉伯?dāng)?shù)字，代表 Proxy 類第 N 次生成的動(dòng)態(tài)代理類，值得注意的一點(diǎn)是，并不是每次調(diào)用 Proxy 的靜態(tài)方法創(chuàng)建動(dòng)態(tài)代理類都會(huì)使得 N 值增加，原因是如果對(duì)同一組接口（包括接口排列的順序相同）試圖重復(fù)創(chuàng)建動(dòng)態(tài)代理類，它會(huì)很聰明地返回先前已經(jīng)創(chuàng)建好的代理類的類對(duì)象，而不會(huì)再嘗試去創(chuàng)建一個(gè)全新的代理類，這樣可以節(jié)省不必要的代碼重復(fù)生成，提高了代理類的創(chuàng)建效率。4）類繼承關(guān)系：該類的繼承關(guān)系如圖：

圖 2. 動(dòng)態(tài)代理類的繼承圖

由圖可見，Proxy 類是它的父類，這個(gè)規(guī)則適用于所有由 Proxy 創(chuàng)建的動(dòng)態(tài)代理類。而且該類還實(shí)現(xiàn)了其所代理的一組接口，這就是為什么它能夠被安全地類型轉(zhuǎn)換到其所代理的某接口的根本原因。

接下來讓我們了解一下代理類實(shí)例的一些特點(diǎn)。每個(gè)實(shí)例都會(huì)關(guān)聯(lián)一個(gè)調(diào)用處理器對(duì)象，可以通過 Proxy 提供的靜態(tài)方法 getInvocationHandler 去獲得代理類實(shí)例的調(diào)用處理器對(duì)象。在代理類實(shí)例上調(diào)用其代理的接口中所聲明的方法時(shí)，這些方法最終都會(huì)由調(diào)用處理器的 invoke 方法執(zhí)行，此外，值得注意的是，代理類的根類 java.lang.Object 中有三個(gè)方法也同樣會(huì)被分派到調(diào)用處理器的 invoke 方法執(zhí)行，它們是 hashCode，equals 和 toString，可能的原因有：一是因?yàn)檫@些方法為 public 且非 final 類型，能夠被代理類覆蓋；二是因?yàn)檫@些方法往往呈現(xiàn)出一個(gè)類的某種特征屬性，具有一定的區(qū)分度，所以為了保證代理類與委托類對(duì)外的一致性，這三個(gè)方法也應(yīng)該被分派到委托類執(zhí)行。當(dāng)代理的一組接口有重復(fù)聲明的方法且該方法被調(diào)用時(shí)，代理類總是從排在最前面的接口中獲取方法對(duì)象并分派給調(diào)用處理器，而無論代理類實(shí)例是否正在以該接口（或繼承于該接口的某子接口）的形式被外部引用，因?yàn)樵诖眍悆?nèi)部無法區(qū)分其當(dāng)前的被引用類型。

接著來了解一下被代理的一組接口有哪些特點(diǎn)。首先，要注意不能有重復(fù)的接口，以避免動(dòng)態(tài)代理類代碼生成時(shí)的編譯錯(cuò)誤。其次，這些接口對(duì)于類裝載器必須可見，否則類裝載器將無法鏈接它們，將會(huì)導(dǎo)致類定義失敗。再次，需被代理的所有非 public 的接口必須在同一個(gè)包中，否則代理類生成也會(huì)失敗。最后，接口的數(shù)目不能超過 65535，這是 JVM 設(shè)定的限制。

最后再來了解一下異常處理方面的特點(diǎn)。從調(diào)用處理器接口聲明的方法中可以看到理論上它能夠拋出任何類型的異常，因?yàn)樗械漠惓６祭^承于 Throwable 接口，但事實(shí)是否如此呢？答案是否定的，原因是我們必須遵守一個(gè)繼承原則：即子類覆蓋父類或?qū)崿F(xiàn)父接口的方法時(shí)，拋出的異常必須在原方法支持的異常列表之內(nèi)。所以雖然調(diào)用處理器理論上講能夠，但實(shí)際上往往受限制，除非父接口中的方法支持拋 Throwable 異常。那么如果在 invoke 方法中的確產(chǎn)生了接口方法聲明中不支持的異常，那將如何呢？放心，Java 動(dòng)態(tài)代理類已經(jīng)為我們?cè)O(shè)計(jì)好了解決方法：它將會(huì)拋出 UndeclaredThrowableException 異常。這個(gè)異常是一個(gè) RuntimeException 類型，所以不會(huì)引起編譯錯(cuò)誤。通過該異常的 getCause 方法，還可以獲得原來那個(gè)不受支持的異常對(duì)象，以便于錯(cuò)誤診斷。

回頁首

代碼是最好的老師

機(jī)制和特點(diǎn)都介紹過了，接下來讓我們通過源代碼來了解一下 Proxy 到底是如何實(shí)現(xiàn)的。

首先記住 Proxy 的幾個(gè)重要的靜態(tài)變量：

清單 5. Proxy 的重要靜態(tài)變量

// 映射表：用于維護(hù)類裝載器對(duì)象到其對(duì)應(yīng)的代理類緩存 private static Map loaderToCache = new WeakHashMap(); // 標(biāo)記：用于標(biāo)記一個(gè)動(dòng)態(tài)代理類正在被創(chuàng)建中 private static Object pendingGenerationMarker = new Object(); // 同步表：記錄已經(jīng)被創(chuàng)建的動(dòng)態(tài)代理類類型，主要被方法 isProxyClass 進(jìn)行相關(guān)的判斷 private static Map proxyClasses = Collections.synchronizedMap(new WeakHashMap()); // 關(guān)聯(lián)的調(diào)用處理器引用 protected InvocationHandler h;

然后，來看一下 Proxy 的構(gòu)造方法：

清單 6. Proxy 構(gòu)造方法

// 由于 Proxy 內(nèi)部從不直接調(diào)用構(gòu)造函數(shù)，所以 private 類型意味著禁止任何調(diào)用 private Proxy() {} // 由于 Proxy 內(nèi)部從不直接調(diào)用構(gòu)造函數(shù)，所以 protected 意味著只有子類可以調(diào)用 protected Proxy(InvocationHandler h) {this.h = h;}

接著，可以快速瀏覽一下 newProxyInstance 方法，因?yàn)槠湎喈?dāng)簡單：

清單 7. Proxy 靜態(tài)方法 newProxyInstance

public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h) throws IllegalArgumentException { // 檢查 h 不為空，否則拋異常if (h == null) { throw new NullPointerException(); } // 獲得與制定類裝載器和一組接口相關(guān)的代理類類型對(duì)象Class cl = getProxyClass(loader, interfaces); // 通過反射獲取構(gòu)造函數(shù)對(duì)象并生成代理類實(shí)例try { Constructor cons = cl.getConstructor(constructorParams); return (Object) cons.newInstance(new Object[] { h }); } catch (NoSuchMethodException e) { throw new InternalError(e.toString()); } catch (IllegalAccessException e) { throw new InternalError(e.toString()); } catch (InstantiationException e) { throw new InternalError(e.toString()); } catch (InvocationTargetException e) { throw new InternalError(e.toString()); } }

由此可見，動(dòng)態(tài)代理真正的關(guān)鍵是在 getProxyClass 方法，該方法負(fù)責(zé)為一組接口動(dòng)態(tài)地生成代理類類型對(duì)象。在該方法內(nèi)部，您將能看到 Proxy 內(nèi)的各路英雄（靜態(tài)變量）悉數(shù)登場。有點(diǎn)迫不及待了么？那就讓我們一起走進(jìn) Proxy 最最神秘的殿堂去欣賞一番吧。該方法總共可以分為四個(gè)步驟：

對(duì)這組接口進(jìn)行一定程度的安全檢查，包括檢查接口類對(duì)象是否對(duì)類裝載器可見并且與類裝載器所能識(shí)別的接口類對(duì)象是完全相同的，還會(huì)檢查確保是 interface 類型而不是 class 類型。這個(gè)步驟通過一個(gè)循環(huán)來完成，檢查通過后將會(huì)得到一個(gè)包含所有接口名稱的字符串?dāng)?shù)組，記為?String[] interfaceNames。總體上這部分實(shí)現(xiàn)比較直觀，所以略去大部分代碼，僅保留留如何判斷某類或接口是否對(duì)特定類裝載器可見的相關(guān)代碼。

清單 8. 通過 Class.forName 方法判接口的可見性

try { // 指定接口名字、類裝載器對(duì)象，同時(shí)制定 initializeBoolean 為 false 表示無須初始化類// 如果方法返回正常這表示可見，否則會(huì)拋出 ClassNotFoundException 異常表示不可見interfaceClass = Class.forName(interfaceName, false, loader); } catch (ClassNotFoundException e) { }

從 loaderToCache 映射表中獲取以類裝載器對(duì)象為關(guān)鍵字所對(duì)應(yīng)的緩存表，如果不存在就創(chuàng)建一個(gè)新的緩存表并更新到 loaderToCache。緩存表是一個(gè) HashMap 實(shí)例，正常情況下它將存放鍵值對(duì)（接口名字列表，動(dòng)態(tài)生成的代理類的類對(duì)象引用）。當(dāng)代理類正在被創(chuàng)建時(shí)它會(huì)臨時(shí)保存（接口名字列表，pendingGenerationMarker）。標(biāo)記 pendingGenerationMarke 的作用是通知后續(xù)的同類請(qǐng)求（接口數(shù)組相同且組內(nèi)接口排列順序也相同）代理類正在被創(chuàng)建，請(qǐng)保持等待直至創(chuàng)建完成。

清單 9. 緩存表的使用

do { // 以接口名字列表作為關(guān)鍵字獲得對(duì)應(yīng) cache 值Object value = cache.get(key); if (value instanceof Reference) { proxyClass = (Class) ((Reference) value).get(); } if (proxyClass != null) { // 如果已經(jīng)創(chuàng)建，直接返回return proxyClass; } else if (value == pendingGenerationMarker) { // 代理類正在被創(chuàng)建，保持等待try { cache.wait(); } catch (InterruptedException e) { } // 等待被喚醒，繼續(xù)循環(huán)并通過二次檢查以確保創(chuàng)建完成，否則重新等待continue; } else { // 標(biāo)記代理類正在被創(chuàng)建cache.put(key, pendingGenerationMarker); // break 跳出循環(huán)已進(jìn)入創(chuàng)建過程break; } while (true);

動(dòng)態(tài)創(chuàng)建代理類的類對(duì)象。首先是確定代理類所在的包，其原則如前所述，如果都為 public 接口，則包名為空字符串表示頂層包；如果所有非 public 接口都在同一個(gè)包，則包名與這些接口的包名相同；如果有多個(gè)非 public 接口且不同包，則拋異常終止代理類的生成。確定了包后，就開始生成代理類的類名，同樣如前所述按格式“$ProxyN”生成。類名也確定了，接下來就是見證奇跡的發(fā)生 —— 動(dòng)態(tài)生成代理類：

清單 10. 動(dòng)態(tài)生成代理類

// 動(dòng)態(tài)地生成代理類的字節(jié)碼數(shù)組 byte[] proxyClassFile = ProxyGenerator.generateProxyClass( proxyName, interfaces); try { // 動(dòng)態(tài)地定義新生成的代理類proxyClass = defineClass0(loader, proxyName, proxyClassFile, 0, proxyClassFile.length); } catch (ClassFormatError e) { throw new IllegalArgumentException(e.toString()); } // 把生成的代理類的類對(duì)象記錄進(jìn) proxyClasses 表 proxyClasses.put(proxyClass, null);

由此可見，所有的代碼生成的工作都由神秘的 ProxyGenerator 所完成了，當(dāng)你嘗試去探索這個(gè)類時(shí)，你所能獲得的信息僅僅是它位于并未公開的 sun.misc 包，有若干常量、變量和方法以完成這個(gè)神奇的代碼生成的過程，但是 sun 并沒有提供源代碼以供研讀。至于動(dòng)態(tài)類的定義，則由 Proxy 的 native 靜態(tài)方法 defineClass0 執(zhí)行。

代碼生成過程進(jìn)入結(jié)尾部分，根據(jù)結(jié)果更新緩存表，如果成功則將代理類的類對(duì)象引用更新進(jìn)緩存表，否則清楚緩存表中對(duì)應(yīng)關(guān)鍵值，最后喚醒所有可能的正在等待的線程。

走完了以上四個(gè)步驟后，至此，所有的代理類生成細(xì)節(jié)都已介紹完畢，剩下的靜態(tài)方法如 getInvocationHandler 和 isProxyClass 就顯得如此的直觀，只需通過查詢相關(guān)變量就可以完成，所以對(duì)其的代碼分析就省略了。

回頁首

代理類實(shí)現(xiàn)推演

分析了 Proxy 類的源代碼，相信在讀者的腦海中會(huì)對(duì) Java 動(dòng)態(tài)代理機(jī)制形成一個(gè)更加清晰的理解，但是，當(dāng)探索之旅在 sun.misc.ProxyGenerator 類處嘎然而止，所有的神秘都匯聚于此時(shí)，相信不少讀者也會(huì)對(duì)這個(gè) ProxyGenerator 類產(chǎn)生有類似的疑惑：它到底做了什么呢？它是如何生成動(dòng)態(tài)代理類的代碼的呢？誠然，這里也無法給出確切的答案。還是讓我們帶著這些疑惑，一起開始探索之旅吧。

事物往往不像其看起來的復(fù)雜，需要的是我們能夠化繁為簡，這樣也許就能有更多撥云見日的機(jī)會(huì)。拋開所有想象中的未知而復(fù)雜的神秘因素，如果讓我們用最簡單的方法去實(shí)現(xiàn)一個(gè)代理類，唯一的要求是同樣結(jié)合調(diào)用處理器實(shí)施方法的分派轉(zhuǎn)發(fā)，您的第一反應(yīng)將是什么呢？“聽起來似乎并不是很復(fù)雜”。的確，掐指算算所涉及的工作無非包括幾個(gè)反射調(diào)用，以及對(duì)原始類型數(shù)據(jù)的裝箱或拆箱過程，其他的似乎都已經(jīng)水到渠成。非常地好，讓我們整理一下思緒，一起來完成一次完整的推演過程吧。

清單 11. 代理類中方法調(diào)用的分派轉(zhuǎn)發(fā)推演實(shí)現(xiàn)

// 假設(shè)需代理接口 Simulator public interface Simulator { short simulate(int arg1, long arg2, String arg3) throws ExceptionA, ExceptionB; } // 假設(shè)代理類為 SimulatorProxy, 其類聲明將如下 final public class SimulatorProxy implements Simulator { // 調(diào)用處理器對(duì)象的引用protected InvocationHandler handler; // 以調(diào)用處理器為參數(shù)的構(gòu)造函數(shù)public SimulatorProxy(InvocationHandler handler){ this.handler = handler; } // 實(shí)現(xiàn)接口方法 simulate public short simulate(int arg1, long arg2, String arg3) throws ExceptionA, ExceptionB {// 第一步是獲取 simulate 方法的 Method 對(duì)象java.lang.reflect.Method method = null; try{ method = Simulator.class.getMethod( "simulate", new Class[] {int.class, long.class, String.class} );} catch(Exception e) { // 異常處理 1（略）} // 第二步是調(diào)用 handler 的 invoke 方法分派轉(zhuǎn)發(fā)方法調(diào)用Object r = null; try { r = handler.invoke(this, method, // 對(duì)于原始類型參數(shù)需要進(jìn)行裝箱操作new Object[] {new Integer(arg1), new Long(arg2), arg3});}catch(Throwable e) { // 異常處理 2（略）} // 第三步是返回結(jié)果（返回類型是原始類型則需要進(jìn)行拆箱操作）return ((Short)r).shortValue();} }

模擬推演為了突出通用邏輯所以更多地關(guān)注正常流程，而淡化了錯(cuò)誤處理，但在實(shí)際中錯(cuò)誤處理同樣非常重要。從以上的推演中我們可以得出一個(gè)非常通用的結(jié)構(gòu)化流程：第一步從代理接口獲取被調(diào)用的方法對(duì)象，第二步分派方法到調(diào)用處理器執(zhí)行，第三步返回結(jié)果。在這之中，所有的信息都是可以已知的，比如接口名、方法名、參數(shù)類型、返回類型以及所需的裝箱和拆箱操作，那么既然我們手工編寫是如此，那又有什么理由不相信 ProxyGenerator 不會(huì)做類似的實(shí)現(xiàn)呢？至少這是一種比較可能的實(shí)現(xiàn)。

接下來讓我們把注意力重新回到先前被淡化的錯(cuò)誤處理上來。在異常處理 1 處，由于我們有理由確保所有的信息如接口名、方法名和參數(shù)類型都準(zhǔn)確無誤，所以這部分異常發(fā)生的概率基本為零，所以基本可以忽略。而異常處理 2 處，我們需要思考得更多一些。回想一下，接口方法可能聲明支持一個(gè)異常列表，而調(diào)用處理器 invoke 方法又可能拋出與接口方法不支持的異常，再回想一下先前提及的 Java 動(dòng)態(tài)代理的關(guān)于異常處理的特點(diǎn)，對(duì)于不支持的異常，必須拋 UndeclaredThrowableException 運(yùn)行時(shí)異常。所以通過再次推演，我們可以得出一個(gè)更加清晰的異常處理 2 的情況：

清單 12. 細(xì)化的異常處理 2

Object r = null; try { r = handler.invoke(this, method, new Object[] {new Integer(arg1), new Long(arg2), arg3}); } catch( ExceptionA e) { // 接口方法支持 ExceptionA，可以拋出throw e; } catch( ExceptionB e ) { // 接口方法支持 ExceptionB，可以拋出throw e; } catch(Throwable e) { // 其他不支持的異常，一律拋 UndeclaredThrowableException throw new UndeclaredThrowableException(e); }

這樣我們就完成了對(duì)動(dòng)態(tài)代理類的推演實(shí)現(xiàn)。推演實(shí)現(xiàn)遵循了一個(gè)相對(duì)固定的模式，可以適用于任意定義的任何接口，而且代碼生成所需的信息都是可知的，那么有理由相信即使是機(jī)器自動(dòng)編寫的代碼也有可能延續(xù)這樣的風(fēng)格，至少可以保證這是可行的。

回頁首

美中不足

誠然，Proxy 已經(jīng)設(shè)計(jì)得非常優(yōu)美，但是還是有一點(diǎn)點(diǎn)小小的遺憾之處，那就是它始終無法擺脫僅支持 interface 代理的桎梏，因?yàn)樗脑O(shè)計(jì)注定了這個(gè)遺憾。回想一下那些動(dòng)態(tài)生成的代理類的繼承關(guān)系圖，它們已經(jīng)注定有一個(gè)共同的父類叫 Proxy。Java 的繼承機(jī)制注定了這些動(dòng)態(tài)代理類們無法實(shí)現(xiàn)對(duì) class 的動(dòng)態(tài)代理，原因是多繼承在 Java 中本質(zhì)上就行不通。

有很多條理由，人們可以否定對(duì) class 代理的必要性，但是同樣有一些理由，相信支持 class 動(dòng)態(tài)代理會(huì)更美好。接口和類的劃分，本就不是很明顯，只是到了 Java 中才變得如此的細(xì)化。如果只從方法的聲明及是否被定義來考量，有一種兩者的混合體，它的名字叫抽象類。實(shí)現(xiàn)對(duì)抽象類的動(dòng)態(tài)代理，相信也有其內(nèi)在的價(jià)值。此外，還有一些歷史遺留的類，它們將因?yàn)闆]有實(shí)現(xiàn)任何接口而從此與動(dòng)態(tài)代理永世無緣。如此種種，不得不說是一個(gè)小小的遺憾。

但是，不完美并不等于不偉大，偉大是一種本質(zhì)，Java 動(dòng)態(tài)代理就是佐例。

本文希望將 Java 動(dòng)態(tài)代理機(jī)制從接口擴(kuò)展到類，使得類能夠享有與接口類似的動(dòng)態(tài)代理支持。

設(shè)計(jì)及特點(diǎn)

新擴(kuò)展的類名為 ProxyEx，將直接繼承于 java.lang.reflect.Proxy，也聲明了與原 Proxy 類中同名的 public 靜態(tài)方法，目的是保持與原代理機(jī)制在使用方法上的完全一致。

圖 1. ProxyEx 類繼承圖

與原代理機(jī)制最大的區(qū)別在于，動(dòng)態(tài)生成的代理類將不再從 Proxy 類繼承，改而繼承需被代理的類。由于 Java 的單繼承原則，擴(kuò)展代理機(jī)制所支持的類數(shù)目不得多于一個(gè)，但它可以聲明實(shí)現(xiàn)若干接口。包管理的機(jī)制與原來相似，不支持一個(gè)以上的類和接口同時(shí)為非 public；如果僅有一個(gè)非 public 的類或接口，假設(shè)其包為 PackageA，則動(dòng)態(tài)生成的代理類將位于包 PackageA；否則將位于被代理的類所在的包。生成的代理類也被賦予 final 和 public 訪問屬性，且其命名規(guī)則類似地為“父類名 +ProxyN”（N 也是遞增的阿拉伯?dāng)?shù)字）。最后，在異常處理方面則與原來保持完全一致。

圖 2. 動(dòng)態(tài)生成的代理類的繼承圖

回頁首

模板

通過對(duì) Java 動(dòng)態(tài)代理機(jī)制的推演，我們已經(jīng)獲得了一個(gè)通用的方法模板。可以預(yù)期的是，通過模板來定制和引導(dǎo)代理類的代碼生成，是比較可行的方法。我們將主要使用兩個(gè)模板：類模板和方法模板。

清單 1. 類模板

package &Package; final public class &Name &Extends &Implements {private java.lang.reflect.InvocationHandler handler = null;&Constructors&Methods }

類模板定制了代理類的代碼框架。其中帶“&”前綴的標(biāo)簽位被用來引導(dǎo)相應(yīng)的代碼替換。在此預(yù)留了包（&Package）、類名（&ClassName）、類繼承（&Extends）、接口實(shí)現(xiàn)（&Implements）、構(gòu)造函數(shù)集（&Constructors）及方法集（&Methods）的標(biāo)簽位。類模板還同時(shí)聲明了一個(gè)私有型的調(diào)用處理器對(duì)象作為類成員。

清單 2. 方法模板

&Modifiers &ReturnType &MethodName(&Parameters) &Throwables {java.lang.reflect.Method method = null;try {method = &Class.getMethod( \"& MethodName\", &ParameterTypes );}catch(Exception e){}Object r = null;try{r = handler.invoke( this, method, &ParameterValues );}&Exceptions&Return }

方法模板定制了代理類方法集合中各個(gè)方法的代碼框架，同樣的帶“&”前綴的標(biāo)簽位被用來引導(dǎo)相應(yīng)的代碼替換。在此預(yù)留了修飾符（&Modifiers）、返回類型（&ReturnType）、方法名（&MethodName）、參數(shù)列表（Parameters）、異常列表（&Throwables）、方法的聲明類（&Class）、參數(shù)類型列表（&ParameterTypes）、調(diào)用處理器的參數(shù)值列表（&ParameterValues），異常處理（&Exceptions）及返回值（&Return）的標(biāo)簽位。

回頁首

代碼生成

有了類模板和方法模板，代碼生成過程就變得有章可依。基本過程可分為三步：1）生成代理類的方法集合；2）生成代理類的構(gòu)造函數(shù)；3）最后生成整個(gè)代理類。

生成代理類的方法集

第一步，通過反射獲得被代理類的所有 public 或 protected 且非 static 的 Method 對(duì)象列表，這些方法將被涵蓋的原因是它們是可以被其他類所訪問的。

第二步，遍歷 Method 對(duì)象列表，對(duì)每個(gè) Method 對(duì)象，進(jìn)行相應(yīng)的代碼生成工作。

清單 3. 對(duì)標(biāo)簽位進(jìn)行代碼替換生成方法代碼

String declTemplate = "&Modifiers &ReturnType &MethodName(&Parameters) &Throwables"; String bodyTemplate = "&Declaration &Body"; // 方法聲明 String declare = declTemplate.replaceAll("&Modifiers", getMethodModifiers( method )).replaceAll("&ReturnType", getMethodReturnType( method )).replaceAll("&MethodName", method.getName()).replaceAll("&Parameters", getMethodParameters( method )).replaceAll("&Throwables", getMethodThrowables( method ));// 方法聲明以及實(shí)現(xiàn) String body = bodyTemplate.replaceAll("&Declaration", declare ).replaceAll("&Body", getMethodEntity( method ));

這里涉及了一些 ProxyEx 類的私有的輔助函數(shù)如 getMethodModifiers 和 getMethodReturnType 等等，它們都是通過反射獲取所需的信息，然后動(dòng)態(tài)地生成各部分代碼。函數(shù) getMethodEntity 是比較重要的輔助函數(shù)，它又調(diào)用了其他的輔助函數(shù)來生成代碼并替換標(biāo)簽位。

清單 4. ProxyEx 的靜態(tài)方法 getMethodEntity()

private static String getMethodEntity( Method method ) {String template = "\n{"+ "\n java.lang.reflect.Method method = null;"+ "\n try{"+ "\n method = &Class.getMethod( \"&MethodName\", &ParameterTypes );"+ "\n }"+ "\n catch(Exception e){"+ "\n }"+ "\n Object r = null;"+ "\n try{" + "\n r = handler.invoke( this, method, &ParameterValues );"+ "\n }&Exceptions"+ "\n &Return"+ "\n}";String result = template.replaceAll("&MethodName", method.getName() ).replaceAll("&Class", method.getDeclaringClass().getName() + ".class").replaceAll("&ParameterTypes", getMethodParameterTypesHelper(method)).replaceAll("&ParameterValues", getMethodParameterValuesHelper(method) ).replaceAll("&Exceptions", getMethodParameterThrowablesHelper(method)).replaceAll("&Return", getMethodReturnHelper( method ) );return result; }

當(dāng)為 Class 類型對(duì)象生成該類型對(duì)應(yīng)的字符代碼時(shí)，可能涉及數(shù)組類型，反推過程會(huì)需要按遞歸方法生成代碼，這部分工作由 getTypeHelper 方法提供

清單 5. ProxyEx 的靜態(tài)方法 getTypeHelper()

private static String getTypeHelper(Class type) {if( type.isArray() ){Class c = type.getComponentType();return getTypeHelper(c) + "[]";}else{return type.getName();} }

第三步，將所生成的方法保存進(jìn)一個(gè) map 表，該表記錄的是鍵值對(duì)（方法聲明，方法實(shí)現(xiàn)）。由于類的多態(tài)性，父類的方法可能被子類所覆蓋，這時(shí)以上通過遍歷所得的方法列表中就會(huì)出現(xiàn)重復(fù)的方法對(duì)象，維護(hù)該表可以很自然地達(dá)到避免方法重復(fù)生成的目的，這就維護(hù)該表的原因所在。

生成代理類的構(gòu)造函數(shù)

相信讀者依然清晰記得代理類是通過其構(gòu)造函數(shù)反射生成的，而構(gòu)造時(shí)傳入的唯一參數(shù)就是調(diào)用處理器對(duì)象。為了保持與原代理機(jī)制的一致性，新的代理類的構(gòu)造函數(shù)也同樣只有一個(gè)調(diào)用處理器對(duì)象作為參數(shù)。模板簡單如下

清單 6. 構(gòu)造函數(shù)模板

public &Constructor(java.lang.reflect.InvocationHandler handler) { super(&Parameters); this.handler = handler; }

需要特別提一下的是 super 方法的參數(shù)值列表 &Parameters 的生成，我們借鑒了 Mock 思想，側(cè)重于追求對(duì)象構(gòu)造的成功，而并未過多地努力分析并尋求最準(zhǔn)確最有意義的賦值。對(duì)此，相信讀者會(huì)多少產(chǎn)生一些疑慮，但稍后我們會(huì)提及改進(jìn)的方法，請(qǐng)先繼續(xù)閱讀。

生成整個(gè)代理類

通過以上步驟，構(gòu)造函數(shù)和所有需被代理的方法的代碼已經(jīng)生成，接下來就是生成整個(gè)代理類的時(shí)候了。這個(gè)過程也很直觀，通過獲取相關(guān)信息并對(duì)類模板中各個(gè)標(biāo)簽位進(jìn)行替換，便可以輕松的完成整個(gè)代理類的代碼生成。

回頁首

被遺忘的角落：類變量

等等，似乎遺忘了什么？從調(diào)用者的角度出發(fā)，我們希望代理類能夠作為被代理類的如實(shí)代表呈現(xiàn)在用戶面前，包括其內(nèi)部狀態(tài)，而這些狀態(tài)通常是由類變量所體現(xiàn)出來的，于是就涉及到類變量的代理問題。

要解決這個(gè)問題，首先需要思考何時(shí)兩者的類變量可能出現(xiàn)不一致？回答了這個(gè)問題，也就找到了解決思路。回顧代理類的構(gòu)造函數(shù)，我們以粗糙的方式構(gòu)造了代理類實(shí)例。它們可能一開始就已經(jīng)不一致了。還有每次方法調(diào)用也可能導(dǎo)致被兩者的類變量的不一致。如何解決？直觀的想法是：1）構(gòu)造時(shí)需設(shè)法進(jìn)行同步；2）方法調(diào)用之前和之后也需設(shè)法進(jìn)行同步。這樣，我們就能夠有效避免代理類和被代理類的類變量不一致的問題的出現(xiàn)了。

但是，如何獲得被代理類的實(shí)例呢？從當(dāng)前的的設(shè)計(jì)中已經(jīng)沒有辦法做到。既然如此，那就繼續(xù)我們的擴(kuò)展之旅。只不過這次擴(kuò)展的對(duì)象是調(diào)用處理器接口，我們將在擴(kuò)展后的接口里加入獲取被代理類對(duì)象的方法，且擴(kuò)展調(diào)用處理器接口將以 static 和 public 的形式被定義在 ProxyEx 類中。

清單 7. ProxyEx 類內(nèi)的靜態(tài)接口 InvocationHandlerEx

public static interface InvocationHandlerEx extends InvocationHandler { // 返回指定 stubClass 參數(shù)所對(duì)應(yīng)的被代理類實(shí)體對(duì)象Object getStub(Class stubClass); }

新的調(diào)用處理器接口具備了獲取被代理類對(duì)象的能力，從而為實(shí)現(xiàn)類變量的同步打開了通道。接下來還需要的就是執(zhí)行類變量同步的 sync 方法，每個(gè)動(dòng)態(tài)生成的代理類中都會(huì)被悄悄地加入這個(gè)私有方法以供調(diào)用。每次方法被分派轉(zhuǎn)發(fā)到調(diào)用處理器執(zhí)行之前和之后，sync 方法都會(huì)被調(diào)用，從而保證類變量的雙向?qū)崟r(shí)更新。相應(yīng)的，方法模板也需要更新以支持該新特性。

清單 8. 更新后的方法模板（部分）

Object r = null; try{// 代理類到被代理類方向的變量同步sync(&Class, true);r = handler.invoke( this, method, &ParameterValues );// 被代理類到代理類方向的變量同步sync(&Class, false); }&Exceptions&Return

sync 方法還會(huì)在構(gòu)造函數(shù)尾部被調(diào)用，從而將被代理類對(duì)象的變量信息同步到代理類對(duì)象，實(shí)現(xiàn)類似于拷貝構(gòu)造的等價(jià)效果。相應(yīng)的，構(gòu)造函數(shù)模板也需要更新以支持該新特性。

清單 9. 更新后的構(gòu)造函數(shù)模板

public &Name(java.lang.reflect.InvocationHandler handler) {super(&Parameters);this.handler = handler;// 被代理類到代理類方向的變量同步sync(null, false); }

接下來介紹 sync 方法的實(shí)現(xiàn)，其思想就是首先獲取被代理類的所有 Field 對(duì)象的列表，并通過擴(kuò)展的調(diào)用處理器獲得方法的聲明類說對(duì)應(yīng)的 stub 對(duì)象，然后遍歷 Field 對(duì)象列表并對(duì)各個(gè)變量進(jìn)行拷貝同步。

清單 10. 聲明在動(dòng)態(tài)生成的代理類內(nèi)部的 snyc 函數(shù)

private synchronized void sync(java.lang.Class clazz, boolean toStub) {// 判斷是否為擴(kuò)展調(diào)用處理器if( handler instanceof InvocationHandlerEx ){java.lang.Class superClass = this.getClass().getSuperclass();java.lang.Class stubClass = ( clazz != null ? clazz : superClass );// 通過擴(kuò)展調(diào)用處理器獲得stub對(duì)象Object stub = ((InvocationHandlerEx)handler).getStub(stubClass);if( stub != null ){// 獲得所有需同步的類成員列表，遍歷并同步j(luò)ava.lang.reflect.Field[] fields = getFields(superClass);for(int i=0; fields!=null&&i<fields.length; i++){try{fields[i].setAccessible(true);// 執(zhí)行代理類和被代理類的變量同步if(toStub){fields[i].set(stub, fields[i].get(this));}else{fields[i].set(this, fields[i].get(stub));}}catch(Throwable e){}}}} }

這里涉及到一個(gè)用于獲取類的所有 Field 對(duì)象列表的靜態(tài)輔助方法 getFields。為了提高頻繁查詢時(shí)的性能，配合該靜態(tài)方法的是一個(gè)靜態(tài)的 fieldsMap 對(duì)象，用于記錄已查詢過的類其所包含的 Field 對(duì)象列表，使得再次查詢時(shí)能迅速返回其對(duì)應(yīng)列表。相應(yīng)的，類模板也需進(jìn)行更新。

清單 11. 增加了靜態(tài) fieldsMap 變量后的類模板

package &Package; final public class &Name &Extends &Implements {private static java.util.HashMap fieldsMap = new java.util.HashMap();private java.lang.reflect.InvocationHandler handler = null;&Constructors&Methods }

清單 12. 聲明在動(dòng)態(tài)生成的代理類內(nèi)部的靜態(tài)方法 getFields

private static java.lang.reflect.Field[] getFields(java.lang.Class c) {if( fieldsMap.containsKey(c) ){return (java.lang.reflect.Field[])fieldsMap.get(c);}java.lang.reflect.Field[] fields = null;if( c == java.lang.Object.class ){fields = c.getDeclaredFields();}else{java.lang.reflect.Field[] fields0 = getFields(c.getSuperclass());java.lang.reflect.Field[] fields1 = c.getDeclaredFields();fields = new java.lang.reflect.Field[fields0.length + fields1.length];System.arraycopy(fields0, 0, fields, 0, fields0.length);System.arraycopy(fields1, 0, fields, fields0.length, fields1.length);}fieldsMap.put(c, fields);return fields; }

回頁首

動(dòng)態(tài)編譯及裝載

代碼生成以后，需要經(jīng)過編譯生成 JVM 所能識(shí)別的字節(jié)碼，而字節(jié)碼還需要通過類裝載器載入 JVM 才能最終被真正使用，接下來我們將闡述如何動(dòng)態(tài)編譯及裝載。

首先是動(dòng)態(tài)編譯。這部分由 ProxyEx 類的 getProxyClassCodeSource 函數(shù)完成。該函數(shù)分三步進(jìn)行：第一步保存源代碼到 .java 文件；第二步編譯該 .java 文件；第三步從輸出的 .class 文件讀取字節(jié)碼。

清單 13. ProxyEx 的靜態(tài)方法 getProxyClassCodeSource

private static byte[] getProxyClassCodeSource( String pkg, String className, String declare ) throws Exception {// 將類的源代碼保存進(jìn)一個(gè)名為類名加“.java”的本地文件File source = new File(className + ".java");FileOutputStream fos = new FileOutputStream( source );fos.write( declare.getBytes() );fos.close();// 調(diào)用com.sun.tools.javac.Main類的靜態(tài)方法compile進(jìn)行動(dòng)態(tài)編譯int status = com.sun.tools.javac.Main.compile( new String[] { "-d", ".", source.getName() } );if( status != 0 ){source.delete();throw new Exception("Compiler exit on " + status);}// 編譯得到的字節(jié)碼將被輸出到與包結(jié)構(gòu)相同的一個(gè)本地目錄，文件名為類名加”.class”String output = ".";int curIndex = -1;int lastIndex = 0;while( (curIndex=pkg.indexOf('.', lastIndex)) != -1 ){output = output + File.separator + pkg.substring( lastIndex, curIndex );lastIndex = curIndex + 1;}output = output + File.separator + pkg.substring( lastIndex );output = output + File.separator + className + ".class";// 從輸出文件中讀取字節(jié)碼，并存入字節(jié)數(shù)組File target = new File(output);FileInputStream f = new FileInputStream( target );byte[] codeSource = new byte[(int)target.length()];f.read( codeSource );f.close();// 刪除臨時(shí)文件source.delete();target.delete();return codeSource; }

得到代理類的字節(jié)碼，接下來就可以動(dòng)態(tài)裝載該類了。這部分由 ProxyEx 類的 defineClassHelper 函數(shù)完成。該函數(shù)分兩步進(jìn)行：第一步通過反射獲取父類 Proxy 的靜態(tài)私有方法 defineClass0；第二步傳入字節(jié)碼數(shù)組及其他相關(guān)信息并反射調(diào)用該方法以完成類的動(dòng)態(tài)裝載。

清單 14. ProxyEx 的靜態(tài)方法 defineClassHelper

private static Class defineClassHelper( String pkg, String cName, byte[] codeSource ) throws Exception {Method defineClass = Proxy.class.getDeclaredMethod( "defineClass0", new Class[] { ClassLoader.class, String.class,byte[].class,int.class,int.class } );defineClass.setAccessible(true);return (Class)defineClass.invoke( Proxy.class, new Object[] { ProxyEx.class.getClassLoader(), pkg.length()==0 ? cName : pkg+"."+cName,codeSource,new Integer(0),new Integer(codeSource.length) } ); }

回頁首

性能改進(jìn)

原動(dòng)態(tài)代理機(jī)制中對(duì)接口數(shù)組有一些有趣的特點(diǎn)，其中之一就是接口的順序差異會(huì)在一定程度上導(dǎo)致生成新的代理類，即使其實(shí)并無必要。其中的原因就是因?yàn)榫彺姹硎且越涌诿Q列表作為關(guān)鍵字，所以不同的順序就意味著不同的關(guān)鍵字，如果對(duì)應(yīng)的關(guān)鍵字不存在，就會(huì)生成新但是作用重復(fù)的代理類。在 ProxyEx 類中，我們通過主動(dòng)排序避免了類似的問題，提高動(dòng)態(tài)生成代理類的效率。而且，如果發(fā)現(xiàn)數(shù)組中都是接口類型，則直接調(diào)用父類 Proxy 的靜態(tài)方法 getProxyClass 生成代理類，否則才通過擴(kuò)展動(dòng)態(tài)代理機(jī)制生成代理類，這樣也一定程度上改進(jìn)了性能。

回頁首

兼容性問題

接下來需要考慮的是與原代理機(jī)制的兼容性問題。曾記否，Proxy 中還有兩個(gè)靜態(tài)方法：isProxyClass 和 getInvocationHandler，分別被用于判斷 Class 對(duì)象是否是動(dòng)態(tài)代理類和從 Object 對(duì)象獲取對(duì)應(yīng)的調(diào)用處理器（如果可能的話）。

清單 15. Proxy 的靜態(tài)方法 isProxyClass 和 getInvocationHandler

static boolean isProxyClass(Class cl) static InvocationHandler getInvocationHandler(Object proxy)

現(xiàn)在的兼容性問題，主要涉及到 ProxyEx 類與父類 Proxy 在關(guān)于動(dòng)態(tài)生成的代理類的信息方面所面臨的如何保持同步的問題。曾介紹過，在 Proxy 類中有個(gè)私有的 Map 對(duì)象 proxyClasses 專門負(fù)責(zé)保存所有動(dòng)態(tài)生成的代理類類型。Proxy 類的靜態(tài)函數(shù) isProxyClass 就是通過查詢?cè)摫硪源_定某 Class 對(duì)象是否為動(dòng)態(tài)代理類，我們需要做的就是把由 ProxyEx 生成的代理類類型也保存入該表。這部分工作由 ProxyEx 類的靜態(tài)方法 addProxyClass 輔助完成。

清單 16. ProxyEx 的靜態(tài)方法 addProxyClass

private static void addProxyClass( Class proxy ) throws IllegalArgumentException { try { // 通過反射獲取父類的私有 proxyClasses 變量并更新Field proxyClasses = Proxy.class.getDeclaredField("proxyClasses"); proxyClasses.setAccessible(true); ((Map)proxyClasses.get(Proxy.class)).put( proxy, null ); } catch(Exception e) { throw new IllegalArgumentException(e.toString()); } }

相對(duì)而言，原來 Proxy 類的靜態(tài)方法 getInvocationHandler 實(shí)現(xiàn)相當(dāng)簡單，先判斷是否為代理類，若是則直接類型轉(zhuǎn)換到 Proxy 并返回其調(diào)用處理器成員，而擴(kuò)展后的代理類并不非從 Proxy 類繼承，所以在獲取調(diào)用處理器對(duì)象的方法上需要一些調(diào)整。這部分由 ProxyEx 類的同名靜態(tài)方法 getInvocationHandler 完成。

清單 17. ProxyEx 的靜態(tài)方法 getInvocationHandler

public static InvocationHandler getInvocationHandler(Object proxy) throws IllegalArgumentException {// 如果Proxy實(shí)例，直接調(diào)父類的方法if( proxy instanceof Proxy ) {return Proxy.getInvocationHandler( proxy );}// 如果不是代理類，拋異常if( !Proxy.isProxyClass( proxy.getClass() )){throw new IllegalArgumentException("Not a proxy instance");}try {// 通過反射獲取擴(kuò)展代理類的調(diào)用處理器對(duì)象Field invoker = proxy.getClass().getDeclaredField("handler");invoker.setAccessible(true);return (InvocationHandler)invoker.get(proxy);}catch(Exception e){throw new IllegalArgumentException("Suspect not a proxy instance");} }

回頁首

坦言：也有局限

受限于 Java 的類繼承機(jī)制，擴(kuò)展的動(dòng)態(tài)代理機(jī)制也有其局限，它不能支持：

聲明為 final 的類；

聲明為 final 的函數(shù)；

構(gòu)造函數(shù)均為 private 類型的類；

回頁首

實(shí)例演示

闡述了這么多，相信讀者一定很想看一下擴(kuò)展動(dòng)態(tài)代理機(jī)制是如何工作的。本文最后將以 2010 世博門票售票代理為模型進(jìn)行演示。

首先，我們定義了一個(gè)售票員抽象類 TicketSeller。

清單 18. TicketSeller

public abstract class TicketSeller {protected String theme;protected TicketSeller(String theme){this.theme = theme;}public String getTicketTheme(){return this.theme;}public void setTicketTheme(String theme){this.theme = theme;}public abstract int getTicketPrice();public abstract int buy(int ticketNumber, int money) throws Exception; }

其次，我們會(huì)實(shí)現(xiàn)一個(gè) 2010 世博門票售票代理類 Expo2010TicketSeller。

清單 19. Expo2010TicketSeller

public class Expo2010TicketSeller extends TicketSeller {protected int price;protected int numTicketForSale;public Expo2010TicketSeller(){super("World Expo 2010");this.price = 180;this.numTicketForSale = 200;}public int getTicketPrice(){return price;}public int buy(int ticketNumber, int money) throws Exception{if( ticketNumber > numTicketForSale ){throw new Exception("There is no enough ticket available for sale, only " + numTicketForSale + " ticket(s) left");}int charge = money - ticketNumber * price;if( charge < 0 ){throw new Exception("Money is not enough. Still needs " + (-charge) + " RMB.");}numTicketForSale -= ticketNumber;return charge;} }

接著，我們將通過購票者類 TicketBuyer 來模擬購票以演示擴(kuò)展動(dòng)態(tài)代理機(jī)制。

清單 20. TicketBuyer

public class TicketBuyer {public static void main(String[] args) {// 創(chuàng)建真正的TickerSeller對(duì)象，作為stub實(shí)體final TicketSeller stub = new Expo2010TicketSeller();// 創(chuàng)建擴(kuò)展調(diào)用處理器對(duì)象InvocationHandler handler = new InvocationHandlerEx(){public Object getStub(Class stubClass) {// 僅對(duì)可接受的Class類型返回stub實(shí)體if( stubClass.isAssignableFrom(stub.getClass()) ){return stub;}return null;}public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {Object o;try{System.out.println(" >>> Enter method: " + method.getName() );o = method.invoke(stub, args);}catch(InvocationTargetException e){throw e.getCause();}finally{System.out.println(" <<< Exit method: " + method.getName() );}return o;}};// 通過ProxyEx構(gòu)造動(dòng)態(tài)代理TicketSeller seller = (TicketSeller)ProxyEx.newProxyInstance(TicketBuyer.class.getClassLoader(), new Class[] {TicketSeller.class}, handler);// 顯示代理類的類型System.out.println("Ticket Seller Class: " + seller.getClass() + "\n");// 直接訪問theme變量，驗(yàn)證代理類變量在對(duì)象構(gòu)造時(shí)同步的有效性System.out.println("Ticket Theme: " + seller.theme + "\n");// 函數(shù)訪問price信息System.out.println("Query Ticket Price...");System.out.println("Ticket Price: " + seller.getTicketPrice() + " RMB\n");// 模擬票務(wù)交易buyTicket(seller, 1, 200);buyTicket(seller, 1, 160);buyTicket(seller, 250, 30000);// 直接更新theme變量System.out.println("Updating Ticket Theme...\n");seller.theme = "World Expo 2010 in Shanghai";// 函數(shù)訪問theme信息，驗(yàn)證擴(kuò)展動(dòng)態(tài)代理機(jī)制對(duì)變量同步的有效性System.out.println("Query Updated Ticket Theme...");System.out.println("Updated Ticket Theme: " + seller.getTicketTheme() + "\n"); }// 購票函數(shù)protected static void buyTicket(TicketSeller seller, int ticketNumber, int money){try {System.out.println("Transaction: Order " + ticketNumber + " ticket(s) with " + money + " RMB");int charge = seller.buy(ticketNumber, money);System.out.println("Transaction: Succeed - Charge is " + charge + " RMB\n");} catch (Exception e) {System.out.println("Transaction: Fail - " + e.getMessage() + "\n");} } }

最后，見演示程序的執(zhí)行結(jié)果。

清單 21. 執(zhí)行輸出

Ticket Seller Class: class com.demo.proxy.test.TicketSellerProxy0Ticket Theme: World Expo 2010Query Ticket Price...>>> Enter method: getTicketPrice<<< Exit method: getTicketPrice Ticket Price: 180 RMBTransaction: Order 1 ticket(s) with 200 RMB>>> Enter method: buy<<< Exit method: buy Transaction: Succeed - Charge is 20 RMBTransaction: Order 1 ticket(s) with 160 RMB>>> Enter method: buy<<< Exit method: buy Transaction: Fail - Money is not enough. Still needs 20 RMB.Transaction: Order 250 ticket(s) with 30000 RMB>>> Enter method: buy<<< Exit method: buy Transaction: Fail - There is no enough ticket available for sale, only 199 ticket(s) leftUpdating Ticket Theme...Query Updated Ticket Theme...>>> Enter method: getTicketTheme<<< Exit method: getTicketTheme Updated Ticket Theme: World Expo 2010 in Shanghai

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/3474867.html

總結(jié)

以上是生活随笔為你收集整理的Java 动态代理机制分析及扩展--转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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

上一篇： java实现插入排序算法附单元测试源码
下一篇：也谈BIO | NIO | AIO （J