[[361071]]

對于 Java 的反射使用， 一般用戶都有所了解。特別是在開源框架里更是大量的使用。通過反射，我們能拿到一個Java Class 的信息。那對于 JVM 的內部信息，像堆的使用情況、線程、甚至是創(chuàng)建對象的內存地址、加載的類的內容，該怎么辦呢?

其實在 JVM內，有許多內部的信息，比如上面提到的那些，就類似于生活中的內部消息一樣。你可以想像一些大型應用，一些用戶的數(shù)據(jù)我們只能通過 API 授權的方式拿到，普通用戶正常使用的時候，是不可能獲取到這些內容的。就像做為運行在 JVM 上的普通 Java應用，也很難拿到 JVM 的信息，畢竟 JVM 更底層，是C++ 開發(fā)的。

JVM 會把這些內部信息告訴咱們嗎?

JVM 提供了一些對外的接口，把它的內部信息披露了出來。通過這些接口SA 才得以訪問到 JVM 內部類的結構和地址，也才能從底層觀察到 JVM內部運行的細節(jié)。

你看在SA 圖形界面的HSDB內部，長長的菜單列表，大多都是通過普通Java 應用獲取不到的「內部信息」。

這些都是怎么實現(xiàn)的呢?說到這兒，就不得不提 gHotSpotVMStructs。

JVM 給提供的那些接口，核心是 gHotSpotVMStructs 這個結構。它對外暴露了JVM內部的大量信息，像原始的堆的地址，線程、棧的地址等等。

gHotSpotVMStructs結構指向了很多類以及這些類的字段信息。每個類都有一系列的字段，每個字段又有自己的名字，類型，是否靜態(tài)等等。如果是靜態(tài)字段這個結構還可以用來訪問它的值。對于一個靜態(tài)的對象字段，這個結構體還會提供目標對象的地址。通過這個根地址我們可以開始反查JVM內部的一些組件，包括編譯器，線程還有堆。

所以要獲取和理解JVM 這些內部信息的關鍵，是在如何解析這個gHotSpotVMStructs 結構里面的數(shù)據(jù)。JVM不僅暴露了它的內部類型系統(tǒng)的地址和根對象地址，還有用以解析這些數(shù)據(jù)的一些額外的符號和值。這包含類描述信息和每個字段在這個類里的偏移量，此外 JVM開發(fā)者又做了一系列的工作，手動把JVM內部的C++類的字段映射并加載到了全局的gHotSpotVMStructs結構里。

SA 就是解析這些信息最好的例子。通過圖形界面我們能直觀感受到解析這些信息了解到了什么，通過翻譯 gHotSpotVMStructs暴露出的這些信息，生成Java的包裝類。通過這些包裝類提供出來的接口讓訪問JVM內部系統(tǒng)的工作變的簡單和方便，和普通的Java 應用使用API 類似，解決了訪問和解析內部數(shù)據(jù)的煩惱。

甚至其它的一些調試工具，診斷工具也是基于這些信息來實現(xiàn)的。

通過我們使用SA的方式，其實是通過一個「ptrace」的系統(tǒng)調用，掛起目標JVM 進程，開始讀取 gHotSpotVMStructs 這些內存信息。

看到上面的內容，我們大致理解了SA 的工作原理。那你如果有這樣的需求，是禁止別人通過 SA 等工具來獲取你JVM 的信息呢?

看，打哪兒指哪兒。答案就是重置gHotSpotVMStructs。這樣工具就不能解析出來這些信息了。

Stackoverflow 上有個解決方案，是編譯一個 agent，在啟動JVM 的時候掛上去，并將gHotSpotVMStructs 設置為0。

extern void *gHotSpotVMStructs; 
 
int Agent_OnLoad(void *vm, char *options, void *reserved) { 
    gHotSpotVMStructs = 0; 
    return 0; 
} 

啟動的時候，掛接到JVM上。

java -agentpath:/path/to/libnostructs.so ... 

再去執(zhí)行SA 這些工具的時候，就會拋出異常提示信息有問題

Exception in thread "main" java.lang.reflect.InvocationTargetException 
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
        at java.lang.reflect.Method.invoke(Method.java:498) 
        at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) 
        at sun.tools.jstack.JStack.main(JStack.java:106) 
Caused by: java.lang.RuntimeException: gHotSpotVMStructs was not initialized properly in the remote process; can not continue 
        at sun.jvm.hotspot.HotSpotTypeDataBase.readVMStructs(HotSpotTypeDataBase.java:418) 
        at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:91) 
        at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:395) 
        at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305) 
        at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140) 
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:185) 
        at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) 
        at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) 
        ... 6 more 

本文轉載自微信公眾號「Tomcat那些事兒」，可以通過以下二維碼關注。轉載本文請聯(lián)系Tomcat那些事兒公眾號。