Instrumentation 實踐詳解

利用 Java 代碼，即 java.lang.instrument 作動態 Instrumentation 是 Java SE 5 的新特性，它把 Java 的 instrument 功能從本地代碼中解放出來，使之能夠用 Java 代碼的方式解決問題。使用 Instrumentation，開發者能夠構建一個獨立於應用程序的代理程序（Agent），用來監測和協助運行在 JVM 上的程序，甚至可以替換和修改某些類的定義。有了這樣的功能，開發者就能夠實現更爲靈活的運行時虛擬機監控和 Java 類操做了，這樣的特性實際上提供了一種虛擬機級別支持的 AOP 實現方式，使得開發者無需對 JDK 作任何升級和改動，就能夠實現某些 AOP 的功能了。

在 Java SE 6 裏面，instrumentation 包被賦予了更強大的功能：啓動後的 instrument、本地代碼（native code）instrument，以及動態改變 classpath 等等。這些改變，意味着 Java 具備了更強的動態控制、解釋能力，它使得 Java 語言變得更加靈活多變。

在 Java SE6 裏面，最大的改變使運行時的 Instrumentation 成爲可能。在 Java SE 5 中，Instrument 要求在運行前利用命令行參數或者系統參數來設置代理類，在實際的運行之中，虛擬機在初始化之時（在絕大多數的 Java 類庫被載入以前），instrumentation 的設置已經啓動，並在虛擬機中設置了回調函數，檢測特定類的加載狀況，並完成實際工做。可是在實際的不少的狀況下，咱們沒有辦法在虛擬機啓動之時就爲其設定代理，這樣實際上限制了 instrument 的應用。而 Java SE 6 的新特性改變了這種狀況，經過 Java Tool API 中的 attach 方式，咱們能夠很方便地在運行過程當中動態地設置加載代理類，以達到 instrumentation 的目的。

另外，對 native 的 Instrumentation 也是 Java SE 6 的一個嶄新的功能，這使之前沒法完成的功能 —— 對 native 接口的 instrumentation 能夠在 Java SE 6 中，經過一個或者一系列的 prefix 添加而得以完成。

最後，Java SE 6 裏的 Instrumentation 也增長了動態添加 class path的功能。全部這些新的功能，都使得 instrument 包的功能更加豐富，從而使 Java 語言自己更增強大。

##Instrumentation 的基本功能和用法 「java.lang.instrument」包的具體實現，依賴於 JVMTI。JVMTI（Java Virtual Machine Tool Interface）是一套由 Java 虛擬機提供的，爲 JVM 相關的工具提供的本地編程接口集合。JVMTI 是從 Java SE 5 開始引入，整合和取代了之前使用的 Java Virtual Machine Profiler Interface (JVMPI) 和 the Java Virtual Machine Debug Interface (JVMDI)，而在 Java SE 6 中，JVMPI 和 JVMDI 已經消失了。JVMTI 提供了一套」代理」程序機制，能夠支持第三方工具程序以代理的方式鏈接和訪問 JVM，並利用 JVMTI 提供的豐富的編程接口，完成不少跟 JVM 相關的功能。事實上，java.lang.instrument 包的實現，也就是基於這種機制的：在 Instrumentation 的實現當中，存在一個 JVMTI 的代理程序，經過調用 JVMTI 當中 Java 類相關的函數來完成Java 類的動態操做。除開 Instrumentation 功能外，JVMTI 還在虛擬機內存管理，線程控制，方法和變量操做等等方面提供了大量有價值的函數。關於 JVMTI 的詳細信息，請參考 Java SE 6 文檔中的介紹。

Instrumentation 的最大做用，就是類定義動態改變和操做。在 Java SE 5 及其後續版本當中，開發者能夠在一個普通 Java 程序（帶有 main 函數的 Java 類）運行時，經過 -javaagent參數指定一個特定的 jar 文件（包含 Instrumentation 代理）來啓動 Instrumentation 的代理程序。

在 Java SE 5 當中，開發者可讓 Instrumentation 代理在 main 函數運行前執行。簡要說來就是以下幾個步驟： (1) 編寫 premain 函數 編寫一個 Java 類，包含以下兩個方法當中的任何一個：

public static void premain(String agentArgs, Instrumentation inst);  [1]
public static void premain(String agentArgs); [2]

其中，[1] 的優先級比 [2] 高，將會被優先執行（[1] 和 [2] 同時存在時，[2] 被忽略）。在這個 premain 函數中，開發者能夠進行對類的各類操做。

agentArgs 是 premain 函數獲得的程序參數，隨同 「-javaagent」一塊兒傳入。與 main 函數不一樣的是，這個參數是一個字符串而不是一個字符串數組，若是程序參數有多個，程序將自行解析這個字符串。

Inst 是一個 java.lang.instrument.Instrumentation 的實例，由 JVM 自動傳入。java.lang.instrument.Instrumentation 是 instrument 包中定義的一個接口，也是這個包的核心部分，集中了其中幾乎全部的功能方法，例如類定義的轉換和操做等等。

(2) jar 文件打包 將這個 Java 類打包成一個 jar 文件，並在其中的 manifest 屬性當中加入」 Premain-Class」來指定步驟 1 當中編寫的那個帶有 premain 的 Java 類。（可能還須要指定其餘屬性以開啓更多功能）

(3) 運行 用以下方式運行帶有 Instrumentation 的 Java 程序：

java -javaagent:jar 文件的位置 [= 傳入 premain 的參數 ]

對 Java 類文件的操做，能夠理解爲對一個 byte 數組的操做（將類文件的二進制字節流讀入一個 byte 數組）。開發者能夠在「ClassFileTransformer」的 transform 方法當中獲得，操做並最終返回一個類的定義（一個 byte 數組）。這方面，Apache 的 BCEL 開源項目提供了強有力的支持，具體的字節碼操做並不是本文的重點，因此，本文中所舉的例子，只是採用簡單的類文件替換的方式來演示 Instrumentation 的使用。

下面，咱們經過簡單的舉例，來講明 Instrumentation 的基本使用方法。

首先，咱們有一個簡單的類，TransClass， 能夠經過一個靜態方法返回一個整數 1。

public class TransClass { 
	 public int getNumber() { 
	 return 1; 
    } 
}

咱們運行以下類，能夠獲得輸出 」1「。

public class TestMainInJar { 
    public static void main(String[] args) { 
        System.out.println(new TransClass().getNumber()); 
    } 
}

而後，咱們將 TransClass 的 getNumber 方法改爲以下 :

public int getNumber() { 
    return 2; 
}

再將這個返回 2 的 Java 文件編譯成類文件，爲了區別開原有的返回 1 的類，咱們將返回 2 的這個類文件命名爲 TransClass2.class.2。 接下來，咱們創建一個 Transformer 類：

import java.io.File; 
import java.io.FileInputStream; 
import java.io.IOException; 
import java.io.InputStream; 
import java.lang.instrument.ClassFileTransformer; 
import java.lang.instrument.IllegalClassFormatException; 
import java.security.ProtectionDomain; 

class Transformer implements ClassFileTransformer { 

    public static final String classNumberReturns2 = "TransClass.class.2"; 

    public static byte[] getBytesFromFile(String fileName) { 
        try { 
            // precondition 
            File file = new File(fileName); 
            InputStream is = new FileInputStream(file); 
            long length = file.length(); 
            byte[] bytes = new byte[(int) length]; 

            // Read in the bytes 
            int offset = 0; 
            int numRead = 0; 
            while (offset <bytes.length 
                    && (numRead = is.read(bytes, offset, bytes.length - offset)) >= 0) { 
                offset += numRead; 
            } 

            if (offset < bytes.length) { 
                throw new IOException("Could not completely read file "
                        + file.getName()); 
            } 
            is.close(); 
            return bytes; 
        } catch (Exception e) { 
            System.out.println("error occurs in _ClassTransformer!"
                    + e.getClass().getName()); 
            return null; 
        } 
    } 

    public byte[] transform(ClassLoader l, String className, Class<?> c, 
            ProtectionDomain pd, byte[] b) throws IllegalClassFormatException { 
        if (!className.equals("TransClass")) { 
            return null; 
        } 
        return getBytesFromFile(classNumberReturns2); 
    } 
}

這個類實現了 ClassFileTransformer 接口。其中，getBytesFromFile 方法根據文件名讀入二進制字符流，而 ClassFileTransformer 當中規定的 transform 方法則完成了類定義的替換轉換。

最後，咱們創建一個 Premain 類，寫入 Instrumentation 的代理方法 premain：

public class Premain { 
    public static void premain(String agentArgs， Instrumentation inst)  throws ClassNotFoundException， UnmodifiableClassException { 
        inst.addTransformer(new Transformer()); 
    } 
}

能夠看出，addTransformer 方法並無指明要轉換哪一個類。轉換髮生在 premain 函數執行以後，main 函數執行以前，這時每裝載一個類，transform 方法就會執行一次，看看是否須要轉換，因此，在 transform（Transformer 類中）方法中，程序用 className.equals("TransClass") 來判斷當前的類是否須要轉換。

代碼完成後，咱們將他們打包爲 TestInstrument1.jar。返回 1 的那個 TransClass 的類文件保留在 jar 包中，而返回 2 的那個 TransClass.class.2 則放到 jar 的外面。在 manifest 裏面加入以下屬性來指定 premain 所在的類：

Manifest-Version: 1.0 Premain-Class: Premain

在運行這個程序的時候，若是咱們用普通方式運行這個 jar 中的 main 函數，能夠獲得輸出「1」。若是用下列方式運行 :

java -javaagent:TestInstrument1.jar -cp TestInstrument1.jar TestMainInJar

則會獲得輸出「2」。

固然，程序運行的 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(TransClass.class， Transformer.getBytesFromFile(Transformer.classNumberReturns2)); 
        inst.redefineClasses(new ClassDefinition[] { def }); 
        System.out.println("success"); 
    } 
}

redefineClasses 的功能比較強大，能夠批量轉換不少類。

##Java SE 6 的新特性：虛擬機啓動後的動態 instrument 在 Java SE 5 當中，開發者只能在 premain 當中施展想象力，所做的 Instrumentation 也僅限與 main 函數執行前，這樣的方式存在必定的侷限性。

在 Java SE 5 的基礎上，Java SE 6 針對這種情況作出了改進，開發者能夠在 main 函數開始執行之後，再啓動本身的 Instrumentation 程序。

在 Java SE 6 的 Instrumentation 當中，有一個跟 premain「並駕齊驅」的「agentmain」方法，能夠在 main 函數開始運行以後再運行。跟 premain 函數同樣， 開發者能夠編寫一個含有「agentmain」函數的 Java 類：

public static void agentmain (String agentArgs, Instrumentation inst); [1] 
public static void agentmain (String agentArgs);[2]

一樣，[1] 的優先級比 [2] 高，將會被優先執行。跟 premain 函數同樣，開發者能夠在 agentmain 中進行對類的各類操做。其中的 agentArgs 和 Inst 的用法跟 premain 相同。

與「Premain-Class」相似，開發者必須在 manifest 文件裏面設置「Agent-Class」來指定包含 agentmain 函數的類。

但是，跟 premain 不一樣的是，agentmain 須要在 main 函數開始運行後才啓動，這樣的時機應該如何肯定呢，這樣的功能又如何實現呢？

在 Java SE 6 文檔當中，開發者也許沒法在 java.lang.instrument 包相關的文檔部分看到明確的介紹，更加沒法看到具體的應用 agnetmain 的例子。不過，在 Java SE 6 的新特性裏面，有一個不太起眼的地方，揭示了 agentmain 的用法。這就是 Java SE 6 當中提供的 Attach API。

Attach API 不是 Java 的標準 API，而是 Sun 公司提供的一套擴展 API，用來向目標 JVM 」附着」（Attach）代理工具程序的。有了它，開發者能夠方便的監控一個 JVM，運行一個外加的代理程序。

Attach API 很簡單，只有 2 個主要的類，都在 com.sun.tools.attach 包裏面： VirtualMachine 表明一個 Java 虛擬機，也就是程序須要監控的目標虛擬機，提供了 JVM 枚舉，Attach 動做和 Detach 動做（Attach 動做的相反行爲，從 JVM 上面解除一個代理）等等 ; VirtualMachineDescriptor 則是一個描述虛擬機的容器類，配合 VirtualMachine 類完成各類功能。

VirtualMachine類，該類容許咱們經過給attach方法傳入一個jvm的pid（進程id），遠程鏈接到jvm上。而後咱們能夠經過loadAgent方法向jvm註冊一個代理程序agent，在該agent的代理程序中會獲得一個Instrumentation實例，該實例能夠在class加載前改變class的字節碼，能夠在class加載後從新加載。在調用Instrumentation實例的方法時，這些方法會使用ClassFileTransformer接口中提供的方法進行處理。

爲了簡單起見，咱們舉例簡化以下：依然用類文件替換的方式，將一個返回 1 的函數替換成返回 2 的函數，Attach API 寫在一個線程裏面，用睡眠等待的方式，每隔半秒時間檢查一次全部的 Java 虛擬機，當發現有新的虛擬機出現的時候，就調用 attach 函數，隨後再按照 Attach API 文檔裏面所說的方式裝載 Jar 文件。等到 5 秒鐘的時候，attach 程序自動結束。而在 main 函數裏面，程序每隔半秒鐘輸出一次返回值（顯示出返回值從 1 變成 2）。

TransClass 類和 Transformer 類的代碼不變，參看上一節介紹。 含有 main 函數的 TestMainInJar 代碼爲：

public class TestMainInJar { 
    public static void main(String[] args) throws InterruptedException { 
        System.out.println(new TransClass().getNumber()); 
        int count = 0; 
        while (true) { 
            Thread.sleep(500); 
            count++; 
            int number = new TransClass().getNumber(); 
            System.out.println(number); 
            if (3 == number || count >= 10) { 
                break; 
            } 
        } 
    } 
}

含有 agentmain 的 AgentMain 類的代碼爲：

import java.lang.instrument.ClassDefinition; 
import java.lang.instrument.Instrumentation; 
import java.lang.instrument.UnmodifiableClassException; 

public class AgentMain { 
    public static void agentmain(String agentArgs, Instrumentation inst)  throws ClassNotFoundException, UnmodifiableClassException, InterruptedException { 
        inst.addTransformer(new Transformer (), true); 
        inst.retransformClasses(TransClass.class); 
        System.out.println("Agent Main Done"); 
    } 
}

其中，retransformClasses 是 Java SE 6 裏面的新方法，它跟 redefineClasses 同樣，能夠批量轉換類定義，多用於 agentmain 場合。

Jar 文件跟 Premain 那個例子裏面的 Jar 文件差很少，也是把 main 和 agentmain 的類，TransClass，Transformer 等類放在一塊兒，打包爲「TestInstrument1.jar」，而 Jar 文件當中的 Manifest 文件爲 :

Manifest-Version: 1.0 Agent-Class: AgentMain

另外，爲了運行 Attach API，咱們能夠再寫一個控制程序來模擬監控過程：（代碼片斷）

import com.sun.tools.attach.VirtualMachine; 
import com.sun.tools.attach.VirtualMachineDescriptor; 
……
// 一個運行 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 = 0; 
                while (true) { 
                    listAfter = VirtualMachine.list(); 
                    for (VirtualMachineDescriptor vmd : listAfter) { 
                        if (!listBefore.contains(vmd)) { 
                            // 若是 VM 有增長，咱們就認爲是被監控的 VM 啓動了
                            // 這時，咱們開始監控這個 VM 
                            vm = VirtualMachine.attach(vmd); 
                            break; 
                        } 
                    } 
                    Thread.sleep(500); 
                    count++; 
                    if (null != vm || count >= 10) { 
                        break; 
                    } 
                } 
                vm.loadAgent(jar); 
                vm.detach(); 
            } catch (Exception e) { 
                 ignore 
            } 
        } 
    } 
……
public static void main(String[] args) throws InterruptedException { 	 
     new AttachThread("TestInstrument1.jar", VirtualMachine.list()).start(); 
}

運行時，能夠首先運行上面這個啓動新線程的 main 函數，而後，在 5 秒鐘內（僅僅簡單模擬 JVM 的監控過程）運行以下命令啓動測試 Jar 文件 :

java – javaagent:TestInstrument2.jar – cp TestInstrument2.jar TestMainInJar

若是時間掌握得不太差的話，程序首先會在屏幕上打出 1，這是改動前的類的輸出，而後會打出一些 2，這個表示 agentmain 已經被 Attach API 成功附着到 JVM 上，代理程序生效了，固然，還能夠看到「Agent Main Done」字樣的輸出。

以上例子僅僅只是簡單示例，簡單說明這個特性而已。真實的例子每每比較複雜，並且可能運行在分佈式環境的多個 JVM 之中。

##Java SE 6 新特性：本地方法的 Instrumentation 在 1.5 版本的 instumentation 裏，並無對 Java 本地方法（Native Method）的處理方式，並且在 Java 標準的 JVMTI 之下，並無辦法改變 method signature， 這就使替換本地方法很是地困難。一個比較直接而簡單的想法是，在啓動時替換本地代碼所在的動態連接庫 —— 可是這樣，本質上是一種靜態的替換，而不是動態的 Instrumentation。並且，這樣可能須要編譯較大數量的動態連接庫 —— 好比，咱們有三個本地函數，假設每個都須要一個替換，而在不一樣的應用之下，可能須要不一樣的組合，那麼若是咱們把三個函數都編譯在同一個動態連接庫之中，最多咱們須要 8 個不一樣的動態連接庫來知足須要。固然，咱們也能夠獨立地編譯之，那樣也須要 6 個動態連接庫——不管如何，這種繁瑣的方式是不可接受的。 在 Java SE 6 中，新的 Native Instrumentation 提出了一個新的 native code 的解析方式，做爲原有的 native method 的解析方式的一個補充，來很好地解決了一些問題。這就是在新版本的 java.lang.instrument 包裏，咱們擁有了對 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);

如今咱們須要在調用這個函數時，使之指向另一個函數。那麼按照 J2SE 的作法，咱們能夠按他的命名方式，加上一個 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(transformer,"another_"); // 設置 native 函數的 prefix，注意這個下劃線必須由用戶本身規定
    …
}

在這裏要注意兩個問題。一：不是在任何的狀況下都是能夠設置 native 函數的 prefix 的；首先，咱們要注意到 agent 包之中的 Manifest 所設定的特性 :

Can-Set-Native-Method-Prefix

要注意，這一個參數均可以影響是否能夠設置 native prefix，並且，在默認的設置之中，這個參數是 false 的，咱們須要將之設置成 true（順便說一句，對 Manifest 之中的屬性來講都是大小寫無關的，固然，若是給一個不是「true」的值，就會被看成 false 值處理）。

固然，咱們還須要確認虛擬機自己是否支持 setNativePrefix。在 Java API 裏，Instrumentation 類提供了一個函數 isNativePrefix，經過這個函數咱們能夠知道該功能是否能夠實行。

二：咱們能夠爲每個 ClassTransformer 加上它本身的 nativeprefix；同時，每個 ClassTransformer 均可覺得同一個 class 作 transform，所以對於一個 Class 來講，一個 native 函數可能有不一樣的 prefix，所以對這個函數來講，它可能也有好幾種解析方式。 在 Java SE 6 當中，Native prefix 的解釋方式以下：對於某一個 package 內的一個 class 當中的一個 native method 來講，首先，假設咱們對這個函數的 transformer 設置了 native 的 prefix「another」，它將這個函數接口解釋成 : 由 Java 的函數接口

native void method()

和上述 prefix"another"，去尋找本地代碼中的函數

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 分別爲：transformer1 和「prefix1_」，transformer2 和 「prefix2_」，transformer3 和 「prefix3_」。那麼，虛擬機會首先作的就是將接口解析爲 :

native void prefix1_prefix2_prefix3_native_method()

而後去找它相對應的 native 代碼。 可是若是第二個 transformer（transformer2）沒有設定 prefix，那麼很簡單，咱們獲得的解析是：

native void prefix1_prefix3_native_method()

這個方式簡單而天然。 固然，對於多個 prefix 的狀況，咱們還要注意一些複雜的狀況。好比，假設咱們有一個 native 函數接口是：

native void native_method()

而後咱們爲它設置了兩個 prefix，好比 "wrapped_" 和 "wrapped2_"，那麼，咱們獲得的是什麼呢？

void Java_package_class_wrapped_wrapped2_method(jclass theClass, jobject thiz); // 這個函數名正確嗎？

答案是否認的，由於事實上，對 Java 中 native 函數的接口到 native 中的映射，有一系列的規定，所以可能有一些特殊的字符要被代入。而實際中，這個函數的正確的函數名是：

void Java_package_class_wrapped_1wrapped2_1method(jclass theClass, jobject thiz); // 只有這個函數名會被找到

頗有趣不是嗎？所以若是咱們要作相似的工做，一個很好的建議是首先在 Java 中寫一個帶 prefix 的 native 接口，用 javah 工具生成一個 c 的 header-file，看看它實際解析獲得的函數名是什麼，這樣咱們就能夠避免一些沒必要要的麻煩。

另一個事實是，與咱們的想像不一樣，對於兩個或者兩個以上的 prefix，虛擬機並不作更多的解析；它不會試圖去掉某一個 prefix，再來組裝函數接口。它作且僅做兩次解析。

總之，新的 native 的 prefix-instrumentation 的方式，改變了之前 Java 中 native 代碼沒法動態改變的缺點。在當前，利用 JNI 來寫 native 代碼也是 Java 應用中很是重要的一個環節，所以它的動態化意味着整個 Java 均可以動態改變了 —— 如今咱們的代碼能夠利用加上 prefix 來動態改變 native 函數的指向，正如上面所說的，若是找不到，虛擬機還會去嘗試作標準的解析，這讓咱們擁有了動態地替換 native 代碼的方式，咱們能夠將許多帶不一樣 prefix 的函數編譯在一個動態連接庫之中，而經過 instrument 包的功能，讓 native 函數和 Java 函數同樣動態改變、動態替換。 固然，如今的 native 的 instrumentation 還有一些限制條件，好比，不一樣的 transformer 會有本身的 native prefix，就是說，每個 transformer 會負責他所替換的全部類而不是特定類的 prefix —— 所以這個粒度可能不夠精確。

##Java SE 6 新特性：BootClassPath / SystemClassPath 的動態增補 咱們知道，經過設置系統參數或者經過虛擬機啓動參數，咱們能夠設置一個虛擬機運行時的 boot class 加載路徑（-Xbootclasspath）和 system class（-cp）加載路徑。固然，咱們在運行以後沒法替換它。然而，咱們也許有時候要須要把某些 jar 加載到 bootclasspath 之中，而咱們沒法應用上述兩個方法；或者咱們須要在虛擬機啓動以後來加載某些 jar 進入 bootclasspath。在 Java SE 6 之中，咱們能夠作到這一點了。

實現這幾點很簡單，首先，咱們依然須要確認虛擬機已經支持這個功能，而後在 premain/agantmain 之中加上須要的 classpath。咱們能夠在咱們的 Transformer 裏使用 appendToBootstrapClassLoaderSearch/appendToSystemClassLoaderSearch來完成這個任務。

同時咱們能夠注意到，在 agent 的 manifest 里加入 Boot-Class-Path 其實同樣能夠在動態地載入 agent 的同時加入本身的 boot class 路徑，固然，在 Java code 中它能夠更加動態方便和智能地完成 —— 咱們能夠很方便地加入判斷和選擇成分。

在這裏咱們也須要注意幾點。首先，咱們加入到 classpath 的 jar 文件中不該當帶有任何和系統的 instrumentation 有關的系統同名類，否則，一切都陷入不可預料之中 —— 這不是一個工程師想要獲得的結果，不是嗎？

其次，咱們要注意到虛擬機的 ClassLoader 的工做方式，它會記載解析結果。好比，咱們曾經要求讀入某個類 someclass，可是失敗了，ClassLoader 會記得這一點。即便咱們在後面動態地加入了某一個 jar，含有這個類，ClassLoader 依然會認爲咱們沒法解析這個類，與上次出錯的相同的錯誤會被報告。

再次咱們知道在 Java 語言中有一個系統參數「java.class.path」，這個 property 裏面記錄了咱們當前的 classpath，可是，咱們使用這兩個函數，雖然真正地改變了實際的 classpath，卻不會對這個 property 自己產生任何影響。

在公開的 JavaDoc 中咱們能夠發現一個頗有意思的事情，Sun 的設計師們告訴咱們，這個功能事實上依賴於 ClassLoader 的 appendtoClassPathForInstrumentation 方法 —— 這是一個非公開的函數，所以咱們不建議直接（使用反射等方式）使用它，事實上，instrument 包裏的這兩個函數已經能夠很好的解決咱們的問題了。