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

截止到目前，咱們都是停留在理論描述的層面。那麼如何進行實現呢？先來看幾個問題：

1. 在咱們的工程中，誰來作這個尋找字節碼，修改字節碼，而後reTransform的動做呢？咱們並不是先知，不可能知道將來有沒有可能遇到文章開頭的這種問題。考慮到性價比，咱們也不可能在每一個工程中都開發一段專門作這些修改字節碼、從新加載字節碼的代碼。
2. 若是JVM不在本地，在遠程呢？
3. 若是連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主要有下面幾個模塊：

1. BTrace腳本：利用BTrace定義的註解，咱們能夠很方便地根據須要進行腳本的開發。
2. Compiler：將BTrace腳本編譯成BTrace class文件。
3. Client：將class文件發送到Agent。
4. Agent：基於Java的Attach Api，Agent能夠動態附着到一個運行的JVM上，而後開啓一個BTrace Server，接收client發過來的BTrace腳本；解析腳本，而後根據腳本中的規則找到要修改的類；修改字節碼後，調用Java Instrument的reTransform接口，完成對對象行爲的修改並使之生效。

整個BTrace的架構大體以下：

BTrace最終借Instruments實現class的替換。如上文所說，出於安全考慮，Instruments在使用上存在諸多的限制，BTrace也不例外。BTrace對JVM來講是「只讀的」，所以BTrace腳本的限制以下：

1. 不容許建立對象
2. 不容許建立數組
3. 不容許拋異常
4. 不容許catch異常
5. 不容許隨意調用其餘對象或者類的方法，只容許調用com.sun.btrace.BTraceUtils中提供的靜態方法（一些數據處理和信息輸出工具）
6. 不容許改變類的屬性
7. 不容許有成員變量和方法，只容許存在static public void方法
8. 不容許有內部類、嵌套類
9. 不容許有同步方法和同步塊
10. 不容許有循環
11. 不容許隨意繼承其餘類（固然，java.lang.Object除外）
12. 不容許實現接口
13. 不容許使用assert
14. 不容許使用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的比特，再到二進制表示出幾種基本類型，再到基本類型表示出無窮的對象，最後無窮的對象組合交互模擬現實生活乃至整個宇宙。

兩千五百年前，《道德經》有言：「道生一，一輩子二，二生三，三生萬物。」

兩千五百年後，計算機的發展過程也大抵如此吧。

做者簡介

• 高揚，2017年加入美團打車，負責美團打車結算系統的開發。