年底Sun 公司發布了 Java Standard Edition （Java SE ）的最終正式版代號 Mustang（野馬）跟 Tiger（Java SE ）相比Mustang 在性能方面有了不錯的提升與 Tiger 在 API 庫方面的大幅度加強相比雖然 Mustang 在 API 庫方面的新特性顯得不太多但是也提供了許多實用和方便的功能在腳本Web serviceXML編譯器 API數據庫JMX網絡和 Instrumentation 方面都有不錯的新特性和功能加強
本系列文章主要介紹 Java SE 在 API 庫方面的部分新特性通過講解一些例子幫助開發者在編程實踐當中更好的運用 Java SE 提高開發效率
Instrumentation 簡介
利用 Java 代碼即 javalanginstrument 做動態 Instrumentation 是 Java SE 的新特性它把 Java 的 instrument 功能從本地代碼中解放出來使之可以用 Java 代碼的方式解決問題使用 Instrumentation開發者可以構建一個獨立於應用程序的代理程序（Agent）用來監測和協助運行在 JVM 上的程序甚至能夠替換和修改某些類的定義有了這樣的功能開發者就可以實現更為靈活的運行時虛擬機監控和 Java 類操作了這樣的特性實際上提供了一種虛擬機級別支持的 AOP 實現方式使得開發者無需對 JDK 做任何升級和改動就可以實現某些 AOP 的功能了
在 Java SE 裡面instrumentation 包被賦予了更強大的功能啟動後的 instrument本地代碼（native code）instrument以及動態改變 classpath 等等這些改變意味著 Java 具有了更強的動態控制解釋能力它使得 Java 語言變得更加靈活多變
在 Java SE 裡面最大的改變使運行時的 Instrumentation 成為可能在 Java SE 中Instrument 要求在運行前利用命令行參數或者系統參數來設置代理類在實際的運行之中虛擬機在初始化之時（在絕大多數的 Java 類庫被載入之前）instrumentation 的設置已經啟動並在虛擬機中設置了回調函數檢測特定類的加載情況並完成實際工作但是在實際的很多的情況下我們沒有辦法在虛擬機啟動之時就為其設定代理這樣實際上限制了 instrument 的應用而 Java SE 的新特性改變了這種情況通過 Java Tool API 中的 attach 方式我們可以很方便地在運行過程中動態地設置加載代理類以達到 instrumentation 的目的
另外對 native 的 Instrumentation 也是 Java SE 的一個嶄新的功能這使以前無法完成的功能 —— 對 native 接口的 instrumentation 可以在 Java SE 中通過一個或者一系列的 prefix 添加而得以完成
最後Java SE 裡的 Instrumentation 也增加了動態添加 class path 的功能所有這些新的功能都使得 instrument 包的功能更加豐富從而使 Java 語言本身更加強大
Instrumentation 的基本功能和用法
javalanginstrument包的具體實現依賴於 JVMTIJVMTI（Java Virtual Machine Tool Interface）是一套由 Java 虛擬機提供的為 JVM 相關的工具提供的本地編程接口集合JVMTI 是從 Java SE 開始引入整合和取代了以前使用的 Java Virtual Machine Profiler Interface (JVMPI) 和 the Java Virtual Machine Debug Interface (JVMDI)而在 Java SE 中JVMPI 和 JVMDI 已經消失了JVMTI 提供了一套代理程序機制可以支持第三方工具程序以代理的方式連接和訪問 JVM並利用 JVMTI 提供的豐富的編程接口完成很多跟 JVM 相關的功能事實上javalanginstrument 包的實現也就是基於這種機制的在 Instrumentation 的實現當中存在一個 JVMTI 的代理程序通過調用 JVMTI 當中 Java 類相關的函數來完成 Java 類的動態操作除開 Instrumentation 功能外JVMTI 還在虛擬機內存管理線程控制方法和變量操作等等方面提供了大量有價值的函數關於 JVMTI 的詳細信息請參考 Java SE 文檔當中的介紹
Instrumentation 的最大作用就是類定義動態改變和操作在 Java SE 及其後續版本當中開發者可以在一個普通 Java 程序（帶有 main 函數的 Java 類）運行時通過 –javaagent 參數指定一個特定的 jar 文件（包含 Instrumentation 代理）來啟動 Instrumentation 的代理程序
在 Java SE 當中開發者可以讓 Instrumentation 代理在 main 函數運行前執行簡要說來就是如下幾個步驟
編寫 premain 函數
編寫一個 Java 類包含如下兩個方法當中的任何一個
public static void premain(String agentArgs Instrumentation inst); []
public static void premain(String agentArgs); []
其中[] 的優先級比 [] 高將會被優先執行（[] 和 [] 同時存在時[] 被忽略）
在這個 premain 函數中開發者可以進行對類的各種操作
agentArgs 是 premain 函數得到的程序參數隨同 –javaagent一起傳入與 main 函數不同的是這個參數是一個字符串而不是一個字符串數組如果程序參數有多個程序將自行解析這個字符串
Inst 是一個 javalanginstrumentInstrumentation 的實例由 JVM 自動傳入javalanginstrumentInstrumentation 是 instrument 包中定義的一個接口也是這個包的核心部分集中了其中幾乎所有的功能方法例如類定義的轉換和操作等等
jar 文件打包
將這個 Java 類打包成一個 jar 文件並在其中的 manifest 屬性當中加入 PremainClass來指定步驟 當中編寫的那個帶有 premain 的 Java類（可能還需要指定其他屬性以開啟更多功能）
運行
用如下方式運行帶有 Instrumentation 的 Java 程序
java javaagent:jar文件的位置[=傳入premain的參數]
對 Java 類文件的操作可以理解為對一個 byte 數組的操作（將類文件的二進制字節流讀入一個 byte 數組）開發者可以在ClassFileTransformer的 transform 方法當中得到操作並最終返回一個類的定義（一個 byte 數組）這方面Apache 的 BCEL 開源項目提供了強有力的支持讀者可以在參考文章Java SE 特性 Instrumentation 實踐中看到一個 BCEL 和 Instrumentation 結合的例子具體的字節碼操作並非本文的重點所以本文中所舉的例子只是采用簡單的類文件替換的方式來演示 Instrumentation 的使用
下面我們通過簡單的舉例來說明 Instrumentation 的基本使用方法
首先我們有一個簡單的類TransClass 可以通過一個靜態方法返回一個整數
public class TransClass {
public int getNumber() {
return ;
}
}
我們運行如下類可以得到輸出
public class TestMainInJar {
public static void main(String[] args) {
Systemoutprintln(new TransClass()getNumber());
}
}
然後我們將 TransClass 的 getNumber 方法改成如下:
public int getNumber() {
return ;
}
再將這個返回 的 Java 文件編譯成類文件為了區別開原有的返回 的類我們將返回 的這個類文件命名為 TransClassclass
接下來我們建立一個 Transformer 類
import javaioFile;
import javaioFileInputStream;
import javaioIOException;
import javaioInputStream;
import javalanginstrumentClassFileTransformer;
import javalanginstrumentIllegalClassFormatException;
import javasecurityProtectionDomain;
class Transformer implements ClassFileTransformer {
public static final String classNumberReturns = TransClassclass;
public static byte[] getBytesFromFile(String fileName) {
try {
// precondition
File file = new File(fileName);
InputStream is = new FileInputStream(file);
long length = filelength();
byte[] bytes = new byte[(int) length];
// Read in the bytes
int offset = ;
int numRead = ;
while (offset <byteslength
&& (numRead = isread(bytes offset byteslength offset)) >= ) {
offset += numRead;
}
if (offset < byteslength) {
throw new IOException(Could not completely read file
+ filegetName());
}
isclose();
return bytes;
} catch (Exception e) {
Systemoutprintln(error occurs in _ClassTransformer!
+ egetClass()getName());
return null;
}
}
public byte[] transform(ClassLoader l String className Class<?> c
ProtectionDomain pd byte[] b) throws IllegalClassFormatException {
if (!classNameequals(TransClass)) {
return null;
}
return getBytesFromFile(classNumberReturns);
}
}
這個類實現了 ClassFileTransformer 接口其中getBytesFromFile 方法根據文件名讀入二進制字符流而 ClassFileTransformer 當中規定的 transform 方法則完成了類定義的替換轉換
最後我們建立一個 Premain 類寫入 Instrumentation 的代理方法 premain
public class Premain {
public static void premain(String agentArgs Instrumentation inst)
throws ClassNotFoundException UnmodifiableClassException {
instaddTransformer(new Transformer());
}
}
可以看出addTransformer 方法並沒有指明要轉換哪個類轉換發生在 premain 函數執行之後main 函數執行之前這時每裝載一個類transform 方法就會執行一次看看是否需要轉換所以在 transform（Transformer 類中）方法中程序用 classNameequals(TransClass) 來判斷當前的類是否需要轉換
代碼完成後我們將他們打包為 TestInstrumentjar返回 的那個 TransClass 的類文件保留在 jar 包中而返回 的那個 TransClassclass 則放到 jar 的外面在 manifest 裡面加入如下屬性來指定 premain 所在的類
ManifestVersion:
PremainClass: Premain
在運行這個程序的時候如果我們用普通方式運行這個 jar 中的 main 函數可以得到輸出如果用下列方式運行:
java –javaagent:TestInstrumentjar –cp TestInstrumentjar TestMainInJar
則會得到輸出
當然程序運行的 main 函數不一定要放在 premain 所在的這個 jar 文件裡面這裡只是為了例子程序打包的方便而放在一起的
除開用 addTransformer 的方式Instrumentation 當中還有另外一個方法redefineClasses來實現 premain 當中指定的轉換用法類似如下
public class Premain {
public static void premain(String agentArgs Instrumentation inst)
throws ClassNotFoundException UnmodifiableClassException {
ClassDefinition def = new ClassDefinition(TransClassclass Transformer
getBytesFromFile(TransformerclassNumberReturns));
instredefineClasses(new ClassDefinition[] { def });
Systemoutprintln(success);
}
}
redefineClasses 的功能比較強大可以批量轉換很多類
Java SE 的新特性虛擬機啟動後的動態 instrument
在 Java SE 當中開發者只能在 premain 當中施展想象力所作的 Instrumentation 也僅限與 main 函數執行前這樣的方式存在一定的局限性
在 Java SE 的基礎上Java SE 針對這種狀況做出了改進開發者可以在 main 函數開始執行以後再啟動自己的 Instrumentation 程序
在 Java SE 的 Instrumentation 當中有一個跟 premain並駕齊驅的agentmain方法可以在 main 函數開始運行之後再運行
跟 premain 函數一樣 開發者可以編寫一個含有agentmain函數的 Java 類
public static void agentmain (String agentArgs Instrumentation inst); []
public static void agentmain (String agentArgs); []
同樣[] 的優先級比 [] 高將會被優先執行
跟 premain 函數一樣開發者可以在 agentmain 中進行對類的各種操作其中的 agentArgs 和 Inst 的用法跟 premain 相同
與PremainClass類似開發者必須在 manifest 文件裡面設置AgentClass來指定包含 agentmain 函數的類
可是跟 premain 不同的是agentmain 需要在 main 函數開始運行後才啟動這樣的時機應該如何確定呢這樣的功能又如何實現呢？
在 Java SE 文檔當中開發者也許無法在 javalanginstrument 包相關的文檔部分看到明確的介紹更加無法看到具體的應用 agnetmain 的例子不過在 Java SE 的新特性裡面有一個不太起眼的地方揭示了 agentmain 的用法這就是 Java SE 當中提供的 Attach API
Attach API 不是 Java 的標准 API而是 Sun 公司提供的一套擴展 API用來向目標 JVM 附著（Attach）代理工具程序的有了它開發者可以方便的監控一個 JVM運行一個外加的代理程序
Attach API 很簡單只有 個主要的類都在 comsuntoolsattach 包裡面 VirtualMachine 代表一個 Java 虛擬機也就是程序需要監控的目標虛擬機提供了 JVM 枚舉Attach 動作和 Detach 動作（Attach 動作的相反行為從 JVM 上面解除一個代理）等等 VirtualMachineDescriptor 則是一個描述虛擬機的容器類配合 VirtualMachine 類完成各種功能
為了簡單起見我們舉例簡化如下依然用類文件替換的方式將一個返回 的函數替換成返回 的函數Attach API 寫在一個線程裡面用睡眠等待的方式每隔半秒時間檢查一次所有的 Java 虛擬機當發現有新的虛擬機出現的時候就調用 attach 函數隨後再按照 Attach API 文檔裡面所說的方式裝載 Jar 文件等到 秒鐘的時候attach 程序自動結束而在 main 函數裡面程序每隔半秒鐘輸出一次返回值（顯示出返回值從 變成 ）
TransClass 類和 Transformer 類的代碼不變參看上一節介紹 含有 main 函數的 TestMainInJar 代碼為
public class TestMainInJar {
public static void main(String[] args) throws InterruptedException {
Systemoutprintln(new TransClass()getNumber());
int count = ;
while (true) {
Threadsleep();
count++;
int number = new TransClass()getNumber();
Systemoutprintln(number);
if ( == number || count >= ) {
break;
}
}
}
}
含有 agentmain 的 AgentMain 類的代碼為
import javalanginstrumentClassDefinition;
import javalanginstrumentInstrumentation;
import javalanginstrumentUnmodifiableClassException;
public class AgentMain {
public static void agentmain(String agentArgs Instrumentation inst)
throws ClassNotFoundException UnmodifiableClassException
InterruptedException {
instaddTransformer(new Transformer () true);
instretransformClasses(TransClassclass);
Systemoutprintln(Agent Main Done);
}
}
其中retransformClasses 是 Java SE 裡面的新方法它跟 redefineClasses 一樣可以批量轉換類定義多用於 agentmain 場合
Jar 文件跟 Premain 那個例子裡面的 Jar 文件差不多也是把 main 和 agentmain 的類TransClassTransformer 等類放在一起打包為TestInstrumentjar而 Jar 文件當中的 Manifest 文件為:
ManifestVersion:
AgentClass: AgentMain
另外為了運行 Attach API我們可以再寫一個控制程序來模擬監控過程（代碼片段）
import comsuntoolsattachVirtualMachine;
import comsuntoolsattachVirtualMachineDescriptor;
……
// 一個運行 Attach API 的線程子類
static class AttachThread extends Thread {
private final List<VirtualMachineDescriptor> listBefore;
private final String jar;
AttachThread(String attachJar List<VirtualMachineDescriptor> vms) {
listBefore = vms; // 記錄程序啟動時的 VM 集合
jar = attachJar;
}
public void run() {
VirtualMachine vm = null;
List<VirtualMachineDescriptor> listAfter = null;
try {
int count = ;
while (true) {
listAfter = VirtualMachinelist();
for (VirtualMachineDescriptor vmd : listAfter) {
if (!ntains(vmd)) {
// 如果 VM 有增加我們就認為是被監控的 VM 啟動了
// 這時我們開始監控這個 VM
vm = VirtualMachineattach(vmd);
break;
}
}
Threadsleep();
count++;
if (null != vm || count >= ) {
break;
}
}
vmloadAgent(jar);
vmdetach();
} catch (Exception e) {
ignore
}
}
}
……
public static void main(String[] args) throws InterruptedException {
new AttachThread(TestInstrumentjar VirtualMachinelist())start();
}
運行時可以首先運行上面這個啟動新線程的 main 函數然後在 秒鐘內（僅僅簡單模擬 JVM 的監控過程）運行如下命令啟動測試 Jar 文件:
java –javaagent:TestInstrumentjar –cp TestInstrumentjar TestMainInJar
如果時間掌握得不太差的話程序首先會在屏幕上打出 這是改動前的類的輸出然後會打出一些 這個表示 agentmain 已經被 Attach API 成功附著到 JVM 上代理程序生效了當然還可以看到Agent Main Done字樣的輸出
以上例子僅僅只是簡單示例簡單說明這個特性而已真實的例子往往比較復雜而且可能運行在分布式環境的多個 JVM 之中
Java SE 新特性本地方法的 Instrumentation
在 版本的 instumentation 裡並沒有對 Java 本地方法（Native Method）的處理方式而且在 Java 標准的 JVMTI 之下並沒有辦法改變 method signature 這就使替換本地方法非常地困難一個比較直接而簡單的想法是在啟動時替換本地代碼所在的動態鏈接庫 —— 但是這樣本質上是一種靜態的替換而不是動態的 Instrumentation而且這樣可能需要編譯較大數量的動態鏈接庫 —— 比如我們有三個本地函數假設每一個都需要一個替換而在不同的應用之下可能需要不同的組合那麼如果我們把三個函數都編譯在同一個動態鏈接庫之中最多我們需要 個不同的動態鏈接庫來滿足需要當然我們也可以獨立地編譯之那樣也需要 個動態鏈接庫——無論如何這種繁瑣的方式是不可接受的
在 Java SE 中新的 Native Instrumentation 提出了一個新的 native code 的解析方式作為原有的 native method 的解析方式的一個補充來很好地解決了一些問題這就是在新版本的 javalanginstrument 包裡我們擁有了對 native 代碼的 instrument 方式 —— 設置 prefix
假設我們有了一個 native 函數名字叫 nativeMethod在運行中過程中我們需要將它指向另外一個函數（需要注意的是在當前標准的 JVMTI 之下除了 native 函數名其他的 signature 需要一致）比如我們的 Java 代碼是
package nativeTester;
class nativePrefixTester{
…
native int nativeMethod(int input);
…
}
那麼我們已經實現的本地代碼是:
jint Java_nativeTester_nativeMethod(jclass thiz jobject thisObj jint input);
現在我們需要在調用這個函數時使之指向另外一個函數那麼按照 JSE 的做法我們可以按他的命名方式加上一個 prefix 作為新的函數名比如我們以 another_ 作為 prefix那麼我們新的函數是:
jint Java_nativeTester_another_nativePrefixTester(jclass thiz jobject thisObj
jint input);
然後將之編入動態鏈接庫之中
現在我們已經有了新的本地函數接下來就是做 instrument 的設置正如以上所說的我們可以使用 premain 方式在虛擬機啟動之時就載入 premain 完成 instrument 代理設置也可以使用 agentmain 方式去 attach 虛擬機來啟動代理而設置 native 函數的也是相當簡單的:
premain(){ // 或者也可以在 agentmain 裡
…
if (!isNativeMethodPrefixSupported()){
return; // 如果無法設置則返回
}
setNativeMethodPrefix(transformeranother_); // 設置 native 函數的 prefix注意這個下劃線必須由用戶自己規定
…
}
在這裡要注意兩個問題一是不是在任何的情況下都是可以設置 native 函數的 prefix 的首先我們要注意到 agent 包之中的 Manifest 所設定的特性:
CanSetNativeMethodPrefix
要注意這一個參數都可以影響是否可以設置 native prefix而且在默認的設置之中這個參數是 false 的我們需要將之設置成 true（順便說一句對 Manifest 之中的屬性來說都是大小寫無關的當然如果給一個不是true的值就會被當作 false 值處理）
當然我們還需要確認虛擬機本身是否支持 setNativePrefix在 Java API 裡Instrumentation 類提供了一個函數 isNativePrefix通過這個函數我們可以知道該功能是否可以實行
二是我們可以為每一個 ClassTransformer 加上它自己的 nativeprefix同時每一個 ClassTransformer 都可以為同一個 class 做 transform因此對於一個 Class 來說一個 native 函數可能有不同的 prefix因此對這個函數來說它可能也有好幾種解析方式
在 Java SE 當中Native prefix 的解釋方式如下對於某一個 package 內的一個 class 當中的一個 native method 來說首先假設我們對這個函數的 transformer 設置了 native 的 prefixanother它將這個函數接口解釋成
由 Java 的函數接口
native void method()
和上述 prefixanother去尋找本地代碼中的函數
void Java_package_class_another_method(jclass theClass jobject thiz);
// 請注意 prefix 在函數名中出現的位置！
一旦可以找到那麼調用這個函數整個解析過程就結束了如果沒有找到那麼虛擬機將會做進一步的解析工作我們將利用 Java native 接口最基本的解析方式去找本地代碼中的函數:
void Java_package_class_method(jclass theClass jobject thiz);
如果找到則執行之否則因為沒有任何一個合適的解析方式於是宣告這個過程失敗
那麼如果有多個 transformer同時每一個都有自己的 prefix又該如何解析呢？事實上虛擬機是按 transformer 被加入到的 Instrumentation 之中的次序去解析的（還記得我們最基本的 addTransformer 方法嗎？）
假設我們有三個 transformer 要被加入進來他們的次序和相對應的 prefix 分別為transformer 和prefix_transformer 和 prefix_transformer 和 prefix_那麼虛擬機會首先做的就是將接口解析為:
native void prefix_prefix_prefix_native_method()
然後去找它相對應的 native 代碼
但是如果第二個 transformer（transformer）沒有設定 prefix那麼很簡單我們得到的解析是
native void prefix_prefix_native_method()
這個方式簡單而自然
當然對於多個 prefix 的情況我們還要注意一些復雜的情況比如假設我們有一個 native 函數接口是
native void native_method()
然後我們為它設置了兩個 prefix比如 wrapped_ 和 wrapped_那麼我們得到的是什麼呢？是
void Java_package_class_wrapped_wrapped_method(jclass theClass jobject thiz);
// 這個函數名正確嗎？
嗎？答案是否定的
因為事實上
對 Java 中 native 函數的接口到 native 中的映射
有一系列的規定
因此可能有一些特殊的字符要被代入
而實際中
這個函數的正確的函數名是
void Java_package_class_wrapped_wrapped_method（jclass theClass jobject thiz） // 只有這個函數名會被找到
很有趣不是嗎？因此如果我們要做類似的工作一個很好的建議是首先在 Java 中寫一個帶 prefix 的 native 接口用 javah 工具生成一個 c 的 headerfile看看它實際解析得到的函數名是什麼這樣我們就可以避免一些不必要的麻煩
另外一個事實是與我們的想像不同對於兩個或者兩個以上的 prefix虛擬機並不做更多的解析它不會試圖去掉某一個 prefix再來組裝函數接口它做且僅作兩次解析
總之新的 native 的 prefixinstrumentation 的方式改變了以前 Java 中 native 代碼無法動態改變的缺點在當前利用 JNI 來寫 native 代碼也是 Java 應用中非常重要的一個環節因此它的動態化意味著整個 Java 都可以動態改變了 —— 現在我們的代碼可以利用加上 prefix 來動態改變 native 函數的指向正如上面所說的如果找不到虛擬機還會去嘗試做標准的解析這讓我們擁有了動態地替換 native 代碼的方式我們可以將許多帶不同 prefix 的函數編譯在一個動態鏈接庫之中而通過 instrument 包的功能讓 native 函數和 Java 函數一樣動態改變動態替換
當然現在的 native 的 instrumentation 還有一些限制條件比如不同的 transformer 會有自己的 native prefix就是說每一個 transformer 會負責他所替換的所有類而不是特定類的 prefix —— 因此這個粒度可能不夠精確
Java SE 新特性BootClassPath / SystemClassPath 的動態增補
我們知道通過設置系統參數或者通過虛擬機啟動參數我們可以設置一個虛擬機運行時的 boot class 加載路徑（Xbootclasspath）和 system class（cp）加載路徑當然我們在運行之後無法替換它然而我們也許有時候要需要把某些 jar 加載到 bootclasspath 之中而我們無法應用上述兩個方法或者我們需要在虛擬機啟動之後來加載某些 jar 進入 bootclasspath在 Java SE 之中我們可以做到這一點了
實現這幾點很簡單首先我們依然需要確認虛擬機已經支持這個功能然後在 premain/agantmain 之中加上需要的 classpath我們可以在我們的 Transformer 裡使用 appendToBootstrapClassLoaderSearch/appendToSystemClassLoaderSearch 來完成這個任務
同時我們可以注意到在 agent 的 manifest 裡加入 BootClassPath 其實一樣可以在動態地載入 agent 的同時加入自己的 boot class 路徑當然在 Java code 中它可以更加動態方便和智能地完成 —— 我們可以很方便地加入判斷和選擇成分
在這裡我們也需要注意幾點首先我們加入到 classpath 的 jar 文件中不應當帶有任何和系統的 instrumentation 有關的系統同名類不然一切都陷入不可預料之中 —— 這不是一個工程師想要得到的結果不是嗎？
其次我們要注意到虛擬機的 ClassLoader 的工作方式它會記載解析結果比如我們曾經要求讀入某個類 someclass但是失敗了ClassLoader 會記得這一點即使我們在後面動態地加入了某一個 jar含有這個類ClassLoader 依然會認為我們無法解析這個類與上次出錯的相同的錯誤會被報告
再次我們知道在 Java 語言中有一個系統參數javaclasspath這個 property 裡面記錄了我們當前的 classpath但是我們使用這兩個函數雖然真正地改變了實際的 classpath卻不會對這個 property 本身產生任何影響
在公開的 JavaDoc 中我們可以發現一個很有意思的事情Sun 的設計師們告訴我們這個功能事實上依賴於 ClassLoader 的 appendtoClassPathForInstrumentation 方法 —— 這是一個非公開的函數因此我們不建議直接（使用反射等方式）使用它事實上instrument 包裡的這兩個函數已經可以很好的解決我們的問題了
結語
從以上的介紹我們可以得出結論在 Java SE 裡面instrumentation 包新增的功能 —— 虛擬機啟動後的動態 instrument本地代碼（native code）instrumentation以及動態添加 classpath 等等使得 Java 具有了更強的動態控制解釋能力從而讓 Java 語言變得更加靈活多變
這些能力從某種意義上開始改變 Java 語言本身在過去很長的一段時間內動態 腳本語言的大量湧現和快速發展對整個軟件業和網絡業提高生產率起到了非常重要的作用在這種背景之下Java 也正在慢慢地作出改變而 Instrument 的新功能和 Script 平台（本系列的後面一篇中將介紹到這一點）的出現則大大強化了語言的動態化和與動態語言融合它是 Java 的發展的值得考量的新趨勢
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19245.html
