0 介紹
利用 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 語言本身更加強大。
1 基本功能和用法
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 還在虛擬機內存管理，線程控制，方法和變量操作等等方面提供了大量有價值的函數。
1.1 VM啓動前設置Instrument
Instrumentation 的最大作用，就是類定義動態改變和操作。在 Java SE 5 及其後續版本當中，開發者可以在一個普通 Java 程序（帶有 main 函數的 Java 類）運行時，通過 -javaagent參數指定一個特定的 jar 文件（包含 Instrumentation 代理）來啓動 Instrumentation 的代理程序。
1、redefineClasses 的功能比較強大，可以批量轉換很多類。
1.2 VM啓動後動態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 類：
同樣，[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，運行一個外加的代理程序。
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 代碼是：
很有趣不是嗎？因此如果我們要做類似的工作，一個很好的建議是首先在 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。我們可以在我們的 Transformer 裏使用 appendToBootstrapClassLoaderSearch/appendToSystemClassLoaderSearch來完成這個任務。
同時我們可以注意到，在 agent 的 mainfest 里加入 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 包裏的這兩個函數已經可以很好的解決我們的問題了。
1.5 META-INF/MAINIFEST.MF清單
以下是agent jar文件的Manifest Attributes清單：
