基於Java Instrument的Agent實現

猿碼道發表於2019-03-04

0 介紹

使用 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

相關文章