使用 Instrumentation，使得開發者可以構建一個獨立於應用程式的代理程式（Agent），用來監測和協助執行在 JVM 上的程式，甚至能夠替換和修改某些類的定義。有了這樣的功能，開發者就可以實現更為靈活的執行時虛擬機器監控和 Java 類操作了，這樣的特性實際上提供了 一種虛擬機器級別支援的 AOP 實現方式，使得開發者無需對 JDK 做任何升級和改動，就可以實現某些 AOP 的功能了。

利用 java.lang.instrument 做靜態 Instrumentation 是 Java SE 5 的新特性，它把 Java 的 instrument 功能從原生代碼中解放出來，使之可以用 Java 程式碼的方式解決問題

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

1. 在 Java SE6 裡面，最大的改變使執行時的 Instrumentation 成為可能。在 Java SE 5 中，Instrument 要求在執行前利用命令列引數或者系統引數來設定代理類，在實際的執行之中，虛擬機器在初始化之時（在絕大多數的 Java 類庫被載入之前），instrumentation 的設定已經啟動，並在虛擬機器中設定了回撥函式，檢測特定類的載入情況，並完成實際工作。但是在實際的很多的情況下，我們沒有辦法在虛擬機器啟動之時就為其設定代理，這樣實際上限制了 instrument 的應用

   。而 Java SE 6 的新特性改變了這種情況，通過 Java Tool API 中的 attach 方式，我們可以很方便地 在執行過程中動態地設定載入代理類，以達到 instrumentation 的目的。

2. 另外，對 native 的 Instrumentation 也是 Java SE 6 的一個嶄新的功能，這使以前無法完成的功能 —— 對 native 介面的 instrumentation 可以在 Java SE 6 中，通過一個或者一系列的 prefix 新增而得以完成。

3. 最後，Java SE 6 裡的 Instrumentation 也增加了動態新增 class path的功能

   。所有這些新的功能，都使得 instrument 包的功能更加豐富，從而使 Java 語言本身更加強大。

1 基本功能和用法

事實上，java.lang.instrument 包的實現，是基於JVMTI機制的：在 Instrumentation 的實現當中，存在一個 JVMTI 的代理程式，通過呼叫 JVMTI 當中 Java 類相關的函式來完成Java 類的動態操作。除開 Instrumentation 功能外，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 相關的功能。

1.1 JVM啟動前靜態Instrument

Instrumentation 的最大作用，就是類定義動態改變和操作。在 Java SE 5 及其後續版本當中，開發者可以在一個普通 Java 程式（帶有 main 函式的 Java 類）執行時，通過 -javaagent引數指定一個特定的 jar 檔案（包含 Instrumentation 代理）來啟動 Instrumentation 的代理程式。

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 函式中，開發者可以進行對類的各種操作。

   1. agentArgs 是 premain 函式得到的程式引數，隨同 “-javaagent”一起傳入。與 main 函式不同的是，這個引數是一個字串而不是一個字串陣列，如果程式引數有多個，程式將自行解析這個字串。
   2. Inst 是一個 java.lang.instrument.Instrumentation 的例項，由 JVM 自動傳入。java.lang.instrument.Instrumentation 是 instrument 包中定義的一個介面，也是這個包的核心部分，集中了其中幾乎所有的功能方法，例如類定義的轉換和操作等等。

2. jar 檔案打包

   將這個 Java 類打包成一個 jar 檔案，並在其中的META-INF/MAINIFEST.MF屬性當中加入” Premain-Class”來指定步驟 1 當中編寫的那個帶有 premain 的 Java 類。（可能還需要指定其他屬性以開啟更多功能）

3. 執行

   用如下方式執行帶有 Instrumentation 的 Java 程式：

   java -javaagent:jar檔案的位置 [= 傳入 premain 的引數 ]
   

舉個替換Java類檔案栗子：採用簡單的類檔案替換的方式來演示 Instrumentation 的使用

對 Java 類檔案的操作，可以理解為對一個 byte 陣列的操作（將類檔案的二進位制位元組流讀入一個 byte 陣列）。開發者可以在“ClassFileTransformer”的 transform 方法當中得到，操作並最終返回一個類的定義（一個 byte 陣列）。

1. 首先，我們有一個簡單的類，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()); } } 

2. 然後，我們將 TransClass 的 getNumber 方法改成如下：

   public int getNumber() { return 2; } 

   再將這個返回 2 的 Java 檔案編譯成類檔案，為了區別開原有的返回 1 的類，我們將返回 2 的這個類檔案命名為 TransClass2.class.2。

3. 接下來，我們建立一個 Transformer 類：這個類實現了 ClassFileTransformer 介面

   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; public 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; } } /** * 引數： * loader - 定義要轉換的類載入器；如果是引導載入器，則為 null * className - 完全限定類內部形式的類名稱和 The Java Virtual Machine Specification 中定義的介面名稱。例如，"java/util/List"。 * classBeingRedefined - 如果是被重定義或重轉換觸發，則為重定義或重轉換的類；如果是類載入，則為 null * protectionDomain - 要定義或重定義的類的保護域 * classfileBuffer - 類檔案格式的輸入位元組緩衝區（不得修改） * 返回： * 一個格式良好的類檔案緩衝區（轉換的結果），如果未執行轉換,則返回 null。 * 丟擲： * IllegalClassFormatException - 如果輸入不表示一個格式良好的類檔案 */ public byte[] transform(ClassLoader l, String className, Class<?> c, ProtectionDomain pd, byte[] b) throws IllegalClassFormatException { if (!className.equals("TransClass")) { return null; } return getBytesFromFile(classNumberReturns2); } } 

   其中，getBytesFromFile 方法根據檔名讀入二進位制字元流，而 ClassFileTransformer 當中規定的 transform 方法則完成了類定義的替換轉換。

4. 最後，我們建立一個 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") 來判斷當前的類是否需要轉換。

5. 程式碼完成後，我們將他們打包為 TestInstrument1.jar。返回 1 的那個 TransClass 的類檔案保留在 jar 包中，而返回 2 的那個 TransClass.class.2 則放到 jar 的外面。在 manifest 裡面加入如下屬性來指定 premain 所在的類：

   Manifest-Version: 1.0 
   Premain-Class: Premain
   

6. 在執行這個程式的時候，如果我們用普通方式執行這個 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 的功能比較強大，可以批量轉換很多類。

1.2 JVM啟動後動態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] 高，將會被優先執行（[1] 和 [2] 同時存在時，[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 包裡面：

1. VirtualMachine 代表一個 Java 虛擬機器，也就是程式需要監控的目標虛擬機器，提供了 JVM 列舉，Attach 動作和 Detach 動作（Attach 動作的相反行為，從 JVM 上面解除一個代理）等等 ;

   VirtualMachine類，該類允許我們 通過給attach方法傳入一個jvm的pid（程序id），遠端連線到jvm上 。然後我們可以 通過loadAgent方法向jvm註冊一個代理程式agent，在該agent的代理程式中會得到一個Instrumentation例項，該例項可以 在class載入前改變class的位元組碼，也可以在class載入後重新載入。在呼叫Instrumentation例項的方法時，這些方法會使用ClassFileTransformer介面中提供的方法進行處理。

2. VirtualMachineDescriptor 則是一個描述虛擬機器的容器類，配合 VirtualMachine 類完成各種功能。

為了簡單起見，我們舉例簡化如下：依然用類檔案替換的方式

1. 將一個返回 1 的函式替換成返回 2 的函式，Attach API 寫在一個執行緒裡面，用睡眠等待的方式，每隔半秒時間檢查一次所有的 Java 虛擬機器，當發現有新的虛擬機器出現的時候，就呼叫 attach 函式，隨後再按照 Attach API 文件裡面所說的方式裝載 Jar 檔案。等到 5 秒鐘的時候，attach 程式自動結束。
2. 在 main 函式裡面，程式每隔半秒鐘輸出一次返回值（顯示出返回值從 1 變成 2）。

TransClass 類和 Transformer 類的程式碼不變，參看上一節介紹。 含有 main 函式的 TestMainInJar 程式碼為：

// 程式每隔半秒鐘輸出一次返回值（顯示出返回值從 1 變成 2）
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 的執行緒子類
// 每隔半秒時間檢查一次所有的 Java 虛擬機器
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 –cp TestInstrument1.jar TestMainInJar 

如果時間掌握得不太差的話，程式首先會在螢幕上打出 1，這是改動前的類的輸出，然後會打出一些 2，這個表示 agentmain 已經被 Attach API 成功附著到 JVM 上，代理程式生效了，當然，還可以看到“Agent Main Done”字樣的輸出。

1.3 本地方法Instrument

在 JDK 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，注意這個下劃線必須由使用者自己規定 … } 

在這裡要注意兩個問題：

1. 不是在任何的情況下都是可以設定 native 函式的 prefix 的；首先，我們要注意到 agent 包之中的 Manifest 所設定的特性 :

   Can-Set-Native-Method-Prefix
   

   要注意，這一個引數都可以影響是否可以設定 native prefix，而且，在預設的設定之中，這個引數是 false 的，我們需要將之設定成 true（順便說一句，對 Manifest 之中的屬性來說都是大小寫無關的，當然，如果給一個不是“true”的值，就會被當作 false 值處理）。

   當然，我們還需要確認虛擬機器本身是否支援 setNativePrefix。在 Java API 裡，Instrumentation 類提供了一個函式 isNativePrefix，通過這個函式我們可以知道該功能是否可以實行。

2. 我們可以為每一個 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"，去尋找原生代碼中的函式：

   // 請注意 prefix 在函式名中出現的位置！
   void Java_package_class_another_method(jclass theClass, jobject thiz); 

   一旦可以找到，那麼呼叫這個函式，整個解析過程就結束了；如果沒有找到，那麼虛擬機器將會做進一步的解析工作。我們將利用 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 —— 因此這個粒度可能不夠精確。

1.4 BootClassPath / SystemClassPath 的動態增補

我們知道，通過設定系統引數或者通過虛擬機器啟動引數，我們可以設定一個虛擬機器執行時的 boot class 載入路徑（-Xbootclasspath）和 system class（-cp）載入路徑。當然，我們在執行之後無法替換它。然而，我們也許有時候要需要把某些 jar 載入到 bootclasspath 之中，而我們無法應用上述兩個方法；或者我們需要在虛擬機器啟動之後來載入某些 jar 進入 bootclasspath。在 Java SE 6 之中，我們可以做到這一點了。

實現這幾點很簡單，首先，我們依然需要 確認虛擬機器已經支援這個功能，然後在 premain/agantmain 之中加上需要的 classpath。我們可以在premain/agentmain方法中 Instrumentation inst 裡使用 appendToBootstrapClassLoaderSearch/appendToSystemClassLoaderSearch來完成這個任務。

同時我們可以注意到，在 agent 的 mainfest 里加入 Boot-Class-Path 其實一樣可以在動態地載入agent自己的 boot class 路徑，當然，在 Java code 中它可以更加動態方便和智慧地完成 —— 我們可以很方便地加入判斷和選擇成分。

在這裡我們也需要注意幾點：

1. 首先，我們加入到 classpath 的 jar 檔案中不應當帶有任何和系統的 instrumentation 有關的系統同名類，不然，一切都陷入不可預料之中 —— 這不是一個工程師想要得到的結果，不是嗎？

2. 其次，我們要注意到虛擬機器的 ClassLoader 的工作方式，它會記錄解析結果。比如，我們曾經要求讀入某個類 someclass，但是失敗了，ClassLoader 會記得這一點。即使我們在後面動態地加入了某一個 jar，含有這個類，ClassLoader 依然會認為我們無法解析這個類，與上次出錯的相同的錯誤會被報告。

3. 再次我們知道在 Java 語言中有一個系統引數“java.class.path”，這個 property 裡面記錄了我們當前的 classpath，但是，我們使用這兩個函式，雖然真正地改變了實際的 classpath，卻不會對這個 property 本身產生任何影響。

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

1.5 META-INF/MAINIFEST.MF清單

以下是agent jar檔案的Manifest Attributes清單：

1. Premain-Class 如果 JVM 啟動時指定了代理，那麼此屬性指定代理類，即包含 premain 方法的類。如果 JVM 啟動時指定了代理，那麼此屬性是必需的。如果該屬性不存在，那麼 JVM 將中止。注：此屬性是類名，不是檔名或路徑。
2. Agent-Class 如果實現支援 VM 啟動之後某一時刻啟動代理的機制，那麼此屬性指定代理類，即包含 agentmain 方法的類。 此屬性是必需的，如果不存在，代理將無法啟動。注：這是類名，而不是檔名或路徑。
3. Boot-Class-Path 設定引導類載入器搜尋的路徑列表。路徑表示目錄或庫（在許多平臺上通常作為 JAR 或 zip 庫被引用）。查詢類的特定於平臺的機制失敗後，引導類載入器會搜尋這些路徑。按列出的順序搜尋路徑。列表中的路徑由一個或多個空格分開。路徑使用分層 URI 的路徑元件語法。如果該路徑以斜槓字元（“/”）開頭，則為絕對路徑，否則為相對路徑。相對路徑根據代理 JAR 檔案的絕對路徑解析。忽略格式不正確的路徑和不存在的路徑。如果代理是在 VM 啟動之後某一時刻啟動的，則忽略不表示 JAR 檔案的路徑。此屬性是可選的。
4. Can-Redefine-Classes 布林值（true 或 false，與大小寫無關）。是否能重定義此代理所需的類。true 以外的值均被視為 false。此屬性是可選的，預設值為 false。
5. Can-Retransform-Classes 布林值（true 或 false，與大小寫無關）。是否能重轉換此代理所需的類。true 以外的值均被視為 false。此屬性是可選的，預設值為 false。
6. Can-Set-Native-Method-Prefix 布林值（true 或 false，與大小寫無關）。是否能設定此代理所需的本機方法字首。true 以外的值均被視為 false。此屬性是可選的，預設值為 false。

2 Instrument兩個核心API

1. ClassFileTransformer：定義了類載入前的預處理類，可以在這個類中對要載入的類的位元組碼做一些處理，譬如進行位元組碼增強；
2. Instrumentation：增強器，由JVM在入口引數中傳遞給我們，提供瞭如下的功能：

   1. addTransformer/removeTransformer：註冊/刪除ClassFileTransformer；
   2. retransformClasses：對於已經載入的類重新進行轉換處理，即會觸發重新載入類定義，需要注意的是，新載入的類不能修改舊有的類宣告，譬如不能增加屬性、不能修改方法宣告；
   3. redefineClasses：與如上類似，但不是重新進行轉換處理，而是直接把處理結果(bytecode)直接給JVM；
   4. getAllLoadedClasses：獲得當前已經載入的Class，可配合retransformClasses使用；
   5. getInitiatedClasses：獲得由某個特定的ClassLoader載入的類定義；
   6. getObjectSize：獲得一個物件佔用的空間，包括其引用的物件；
   7. appendToBootstrapClassLoaderSearch/appendToSystemClassLoaderSearch：增加BootstrapClassLoader/SystemClassLoader的搜尋路徑；
   8. isNativeMethodPrefixSupported/setNativeMethodPrefix：判斷JVM是否支援攔截Native Method；