Java動態追蹤技術探究
在遙遠的希艾斯星球爪哇國塞沃城中，兩名年輕的程式設計師正在為一件事情苦惱，程式出問題了，一時看不出問題出在哪裡，於是有了以下對話：
“Debug一下吧。”
“線上機器，沒開Debug埠。”
“看日誌，看看請求值和返回值分別是什麼？”
“那段程式碼沒列印日誌。”
“改程式碼，加日誌，重新發布一次。”
“懷疑是執行緒池的問題，重啟會破壞現場。”
長達幾十秒的沉默之後：“據說，排查問題的最高境界，就是隻通過Review程式碼來發現問題。”
比幾十秒長几十倍的沉默之後：“我輪詢了那段程式碼一十七遍之後，終於得出一個結論。”
“結論是？”
“我還沒到達只通過Review程式碼就能發現問題的至高境界。”
從JSP說起
對於大多數Java程式設計師來說，早期的時候，都會接觸到一個叫做JSP（Java Server Pages）的技術。雖然這種技術，在前後端程式碼分離、前後端邏輯分離、前後端組織架構分離的今天來看，已經過時了，但是其中還是有一些有意思的東西，值得拿出來說一說。
當時剛剛處於Java入門時期的我們，大多數精力似乎都放在了JSP的頁面展示效果上了：
“這個表格顯示的行數不對”
“原來是for迴圈寫的有問題，改一下，重新整理頁面再試一遍”
“嗯，好了，表格顯示沒問題了，但是，登入人的姓名沒取到啊，是不是Sesstion獲取有問題？”
“有可能，我再改一下，一會兒再重新整理試試”
......
在一遍一遍修改程式碼重新整理瀏覽器頁面重試的時候，我們自己也許並沒有注意到一件很酷的事情：我們修改完程式碼，居然只是簡單地重新整理一遍瀏覽器頁面，修改就生效了，整個過程並沒有重啟JVM。按照我們的常識，Java程式一般都是在啟動時載入類檔案，如果都像JSP這樣修改完程式碼，不用重啟就生效的話，那文章開頭的問題就可以解決了啊：Java檔案中加一段日誌列印的程式碼，不重啟就生效，既不破壞現場，又可以定位問題。忍不住試一試：修改、編譯、替換class檔案。額，不行，新改的程式碼並沒有生效。那為什麼偏偏JSP可以呢？讓我們先來看看JSP的執行原理。
當我們開啟瀏覽器，請求訪問一個JSP檔案的時候，整個過程是這樣的:
JSP檔案修改過後，之所以能及時生效，是因為Web容器（Tomcat）會檢查請求的JSP檔案是否被更改過。如果發生過更改，那麼就將JSP檔案重新解析翻譯成一個新的Sevlet類，並載入到JVM中。之後的請求，都會由這個新的Servet來處理。這裡有個問題，根據Java的類載入機制，在同一個ClassLoader中，類是不允許重複的。為了繞開這個限制，Web容器每次都會建立一個新的ClassLoader例項，來載入新編譯的Servlet類。之後的請求都會由這個新的Servlet來處理，這樣就實現了新舊JSP的切換。
HTTP服務是無狀態的，所以JSP的場景基本上都是一次性消費，這種通過建立新的ClassLoader來“替換”class的做法行得通，但是對於其他應用，比如Spring框架，即便這樣做了，物件多數是單例，對於記憶體中已經建立好的物件，我們無法通過這種建立新的ClassLoader例項的方法來修改物件行為。
我就是想不重啟應用加個日誌列印，就這麼難嗎？
Java物件行為
既然JSP的辦法行不通，那我們來看看還有沒有其他的辦法。仔細想想，我們會發現，文章開頭的問題本質上是動態改變記憶體中已存在物件的行為的問題。所以，我們得先弄清楚JVM中和物件行為有關的地方在哪裡，有沒有更改的可能性。
我們都知道，物件使用兩種東西來描述事物：行為和屬性。舉個例子：
public class Person{ private int age; private String name; public void speak(String str) { System.out.println(str); } public Person(int age, String name) { this.age = age; this.name = name; } } 複製程式碼
上面Person類中age和name是屬性，speak是行為。物件是類的事例，每個物件的屬性都屬於物件本身，但是每個物件的行為卻是公共的。舉個例子，比如我們現在基於Person類建立了兩個物件，personA和personB：
Person personA = new Person(43, "lixunhuan"); personA.speak("我是李尋歡"); Person personB = new Person(23, "afei"); personB.speak("我是阿飛"); 複製程式碼
personA和personB有各自的姓名和年齡，但是有共同的行為：speak。想象一下，如果我們是Java語言的設計者，我們會怎麼儲存物件的行為和屬性呢？
“很簡單，屬性跟著物件走，每個物件都存一份。行為是公共的東西，抽離出來，單獨放到一個地方。”
“咦？抽離出公共的部分，跟程式碼複用好像啊。”
“大道至簡，很多東西本來都是殊途同歸。”
也就是說，第一步我們首先得找到儲存物件行為的這個公共的地方。一番搜尋之後，我們發現這樣一段描述：
Method area is created on virtual machine startup, shared among all Java virtual machine threads and it is logically part of heap area. It stores per-class structures such as the run-time constant pool, field and method data, and the code for methods and constructors.
Java的物件行為（方法、函式）是儲存在方法區的。
“方法區中的資料從哪來？”
“方法區中的資料是類載入時從class檔案中提取出來的。”
“class檔案從哪來？”
“從Java或者其他符合JVM規範的原始碼中編譯而來。”
“原始碼從哪來？”
“廢話，當然是手寫！”
“倒著推，手寫沒問題，編譯沒問題，至於載入......有沒有辦法載入一個已經載入過的類呢？如果有的話，我們就能修改位元組碼中目標方法所在的區域，然後重新載入這個類，這樣方法區中的物件行為（方法）就被改變了，而且不改變物件的屬性，也不影響已經存在物件的狀態，那麼就可以搞定這個問題了。可是，這豈不是違背了JVM的類載入原理？畢竟我們不想改變ClassLoader。”
“少年，可以去看看 java.lang.instrument.Instrumentation 。”
java.lang.instrument.Instrumentation
看完文件之後，我們發現這麼兩個介面：redefineClasses和retransformClasses。一個是重新定義class，一個是修改class。這兩個大同小異，看reDefineClasses的說明：
This method is used to replace the definition of a class without reference to the existing class file bytes, as one might do when recompiling from source for fix-and-continue debugging. Where the existing class file bytes are to be transformed (for example in bytecode instrumentation) retransformClasses should be used.
都是替換已經存在的class檔案，redefineClasses是自己提供位元組碼檔案替換掉已存在的class檔案，retransformClasses是在已存在的位元組碼檔案上修改後再替換之。
當然，執行時直接替換類很不安全。比如新的class檔案引用了一個不存在的類，或者把某個類的一個field給刪除了等等，這些情況都會引發異常。所以如文件中所言，instrument存在諸多的限制：
The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions. The class file bytes are not checked, verified and installed until after the transformations have been applied, if the resultant bytes are in error this method will throw an exception.
我們能做的基本上也就是簡單修改方法內的一些行為，這對於我們開頭的問題，列印一段日誌來說，已經足夠了。當然，我們除了通過reTransform來列印日誌，還能做很多其他非常有用的事情，這個下文會進行介紹。
那怎麼得到我們需要的class檔案呢？一個最簡單的方法，是把修改後的Java檔案重新編譯一遍得到class檔案，然後呼叫redefineClasses替換。但是對於沒有（或者拿不到，或者不方便修改）原始碼的檔案我們應該怎麼辦呢？其實對於JVM來說，不管是Java也好，Scala也好，任何一種符合JVM規範的語言的原始碼，都可以編譯成class檔案。JVM的操作物件是class檔案，而不是原始碼。所以，從這種意義上來講，我們可以說“JVM跟語言無關”。既然如此，不管有沒有原始碼，其實我們只需要修改class檔案就行了。
直接操作位元組碼
Java是軟體開發人員能讀懂的語言，class位元組碼是JVM能讀懂的語言，class位元組碼最終會被JVM解釋成機器能讀懂的語言。無論哪種語言，都是人創造的。所以，理論上（實際上也確實如此）人能讀懂上述任何一種語言，既然能讀懂，自然能修改。只要我們願意，我們完全可以跳過Java編譯器，直接寫位元組碼檔案，只不過這並不符合時代的發展罷了，畢竟高階語言設計之始就是為我們人類所服務，其開發效率也比機器語言高很多。
對於人類來說，位元組碼檔案的可讀性遠遠沒有Java程式碼高。儘管如此，還是有一些傑出的程式設計師們創造出了可以用來直接編輯位元組碼的框架，提供介面可以讓我們方便地操作位元組碼檔案，進行注入修改類的方法，動態創造一個新的類等等操作。其中最著名的框架應該就是ASM了，cglib、Spring等框架中對於位元組碼的操作就建立在ASM之上。
我們都知道，Spring的AOP是基於動態代理實現的，Spring會在執行時動態建立代理類，代理類中引用被代理類，在被代理的方法執行前後進行一些神祕的操作。那麼，Spring是怎麼在執行時建立代理類的呢？動態代理的美妙之處，就在於我們不必手動為每個需要被代理的類寫代理類程式碼，Spring在執行時會根據需要動態地創造出一個類，這裡創造的過程並非通過字串寫Java檔案，然後編譯成class檔案，然後載入。Spring會直接“創造”一個class檔案，然後載入，創造class檔案的工具，就是ASM了。
到這裡，我們知道了用ASM框架直接操作class檔案，在類中加一段列印日誌的程式碼，然後呼叫retransformClasses就可以了。
BTrace
截止到目前，我們都是停留在理論描述的層面。那麼如何進行實現呢？先來看幾個問題：
- 在我們的工程中，誰來做這個尋找位元組碼，修改位元組碼，然後reTransform的動作呢？我們並非先知，不可能知道未來有沒有可能遇到文章開頭的這種問題。考慮到價效比，我們也不可能在每個工程中都開發一段專門做這些修改位元組碼、重新載入位元組碼的程式碼。
- 如果JVM不在本地，在遠端呢？
- 如果連ASM都不會用呢？能不能更通用一些，更“傻瓜”一些。
幸運的是，因為有BTrace的存在，我們不必自己寫一套這樣的工具了。什麼是BTrace呢？ BTrace 已經開源，專案描述極其簡短：
A safe, dynamic tracing tool for the Java platform.
BTrace是基於Java語言的一個安全的、可提供動態追蹤服務的工具。BTrace基於ASM、Java Attach Api、Instruments開發，為使用者提供了很多註解。依靠這些註解，我們可以編寫BTrace指令碼（簡單的Java程式碼）達到我們想要的效果，而不必深陷於ASM對位元組碼的操作中不可自拔。
看BTrace官方提供的一個簡單例子：攔截所有java.io包中所有類中以read開頭的方法，列印類名、方法名和引數名。當程式IO負載比較高的時候，就可以從輸出的資訊中看到是哪些類所引起，是不是很方便？
package com.sun.btrace.samples; import com.sun.btrace.annotations.*; import com.sun.btrace.AnyType; import static com.sun.btrace.BTraceUtils.*; /** * This sample demonstrates regular expression * probe matching and getting input arguments * as an array - so that any overload variant * can be traced in "one place". This example * traces any "readXX" method on any class in * java.io package. Probed class, method and arg * array is printed in the action. */ @BTrace public class ArgArray { @OnMethod( clazz="/java\\.io\\..*/", method="/read.*/" ) public static void anyRead(@ProbeClassName String pcn, @ProbeMethodName String pmn, AnyType[] args) { println(pcn); println(pmn); printArray(args); } } 複製程式碼
再來看另一個例子：每隔2秒列印截止到當前建立過的執行緒數。
package com.sun.btrace.samples; import com.sun.btrace.annotations.*; import static com.sun.btrace.BTraceUtils.*; import com.sun.btrace.annotations.Export; /** * This sample creates a jvmstat counter and * increments it everytime Thread.start() is * called. This thread count may be accessed * from outside the process. The @Export annotated * fields are mapped to jvmstat counters. The counter * name is "btrace." + <className> + "." + <fieldName> */ @BTrace public class ThreadCounter { // create a jvmstat counter using @Export @Export private static long count; @OnMethod( clazz="java.lang.Thread", method="start" ) public static void onnewThread(@Self Thread t) { // updating counter is easy. Just assign to // the static field! count++; } @OnTimer(2000) public static void ontimer() { // we can access counter as "count" as well // as from jvmstat counter directly. println(count); // or equivalently ... println(Counters.perfLong("btrace.com.sun.btrace.samples.ThreadCounter.count")); } } 複製程式碼
看了上面的用法是不是有所啟發？忍不住冒出來許多想法。比如檢視HashMap什麼時候會觸發rehash，以及此時容器中有多少元素等等。
有了BTrace，文章開頭的問題可以得到完美的解決。至於BTrace具體有哪些功能，指令碼怎麼寫，這些Git上BTrace工程中有大量的說明和舉例，網上介紹BTrace用法的文章更是恆河沙數，這裡就不再贅述了。
我們明白了原理，又有好用的工具支援，剩下的就是發揮我們的創造力了，只需在合適的場景下合理地進行使用即可。
既然BTrace能解決上面我們提到的所有問題，那麼BTrace的架構是怎樣的呢？
BTrace主要有下面幾個模組：
- BTrace指令碼：利用BTrace定義的註解，我們可以很方便地根據需要進行指令碼的開發。
- Compiler：將BTrace指令碼編譯成BTrace class檔案。
- Client：將class檔案傳送到Agent。
- Agent：基於Java的Attach Api，Agent可以動態附著到一個執行的JVM上，然後開啟一個BTrace Server，接收client發過來的BTrace指令碼；解析指令碼，然後根據指令碼中的規則找到要修改的類；修改位元組碼後，呼叫Java Instrument的reTransform介面，完成對物件行為的修改並使之生效。
整個BTrace的架構大致如下：
BTrace最終借Instruments實現class的替換。如上文所說，出於安全考慮，Instruments在使用上存在諸多的限制，BTrace也不例外。BTrace對JVM來說是“只讀的”，因此BTrace指令碼的限制如下：
- 不允許建立物件
- 不允許建立陣列
- 不允許拋異常
- 不允許catch異常
- 不允許隨意呼叫其他物件或者類的方法，只允許呼叫com.sun.btrace.BTraceUtils中提供的靜態方法（一些資料處理和資訊輸出工具）
- 不允許改變類的屬性
- 不允許有成員變數和方法，只允許存在 static public void 方法
- 不允許有內部類、巢狀類
- 不允許有同步方法和同步塊
- 不允許有迴圈
- 不允許隨意繼承其他類（當然，java.lang.Object除外）
- 不允許實現介面
- 不允許使用assert
- 不允許使用Class物件
如此多的限制，其實可以理解。BTrace要做的是，雖然修改了位元組碼，但是除了輸出需要的資訊外，對整個程式的正常執行並沒有影響。
Arthas
BTrace指令碼在使用上有一定的學習成本，如果能把一些常用的功能封裝起來，對外直接提供簡單的命令即可操作的話，那就再好不過了。阿里的工程師們早已想到這一點，就在去年（2018年9月份），阿里巴巴開源了自己的Java診斷工具—— Arthas 。Arthas提供簡單的命令列操作，功能強大。究其背後的技術原理，和本文中提到的大致無二。Arthas的文件很全面，想詳細瞭解的話可以戳這裡。
本文旨在說明Java動態追蹤技術的來龍去脈，掌握技術背後的原理之後，只要願意，各位讀者也可以開發出自己的“冰封王座”出來。
尾聲：三生萬物
現在，讓我們試著站在更高的地方“俯瞰”這些問題。
Java的Instruments給執行時的動態追蹤留下了希望，Attach API則給執行時動態追蹤提供了“出入口”，ASM則大大方便了“人類”操作Java位元組碼的操作。
基於Instruments和Attach API前輩們創造出了諸如JProfiler、Jvisualvm、BTrace、Arthas這樣的工具。以ASM為基礎發展出了cglib、動態代理，繼而是應用廣泛的Spring AOP。
Java是靜態語言，執行時不允許改變資料結構。然而，Java 5引入Instruments，Java 6引入Attach API之後，事情開始變得不一樣了。雖然存在諸多限制，然而，在前輩們的努力下，僅僅是利用預留的近似於“只讀”的這一點點狹小的空間，仍然創造出了各種大放異彩的技術，極大地提高了軟體開發人員定位問題的效率。
計算機應該是人類有史以來最偉大的發明之一，從電磁感應磁生電，到高低電壓模擬0和1的位元，再到二進位制表示出幾種基本型別，再到基本型別表示出無窮的物件，最後無窮的物件組合互動模擬現實生活乃至整個宇宙。
兩千五百年前，《道德經》有言：“道生一，一生二，二生三，三生萬物。”
兩千五百年後，計算機的發展過程也大抵如此吧。