Java 1.5中面向方面(AOP)編程

　　對于一個能夠訪問源代碼的經(jīng)驗豐富的Java開發(fā)人員來說，任何程序都可以被看作是博物館里透明的模型。類似線程轉(zhuǎn)儲（dump）、方法調(diào)用跟蹤、斷點、切面（profiling）統(tǒng)計表等工具可以讓我們了解程序目前正在執(zhí)行什么操作、剛才做了什么操作、未來將做什么操作。但是在產(chǎn)品環(huán)境中情況就沒有那么明顯了，這些工具一般是不能夠使用的，或最多只能由受過訓(xùn)練的開發(fā)者使用。支持團隊和最終用戶也需要知道在某個時刻應(yīng)用程序正在執(zhí)行什么操作。

　　為了填補這個空缺，我們已經(jīng)發(fā)明了一些簡單的替代品，例如日志文件（典型情況下用于服務(wù)器處理）和狀態(tài)條（用于GUI應(yīng)用程序）。但是，由于這些工具只能捕捉和報告可用信息的一個很小的子集，并且通常必須把這些信息用容易理解的方式表現(xiàn)出來，所以程序員趨向于把它們明確地編寫到應(yīng)用程序中。而這些代碼會纏繞著應(yīng)用程序的業(yè)務(wù)邏輯，當(dāng)開發(fā)者試圖調(diào)試或了解核心功能的時候，他們必須"圍繞這些代碼工作"，而且還要記得功能發(fā)生改變后更新這些代碼。我們希望實現(xiàn)的真正功能是把狀態(tài)報告集中在某個位置，把單個狀態(tài)消息作為元數(shù)據(jù)（metadata）來管理。

　　在本文中我將考慮使用嵌入GUI應(yīng)用程序中的狀態(tài)條組件的情形。我將介紹多種實現(xiàn)這種狀態(tài)報告的不同方法，從傳統(tǒng)的硬編碼習(xí)慣開始。隨后我會介紹Java 1.5的大量新特性，包括注解（annotation）和運行時字節(jié)碼重構(gòu)（instrumentation）。
　　狀態(tài)管理器（StatusManager）

　　我的主要目標(biāo)是建立一個可以嵌入GUI應(yīng)用程序的JStatusBar Swing組件。圖1顯示了一個簡單的Jframe中狀態(tài)條的樣式。

　　圖1.我們動態(tài)生成的狀態(tài)條

　　由于我不希望直接在業(yè)務(wù)邏輯中引用任何GUI組件，我將建立一個StatusManager（狀態(tài)管理器）來充當(dāng)狀態(tài)更新的入口點。實際的通知會被委托給StatusState對象，因此以后可以擴展它以支持多個并發(fā)的線程。圖2顯示了這種安排。

　　圖2. StatusManager和JstatusBar

　　現(xiàn)在我必須編寫代碼調(diào)用StatusManager的方法來報告應(yīng)用程序的進程。典型情況下，這些方法調(diào)用都分散地貫穿于try-finally代碼塊中，通常每個方法一個調(diào)用。

　　public void connectToDB (String url) {
　　StatusManager.push("Connecting to database");
　　try {
　　...
　　} finally {
　　StatusManager.pop();
　　}
　　}

　　這些代碼實現(xiàn)了我們所需要功能，但是在代碼庫中數(shù)十次、甚至于數(shù)百次地復(fù)制這些代碼之后，它看起來就有些混亂了。此外，如果我們希望用一些其它的方式訪問這些消息該怎么辦呢？在本文的后面部分中，我將定義一個用戶友好的異常處理程序，它共享了相同的消息。問題是我把狀態(tài)消息隱藏在方法的實現(xiàn)之中了，而沒有把消息放在消息所屬的接口中。

　　面向?qū)傩跃幊?/strong>

　　我真正想實現(xiàn)的操作是把對StatusManager的引用都放到代碼外面的某個地方，并簡單地用我們的消息標(biāo)記這個方法。接著我可以使用代碼生成（code-generation）或運行時反�。╥ntrospection）來執(zhí)行真正的工作。XDoclet項目把這種方法歸納為面向?qū)傩跃幊蹋ˋttribute-Oriented Programming），它還提供了一個框架組件，可以把自定義的類似Javadoc的標(biāo)記轉(zhuǎn)換到源代碼之中。

　　但是，JSR-175包含了這樣的內(nèi)容，Java 1.5為了包含真實代碼中的這些屬性提供了一種結(jié)構(gòu)化程度更高的格式。這些屬性被稱為"注解（annotations）"，我們可以使用它們?yōu)轭�、方法、字段或變量定義提供元數(shù)據(jù)。它們必須被顯式聲明，并提供一組可以包含任意常量值（包括原語、字符串、枚舉和類）的名稱-值對（name-value pair）。

　　注解（Annotations）

　　為了處理狀態(tài)消息，我希望定義一個包含字符串值的新注解。注解的定義非常類似接口的定義，但是它用@interface關(guān)鍵字代替了interface，并且只支持方法（盡管它們的功能更像字段）：

　　public @interface Status {
　　String value();
　　}

　　與接口類似，我把@interface放入一個叫做Status.java的文件中，并把它導(dǎo)入到任何需要引用它的文件中。

　　對我們的字段來說，value可能是個奇怪的名稱。類似message的名稱可能更適合；但是，value對于Java來說具有特殊的意義。它允許我們使用@Status("...")代替@Status(value="...")來定義注解，這明顯更加簡捷。

　　我現(xiàn)在可以使用下面的代碼定義自己的方法：

　　@Status("Connecting to database")
　　public void connectToDB (String url) {
　　...
　　}

　　請注意，我們在編譯這段代碼的時候必須使用-source 1.5選項。如果你使用Ant而不是直接使用javac命令行建立應(yīng)用程序，那么你需要使用Ant 1.6.1以上版本。

　　作為類、方法、字段和變量的補充，注解也可以用于為其它的注解提供元數(shù)據(jù)。特別地，Java引入了少量注解，你可以使用這些注解來定制你自己的注解的工作方式。我們用下面的代碼重新定義自己的注解：

　　@Target(ElementType.METHOD)
　　@Retention(RetentionPolicy.SOURCE)
　　public @interface Status {
　　String value();
　　}


　　@Target注解定義了@Status注解可以引用什么內(nèi)容。理想情況下，我希望標(biāo)記大塊的代碼，但是它的選項只有方法、字段、類、本地變量、參數(shù)和其它注解。我只對代碼感興趣，因此我選擇了METHOD（方法）。
　　
　　@Retention注解允許我們指定Java什么時候可以自主地拋棄消息。它可能是SOURCE（在編譯時拋棄）、CLASS（在類載入時拋棄）或RUNTIME（不拋棄）。我們先選擇SOURCE，但是在本文后部我們會更新它。
　　 重構(gòu)源代碼

　　現(xiàn)在我的消息都被編碼放入元數(shù)據(jù)中了，我必須編寫一些代碼來通知狀態(tài)監(jiān)聽程序。假設(shè)在某個時候，我繼續(xù)把connectToDB方法保存源代碼控件中，但是卻沒有對StatusManager的任何引用。但是，在編譯這個類之前，我希望加入一些必要的調(diào)用。也就是說，我希望自動地插入try-finally語句和push/pop調(diào)用。

　　XDoclet框架組件是一種Java源代碼生成引擎，它使用了類似上述的注解，但是把它們存儲在Java源代碼的注釋（comment）中。XDoclet生成整個Java類、配置文件或其它建立的部分的時候非常完美，但是它不支持對已有Java類的修改，而這限制了重構(gòu)的有效性。作為代替，我可以使用分析工具（例如JavaCC或ANTLR，它提供了分析Java源代碼的語法基礎(chǔ)），但是這需要花費大量精力。

　　看起來沒有什么可以用于Java代碼的源代碼重構(gòu)的很好的工具。這類工具可能有市場，但是你在本文的后面部分可以看到，字節(jié)碼重構(gòu)可能是一種更強大的技術(shù)。 重構(gòu)字節(jié)碼

　　不是重構(gòu)源代碼然后編譯它，而是編譯原始的源代碼，然后重構(gòu)它所產(chǎn)生的字節(jié)碼。這樣的操作可能比源代碼重構(gòu)更容易，也可能更加復(fù)雜，而這依賴于需要的準(zhǔn)確轉(zhuǎn)換。字節(jié)碼重構(gòu)的主要優(yōu)點是代碼可以在運行時被修改，不需要使用編譯器。

　　盡管Java的字節(jié)碼格式相對簡單，我還是希望使用一個Java類庫來執(zhí)行字節(jié)碼的分析和生成（這可以把我們與未來Java類文件格式的改變隔離開來）。我選擇了使用Jakarta的Byte Code Engineering Library（字節(jié)碼引擎類庫，BCEL），但是我還可以選用CGLIB、ASM或SERP。

　　由于我將使用多種不同的方式重構(gòu)字節(jié)碼，我將從聲明重構(gòu)的通用接口開始。它類似于執(zhí)行基于注解重構(gòu)的簡單框架組件。這個框架組件基于注解，將支持類和方法的轉(zhuǎn)換，因此該接口有類似下面的定義：


　　public interface Instrumentor
　　{
　　public void instrumentClass (ClassGen classGen,Annotation a);
　　public void instrumentMethod (ClassGen classGen,MethodGen methodGen,Annotation a);
　　}


　　ClassGen和MethodGen都是BCEL類，它們使用了Builder模式（pattern）。也就是說，它們?yōu)楦淖兤渌�不可變的（immutable）對象、以及可變的和不可變的表現(xiàn)（representation）之間的轉(zhuǎn)換提供了方法。

　　現(xiàn)在我需要為接口編寫實現(xiàn)，它必須用恰當(dāng)?shù)腟tatusManager調(diào)用更換@Status注解。前面提到，我希望把這些調(diào)用包含在try-finally代碼塊中。請注意，要達到這個目標(biāo)，我們所使用的注解必須用@Retention(RetentionPolicy.CLASS)進行標(biāo)記，它指示Java編譯器在編譯過程中不要拋棄注解。由于在前面我把@Status聲明為@Retention(RetentionPolicy.SOURCE)的，我必須更新它。

　　在這種情況下，重構(gòu)字節(jié)碼明顯比重構(gòu)源代碼更復(fù)雜。其原因在于try-finally是一種僅僅存在于源代碼中的概念。Java編譯器把try-finally代碼塊轉(zhuǎn)換為一系列的try-catch代碼塊，并在每一個返回之前插入對finally代碼塊的調(diào)用。因此，為了把try-finally代碼塊添加到已有的字節(jié)碼中，我也必須執(zhí)行類似的事務(wù)。

　　下面是表現(xiàn)一個普通方法調(diào)用的字節(jié)碼，它被StatusManager更新環(huán)繞著：


　　0: ldc #2; //字符串消息
　　2: invokestatic #3; //方法StatusManager.push:(LString;)V
　　5: invokestatic #4; //方法 doSomething:()V
　　8: invokestatic #5; //方法 StatusManager.pop:()V
　　11: return


　　下面是相同的方法調(diào)用，但是位于try-finally代碼塊中，因此，如果它產(chǎn)生了異常會調(diào)用StatusManager.pop()：


　　0: ldc #2; //字符串消息
　　2: invokestatic #3; //方法 StatusManager.push:(LString;)V
　　5: invokestatic #4; //方法 doSomething:()V
　　8: invokestatic #5; //方法 StatusManager.pop:()V
　　11: goto 20
　　14: astore_0
　　15: invokestatic #5; //方法 StatusManager.pop:()V
　　18: aload_0
　　19: athrow
　　20: return

　　Exception table:
　　from to target type
　　5 8 14 any
　　14 15 14 any


　　你可以發(fā)現(xiàn)，為了實現(xiàn)一個try-finally，我必須復(fù)制一些指令，并添加了幾個跳轉(zhuǎn)和異常表記錄。幸運的是，BCEL的InstructionList類使這種工作相當(dāng)簡單。

　　在運行時重構(gòu)字節(jié)碼

　　現(xiàn)在我擁有了一個基于注解修改類的接口和該接口的具體實現(xiàn)了，下一步是編寫調(diào)用它的實際框架組件。實際上我將編寫少量的框架組件，先從運行時重構(gòu)所有類的框架組件開始。由于這種操作會在build過程中發(fā)生，我決定為它定義一個Ant事務(wù)。build.xml文件中的重構(gòu)目標(biāo)的聲明應(yīng)該如下：


　�。糹nstrument class="com.pkg.OurInstrumentor"＞
　�。糵ileset dir="$(classes.dir)"＞
　�。糹nclude name="**/*.class"/＞
　　＜/fileset＞
　�。�/instrument＞


　　為了實現(xiàn)這種事務(wù)，我必須定義一個實現(xiàn)org.apache.tools.ant.Task接口的類。我們的事務(wù)的屬性和子元素（sub-elements）都是通過set和add方法調(diào)用傳遞進來的。我們調(diào)用執(zhí)行（execute）方法來實現(xiàn)事務(wù)所要執(zhí)行的工作--在示例中，就是重構(gòu)＜fileset＞中指定的類文件。


　　public class InstrumentTask extends Task {
　　...
　　public void setClass (String className) { ... }
　　public void addFileSet (FileSet fileSet) { ... }

　　public void execute () throws BuildException {
　　Instrumentor inst = getInstrumentor();

　　try {
　　　DirectoryScanner ds =fileSet.getDirectoryScanner(project);
　　　// Java 1.5 的"for" 語法
　　　for (String file : ds.getIncludedFiles()) {
　　　　instrumentFile(inst, file);
　　　}
　　} catch (Exception ex) {
　　　throw new BuildException(ex);
　　}
　　}
　　...
　　}


　　用于該項操作的BCEL 5.1版本有一個問題--它不支持分析注解。我可以載入正在重構(gòu)的類并使用反射（reflection）查看注解。但是，如果這樣，我就不得不使用RetentionPolicy.RUNTIME來代替RetentionPolicy.CLASS。我還必須在這些類中執(zhí)行一些靜態(tài)的初始化，而這些操作可能載入本地類庫或引入其它的依賴關(guān)系。幸運的是，BCEL提供了一種插件（plugin）機制，它允許客戶端分析字節(jié)碼屬性。我編寫了自己的AttributeReader的實現(xiàn)（implementation），在出現(xiàn)注解的時候，它知道如何分析插入字節(jié)碼中的RuntimeVisibleAnnotations和RuntimeInvisibleAnnotations屬性。BCEL未來的版本應(yīng)該會包含這種功能而不是作為插件提供。

　　編譯時刻的字節(jié)碼重構(gòu)方法顯示在示例代碼的code/02_compiletime目錄中。

　　但是這種方法有很多缺陷。首先，我必須給建立過程增加額外的步驟。我不能基于命令行設(shè)置或其它編譯時沒有提供的信息來決定打開或關(guān)閉重構(gòu)操作。如果重構(gòu)的或沒有重構(gòu)的代碼需要同時在產(chǎn)品環(huán)境中運行，那么就必須建立兩個單獨的.jars文件，而且還必須決定使用哪一個。
　　 　在類載入時重構(gòu)字節(jié)碼

　　更好的方法可能是延遲字節(jié)碼重構(gòu)操作，直到字節(jié)碼被載入的時候才進行重構(gòu)。使用這種方法的時候，重構(gòu)的字節(jié)碼不用保存起來。我們的應(yīng)用程序啟動時刻的性能可能會受到影響，但是你卻可以基于自己的系統(tǒng)屬性或運行時配置數(shù)據(jù)來控制進行什么操作。

　　 Java 1.5之前，我們使用定制的類載入程序可能實現(xiàn)這種類文件維護操作。但是Java 1.5中新增加的java.lang.instrument程序包提供了少數(shù)附加的工具。特別地，它定義了ClassFileTransformer的概念，在標(biāo)準(zhǔn)的載入過程中我們可以使用它來重構(gòu)一個類。

　　為了在適當(dāng)?shù)臅r候（在載入任何類之前）注冊ClassFileTransformer，我需要定義一個premain方法。Java在載入主類（main class）之前將調(diào)用這個方法，并且它傳遞進來對Instrumentation對象的引用。我還必須給命令行增加-javaagent參數(shù)選項，告訴Java我們的premain方法的信息。這個參數(shù)選項把我們的agent class（代理類，它包含了premain方法）的全名和任意字符串作為參數(shù)。在例子中我們把Instrumentor類的全名作為參數(shù)（它必須在同一行之中）：


　　-javaagent:boxpeeking.instrument.InstrumentorAdaptor=
　　boxpeeking.status.instrument.StatusInstrumentor


　　現(xiàn)在我已經(jīng)安排了一個回調(diào)（callback），它在載入任何含有注解的類之前都會發(fā)生，并且我擁有Instrumentation對象的引用，可以注冊我們的ClassFileTransformer了：


　　public static void premain (String className,
　　Instrumentation i)
　　throws ClassNotFoundException,
　　InstantiationException,
　　IllegalAccessException
　　{
　　Class instClass = Class.forName(className);
　　Instrumentor inst = (Instrumentor)instClass.newInstance();
　　i.addTransformer(new InstrumentorAdaptor(inst));
　　}


　　我們在此處注冊的適配器將充當(dāng)上面給出的Instrumentor接口和Java的ClassFileTransformer接口之間的橋梁。


　　public class InstrumentorAdaptor
　　implements ClassFileTransformer
　　{
　　public byte[] transform (ClassLoader cl,String className,Class classBeingRedefined,
　　ProtectionDomain protectionDomain,byte[] classfileBuffer)
　　{
　　try {
　　　ClassParser cp =new ClassParser(new ByteArrayInputStream(classfileBuffer),className + ".java");
　　　JavaClass jc = cp.parse();

　　　ClassGen cg = new ClassGen(jc);

　　　for (Annotation an : getAnnotations(jc.getAttributes())) {
　　　　instrumentor.instrumentClass(cg, an);
　　　}

　　　for (org.apache.bcel.classfile.Method m : cg.getMethods()) {
　　　　for (Annotation an : getAnnotations(m.getAttributes())) {
　　　　　ConstantPoolGen cpg =cg.getConstantPool();
　　　　　MethodGen mg =new MethodGen(m, className, cpg);
　　　　　instrumentor.instrumentMethod(cg, mg, an);
　　　　　mg.setMaxStack();
　　　　　mg.setMaxLocals();
　　　　　cg.replaceMethod(m, mg.getMethod());
　　　　}
　　　}
　　　JavaClass jcNew = cg.getJavaClass();
　　　return jcNew.getBytes();
　　} catch (Exception ex) {
　　　throw new RuntimeException("instrumenting " + className, ex);
　　}
　　}
　　...
　　}


　　這種在啟動時重構(gòu)字節(jié)碼的方法位于在示例的/code/03_startup目錄中。

　　異常的處理

　　文章前面提到，我希望編寫附加的代碼使用不同目的的@Status注解。我們來考慮一下一些額外的需求：我們的應(yīng)用程序必須捕捉所有的未處理異常并把它們顯示給用戶。但是，我們不是提供Java堆棧跟蹤，而是顯示擁有@Status注解的方法，而且還不應(yīng)該顯示任何代碼（類或方法的名稱或行號等等）。

　　例如，考慮下面的堆棧跟蹤信息：


　　java.lang.RuntimeException: Could not load data for symbol IBM
　　at boxpeeking.code.YourCode.loadData(Unknown Source)
　　at boxpeeking.code.YourCode.go(Unknown Source)
　　at boxpeeking.yourcode.ui.Main+2.run(Unknown Source)
　　at java.lang.Thread.run(Thread.java:566)
　　Caused by: java.lang.RuntimeException: Timed out
　　at boxpeeking.code.YourCode.connectToDB(Unknown Source)
　　... 更多信息


　　這將導(dǎo)致圖1中所示的GUI彈出框，上面的例子假設(shè)你的YourCode.loadData()、YourCode.go()和YourCode.connectToDB()都含有@Status注解。請注意，異常的次序是相反的，因此用戶最先得到的是最詳細(xì)的信息。 　　　　　　　　　　　

　圖3.顯示在錯誤對話框中的堆棧跟蹤信息

　　為了實現(xiàn)這些功能，我必須對已有的代碼進行稍微的修改。首先，為了確保在運行時@Status注解是可以看到的，我就必須再次更新@Retention，把它設(shè)置為@Retention(RetentionPolicy.RUNTIME)。請記住，@Retention控制著JVM什么時候拋棄注解信息。這樣的設(shè)置意味著注解不僅可以被編譯器插入字節(jié)碼中，還能夠使用新的Method.getAnnotation(Class)方法通過反射來進行訪問。

　　現(xiàn)在我需要安排接收代碼中沒有明確處理的任何異常的通知了。在Java 1.4中，處理任何特定線程上未處理異常的最好方法是使用ThreadGroup子類并給該類型的ThreadGroup添加自己的新線程。但是Java 1.5提供了額外的功能。我可以定義UncaughtExceptionHandler接口的一個實例，并為任何特定的線程（或所有線程）注冊它。

　　請注意，在例子中為特定異常注冊可能更好，但是在Java 1.5.0beta1（#4986764）中有一個bug，它使這樣操作無法進行。但是為所有線程設(shè)置一個處理程序是可以工作的，因此我就這樣操作了。

　　現(xiàn)在我們擁有了一種截取未處理異常的方法了，并且這些異常必須被報告給用戶。在GUI應(yīng)用程序中，典型情況下這樣的操作是通過彈出一個包含整個堆棧跟蹤信息或簡單消息的模式對話框來實現(xiàn)的。在例子中，我希望在產(chǎn)生異常的時候顯示一個消息，但是我希望提供堆棧的@Status描述而不是類和方法的名稱。為了實現(xiàn)這個目的，我簡單地在Thread的StackTraceElement數(shù)組中查詢，找到與每個框架相關(guān)的java.lang.reflect.Method對象，并查詢它的堆棧注解列表。不幸的是，它只提供了方法的名稱，沒有提供方法的特征量（signature），因此這種技術(shù)不支持名稱相同的（但@Status注解不同的）重載方法。

　　實現(xiàn)這種方法的示例代碼可以在peekinginside-pt2.tar.gz文件的/code/04_exceptions目錄中找到。

　　 取樣（Sampling）

　　我現(xiàn)在有辦法把StackTraceElement數(shù)組轉(zhuǎn)換為@Status注解堆棧。這種操作比表明看到的更加有用。Java 1.5中的另一個新特性--線程反�。╥ntrospection）--使我們能夠從當(dāng)前正在運行的線程中得到準(zhǔn)確的StackTraceElement數(shù)組。有了這兩部分信息之后，我們就可以構(gòu)造JstatusBar的另一種實現(xiàn)。StatusManager將不會在發(fā)生方法調(diào)用的時候接收通知，而是簡單地啟動一個附加的線程，讓它負(fù)責(zé)在正常的間隔期間抓取堆棧跟蹤信息和每個步驟的狀態(tài)。只要這個間隔期間足夠短，用戶就不會感覺到更新的延遲。

　　下面使"sampler"線程背后的代碼，它跟蹤另一個線程的經(jīng)過：

　　class StatusSampler implements Runnable
　　{
　　private Thread watchThread;

　　public StatusSampler (Thread watchThread)
　　{
　　this.watchThread = watchThread;
　　}

　　public void run ()
　　{
　　while (watchThread.isAlive()) {
　　　// 從線程中得到堆棧跟蹤信息
　　　StackTraceElement[] stackTrace =watchThread.getStackTrace();
　　　// 從堆棧跟蹤信息中提取狀態(tài)消息
　　　List＜Status＞ statusList =StatusFinder.getStatus(stackTrace);
　　　Collections.reverse(statusList);
　　　// 用狀態(tài)消息建立某種狀態(tài)
　　　StatusState state = new StatusState();
　　　for (Status s : statusList) {
　　　　String message = s.value();
　　　　state.push(message);
　　　}

　　　// 更新當(dāng)前的狀態(tài)
　　　StatusManager.setState(watchThread,state);
　　　//休眠到下一個周期
　　　try {
　　　　Thread　.sleep(SAMPLING_DELAY);
　　　} catch (InterruptedException ex) {}
　　}

　　//狀態(tài)復(fù)位
　　StatusManager.setState(watchThread,new StatusState());
　　}
　　}

　　與增加方法調(diào)用、手動或通過重構(gòu)相比，取樣對程序的侵害性（invasive）更小。我根本不需要改變建立過程或命令行參數(shù)，或修改啟動過程。它也允許我通過調(diào)整SAMPLING_DELAY來控制占用的開銷。不幸的是，當(dāng)方法調(diào)用開始或結(jié)束的時候，這種方法沒有明確的回調(diào)。除了狀態(tài)更新的延遲之外，沒有原因要求這段代碼在那個時候接收回調(diào)。但是，未來我能夠增加一些額外的代碼來跟蹤每個方法的準(zhǔn)確的運行時。通過檢查StackTraceElement是可以精確地實現(xiàn)這樣的操作的。

　　通過線程取樣實現(xiàn)JStatusBar的代碼可以在peekinginside-pt2.tar.gz文件的/code/05_sampling目錄中找到。

　　在執(zhí)行過程中重構(gòu)字節(jié)碼

　　通過把取樣的方法與重構(gòu)組合在一起，我能夠形成一種最終的實現(xiàn)，它提供了各種方法的最佳特性。默認(rèn)情況下可以使用取樣，但是應(yīng)用程序的花費時間最多的方法可以被個別地進行重構(gòu)。這種實現(xiàn)根本不會安裝ClassTransformer，但是作為代替，它會一次一個地重構(gòu)方法以響應(yīng)取樣過程中收集到的數(shù)據(jù)。

　　為了實現(xiàn)這種功能，我將建立一個新類InstrumentationManager，它可以用于重構(gòu)和不重構(gòu)獨立的方法。它可以使用新的Instrumentation.redefineClasses方法來修改空閑的類，同時代碼則可以不間斷執(zhí)行。前面部分中增加的StatusSampler線程現(xiàn)在有了額外的職責(zé)，它把任何自己"發(fā)現(xiàn)"的@Status方法添加到集合中。它將周期性地找出最壞的冒犯者并把它們提供給InstrumentationManager以供重構(gòu)。這允許應(yīng)用程序更加精確地跟蹤每個方法的啟動和終止時刻。

　　前面提到的取樣方法的一個問題是它不能區(qū)分長時間運行的方法與在循環(huán)中多次調(diào)用的方法。由于重構(gòu)會給每次方法調(diào)用增加一定的開銷，我們有必要忽略頻繁調(diào)用的方法。幸運的是，我們可以使用重構(gòu)解決這個問題。除了簡單地更新StatusManager之外，我們將維護每個重構(gòu)的方法被調(diào)用的次數(shù)。如果這個數(shù)值超過了某個極限（意味著維護這個方法的信息的開銷太大了），取樣線程將會永遠(yuǎn)地取消對該方法的重構(gòu)。

　　理想情況下，我將把每個方法的調(diào)用數(shù)量存儲在重構(gòu)過程中添加到類的新字段中。不幸的是，Java 1.5中增加的類轉(zhuǎn)換機制不允許這樣操作；它不能增加或刪除任何字段。作為代替，我將把這些信息存儲在新的CallCounter類的Method對象的靜態(tài)映射中。

　　這種混合的方法可以在示例代碼的/code/06_dynamic目錄中找到。

　　概括

　　圖4提供了一個矩形，它顯示了我給出的例子相關(guān)的特性和代價。

　　圖4.重構(gòu)方法的分析

 　　你可以發(fā)現(xiàn)，動態(tài)的（Dynamic）方法是各種方案的良好組合。與使用重構(gòu)的所有示例類似，它提供了方法開始或終止時刻的明確的回調(diào)，因此你的應(yīng)用程序可以準(zhǔn)確地跟蹤運行時并立即為用戶提供反饋信息。但是，它還能夠取消某種方法的重構(gòu)（它被過于頻繁地調(diào)用），因此它不會受到其它的重構(gòu)方案遇到的性能問題的影響。它沒有包含編譯時步驟，并且它沒有增加類載入過程中的額外的工作。

　　未來的趨勢

　　我們可以給這個項目增加大量的附件特性，使它更加適用。其中最有用的特性可能是動態(tài)的狀態(tài)信息。我們可以使用新的java.util.Formatter類把類似printf的模式替換（pattern substitution）用于@Status消息中。例如，我們的connectToDB(String url)方法中的@Status("Connecting to %s")注解可以把URL作為消息的一部分報告給用戶。

　　在源代碼重構(gòu)的幫助下，這可能顯得微不足道，因為我將使用的Formatter.format方法使用了可變參數(shù)（Java 1.5中增加的"魔術(shù)"功能）。重構(gòu)過的版本類似下面的情形：

　　public void connectToDB (String url) {
　　Formatter f = new Formatter();
　　String message = f.format("Connecting to %s", url);

　　StatusManager.push(message);
　　try {
　　...
　　} finally {
　　StatusManager.pop();
　　}
　　}

　　不幸的是，這種"魔術(shù)"功能是完全在編譯器中實現(xiàn)的。在字節(jié)碼中，F(xiàn)ormatter.format把Object[]作為參數(shù)，編譯器明確地添加代碼來包裝每個原始的類型并裝配該數(shù)組。如果BCEL沒有加緊彌補，而我又需要使用字節(jié)碼重構(gòu)，我將不得不重新實現(xiàn)這種邏輯。

　　由于它只能用于重構(gòu)（這種情況下方法參數(shù)是可用的）而不能用于取樣，你可能希望在啟動的時候重構(gòu)這些方法，或最少使動態(tài)實現(xiàn)偏向于任何方法的重構(gòu)，還可以在消息中使用替代模式。

　　你還可以跟蹤每個重構(gòu)的方法調(diào)用的啟動次數(shù)，因此你還可以更加精確地報告每個方法的運行次數(shù)。你甚至于可以保存這些次數(shù)的歷史統(tǒng)計數(shù)據(jù)，并使用它們形成一個真正的進度條（代替我使用的不確定的版本）。這種能力將賦予你在運行時重構(gòu)某種方法的一個很好的理由，因為跟蹤任何獨立的方法的開銷都是很能很明顯的。

　　你可以給進度條增加"調(diào)試"模式，它不管方法調(diào)用是否包含@Status注解，報告取樣過程中出現(xiàn)的所有方法調(diào)用。這對于任何希望調(diào)試死鎖或性能問題的開發(fā)者來說都是無價之寶。實際上，Java 1.5還為死鎖（deadlock）檢測提供了一個可編程的API，在應(yīng)用程序鎖住的時候，我們可以使用該API把進程條變成紅色。

　　本文中建立的基于注解的重構(gòu)框架組件可能很有市場。一個允許字節(jié)碼在編譯時（通過Ant事務(wù)）、啟動時（使用ClassTransformer）和執(zhí)行過程中（使用Instrumentation）進行重構(gòu)的工具對于少量其它新項目來說毫無疑問地非常有價值。

　　總結(jié)

　　在這幾個例子中你可以看到，元數(shù)據(jù)編程（meta-programming）可能是一種非常強大的技術(shù)。報告長時間運行的操作的進程僅僅是這種技術(shù)的應(yīng)用之一，而我們的JStatusBar僅僅是溝通這些信息的一種媒介。我們可以看到，Java 1.5中提供的很多新特性為元數(shù)據(jù)編程提供了增強的支持。特別地，把注解和運行時重構(gòu)組合在一起為面向?qū)傩缘木幊烫峁┝苏嬲齽討B(tài)的形式。我們可以進一步使用這些技術(shù)，使它的功能超越已有的框架組件（例如XDoclet提供的框架組件的功能）。