調試是發現和減少計算機程序或電子儀器設備中程序錯誤的一個過程。最常用的斷點調試技術會在斷點位置停頓，導致應用停止響應。本文將介紹一種Java動態調試技術，希望能對大家有幫助。

1. 動態調試要解決的問題

斷點調試是我們最常使用的調試手段，它可以獲取到方法執行過程中的變量信息，并可以觀察到方法的執行路徑。但斷點調試會在斷點位置停頓，使得整個應用停止響應。在線上停頓應用是致命的，動態調試技術給了我們創造新的調試模式的想象空間。本文將研究Java語言中的動態調試技術，首先概括Java動態調試所涉及的技術基礎，接著介紹我們在Java動態調試領域的思考及實踐，通過結合實際業務場景，設計并實現了一種具備動態性的斷點調試工具Java-debug-tool，顯著提高了故障排查效率。

2. Java Agent技術

JVMTI （JVM Tool Interface）是Java虛擬機對外提供的Native編程接口，通過JVMTI，外部進程可以獲取到運行時JVM的諸多信息，比如線程、GC等。Agent是一個運行在目標JVM的特定程序，它的職責是負責從目標JVM中獲取數據，然后將數據傳遞給外部進程。加載Agent的時機可以是目標JVM啟動之時，也可以是在目標JVM運行時進行加載，而在目標JVM運行時進行Agent加載具備動態性，對于時機未知的Debug場景來說非常實用。下面將詳細分析Java Agent技術的實現細節。

2.1 Agent的實現模式

JVMTI是一套Native接口，在Java SE 5之前，要實現一個Agent只能通過編寫Native代碼來實現。從Java SE 5開始，可以使用Java的Instrumentation接口（java.lang.instrument）來編寫Agent。無論是通過Native的方式還是通過Java Instrumentation接口的方式來編寫Agent，它們的工作都是借助JVMTI來進行完成，下面介紹通過Java Instrumentation接口編寫Agent的方法。

2.1.1 通過Java Instrumentation API

實現Agent啟動方法

Java Agent支持目標JVM啟動時加載，也支持在目標JVM運行時加載，這兩種不同的加載模式會使用不同的入口函數，如果需要在目標JVM啟動的同時加載Agent，那么可以選擇實現下面的方法：

JVM將首先尋找［1］，如果沒有發現［1］，再尋找［2］。如果希望在目標JVM運行時加載Agent，則需要實現下面的方法：

這兩組方法的第一個參數AgentArgs是隨同 “– javaagent”一起傳入的程序參數，如果這個字符串代表了多個參數，就需要自己解析這些參數。inst是Instrumentation類型的對象，是JVM自動傳入的，我們可以拿這個參數進行類增強等操作。

指定Main-Class

Agent需要打包成一個jar包，在ManiFest屬性中指定“Premain-Class”或者“Agent-Class”：

掛載到目標JVM

將編寫的Agent打成jar包后，就可以掛載到目標JVM上去了。如果選擇在目標JVM啟動時加載Agent，則可以使用 “-javaagent：《jarpath》［=《option》］”，具體的使用方法可以使用“Java -Help”來查看。如果想要在運行時掛載Agent到目標JVM，就需要做一些額外的開發了。

com.sun.tools.attach.VirtualMachine 這個類代表一個JVM抽象，可以通過這個類找到目標JVM，并且將Agent掛載到目標JVM上。下面是使用com.sun.tools.attach.VirtualMachine進行動態掛載Agent的一般實現：

首先通過指定的進程ID找到目標JVM，然后通過Attach掛載到目標JVM上，執行加載Agent操作。VirtualMachine的Attach方法就是用來將Agent掛載到目標JVM上去的，而Detach則是將Agent從目標JVM卸載。關于Agent是如何掛載到目標JVM上的具體技術細節，將在下文中進行分析。

2.2 啟動時加載Agent

2.2.1 參數解析

創建JVM時，JVM會進行參數解析，即解析那些用來配置JVM啟動的參數，比如堆大小、GC等；本文主要關注解析的參數為-agentlib、 -agentpath、 -javaagent，這幾個參數用來指定Agent，JVM會根據這幾個參數加載Agent。下面來分析一下JVM是如何解析這幾個參數的。

上面的代碼片段截取自hotspot/src/share/vm/runtime/arguments.cpp中的Arguments：：parse_each_vm_init_arg（const JavaVMInitArgs* args， bool* patch_mod_javabase， Flag：：Flags origin） 函數，該函數用來解析一個具體的JVM參數。這段代碼的主要功能是解析出需要加載的Agent路徑，然后調用add_init_agent函數進行解析結果的存儲。下面先看一下add_init_agent函數的具體實現：

AgentLibraryList是一個簡單的鏈表結構，add_init_agent函數將解析好的、需要加載的Agent添加到這個鏈表中，等待后續的處理。

這里需要注意，解析-javaagent參數有一些特別之處，這個參數用來指定一個我們通過Java Instrumentation API來編寫的Agent，Java Instrumentation API底層依賴的是JVMTI，對-JavaAgent的處理也說明了這一點，在調用add_init_agent函數時第一個參數是“instrument”，關于加載Agent這個問題在下一小節進行展開。到此，我們知道在啟動JVM時指定的Agent已經被JVM解析完存放在了一個鏈表結構中。下面來分析一下JVM是如何加載這些Agent的。

2.2.2 執行加載操作

在創建JVM進程的函數中，解析完JVM參數之后，下面的這段代碼和加載Agent相關：

當JVM判斷出上一小節中解析出來的Agent不為空的時候，就要去調用函數create_vm_init_agents來加載Agent，下面來分析一下create_vm_init_agents函數是如何加載Agent的。

create_vm_init_agents這個函數通過遍歷Agent鏈表來逐個加載Agent。通過這段代碼可以看出，首先通過lookup_agent_on_load來加載Agent并且找到Agent_OnLoad函數，這個函數是Agent的入口函數。如果沒找到這個函數，則認為是加載了一個不合法的Agent，則什么也不做，否則調用這個函數，這樣Agent的代碼就開始執行起來了。對于使用Java Instrumentation API來編寫Agent的方式來說，在解析階段觀察到在add_init_agent函數里面傳遞進去的是一個叫做“instrument”的字符串，其實這是一個動態鏈接庫。在Linux里面，這個庫叫做libinstrument.so，在BSD系統中叫做libinstrument.dylib，該動態鏈接庫在{JAVA_HOME}/jre/lib/目錄下。

2.2.3 Instrument動態鏈接庫

libinstrument用來支持使用Java Instrumentation API來編寫Agent，在libinstrument中有一個非常重要的類稱為：JPLISAgent（Java Programming Language Instrumentation Services Agent），它的作用是初始化所有通過Java Instrumentation API編寫的Agent，并且也承擔著通過JVMTI實現Java Instrumentation中暴露API的責任。

我們已經知道，在JVM啟動的時候，JVM會通過-javaagent參數加載Agent。最開始加載的是libinstrument動態鏈接庫，然后在動態鏈接庫里面找到JVMTI的入口方法：Agent_OnLoad。下面就來分析一下在libinstrument動態鏈接庫中，Agent_OnLoad函數是怎么實現的。

上述代碼片段是經過精簡的libinstrument中Agent_OnLoad實現的，大概的流程就是：先創建一個JPLISAgent，然后將ManiFest中設定的一些參數解析出來， 比如（Premain-Class）等。創建了JPLISAgent之后，調用initializeJPLISAgent對這個Agent進行初始化操作。跟進initializeJPLISAgent看一下是如何初始化的：

這里，我們關注callbacks.VMInit = &eventHandlerVMInit;這行代碼，這里設置了一個VMInit事件的回調函數，表示在JVM初始化的時候會回調eventHandlerVMInit函數。下面來看一下這個函數的實現細節，猜測就是在這里調用了Premain方法：

看到這里，Instrument已經實例化，invokeJavaAgentMainMethod這個方法將我們的Premain方法執行起來了。接著，我們就可以根據Instrument實例來做我們想要做的事情了。

2.3 運行時加載Agent

比起JVM啟動時加載Agent，運行時加載Agent就比較有誘惑力了，因為運行時加載Agent的能力給我們提供了很強的動態性，我們可以在需要的時候加載Agent來進行一些工作。因為是動態的，我們可以按照需求來加載所需要的Agent，下面來分析一下動態加載Agent的相關技術細節。

2.3.1 AttachListener

Attach機制通過Attach Listener線程來進行相關事務的處理，下面來看一下Attach Listener線程是如何初始化的。

我們知道，一個線程啟動之后都需要指定一個入口來執行代碼，Attach Listener線程的入口是attach_listener_thread_entry，下面看一下這個函數的具體實現：

整個函數執行邏輯，大概是這樣的：

拉取一個需要執行的任務：AttachListener：：dequeue。

查詢匹配的命令處理函數。

執行匹配到的命令執行函數。

其中第二步里面存在一個命令函數表，整個表如下：

對于加載Agent來說，命令就是“load”?，F在，我們知道了Attach Listener大概的工作模式，但是還是不太清楚任務從哪來，這個秘密就藏在AttachListener：：dequeue這行代碼里面，接下來我們來分析一下dequeue這個函數：

這是Linux上的實現，不同的操作系統實現方式不太一樣。上面的代碼表面，Attach Listener在某個端口監聽著，通過accept來接收一個連接，然后從這個連接里面將請求讀取出來，然后將請求包裝成一個AttachOperation類型的對象，之后就會從表里查詢對應的處理函數，然后進行處理。

Attach Listener使用一種被稱為“懶加載”的策略進行初始化，也就是說，JVM啟動的時候Attach Listener并不一定會啟動起來。下面我們來分析一下這種“懶加載”策略的具體實現方案。

上面的代碼截取自create_vm函數，DisableAttachMechanism、StartAttachListener和ReduceSignalUsage這三個變量默認都是false，所以AttachListener：：init（）;這行代碼不會在create_vm的時候執行，而vm_start會執行。下面來看一下這個函數的實現細節：

這是在Linux上的實現，是將/tmp/目錄下的.java_pid{pid}文件刪除，后面在創建Attach Listener線程的時候會創建出來這個文件。上面說到，AttachListener：：init（）這行代碼不會在create_vm的時候執行，這行代碼的實現已經在上文中分析了，就是創建Attach Listener線程，并監聽其他JVM的命令請求?，F在來分析一下這行代碼是什么時候被調用的，也就是“懶加載”到底是怎么加載起來的。

這是create_vm中的一段代碼，看起來跟信號相關，其實Attach機制就是使用信號來實現“懶加載“的。下面我們來仔細地分析一下這個過程。

JVM創建了一個新的進程來實現信號處理，這個線程叫“Signal Dispatcher”，一個線程創建之后需要有一個入口，“Signal Dispatcher”的入口是signal_thread_entry：

這段代碼截取自signal_thread_entry函數，截取中的內容是和Attach機制信號處理相關的代碼。這段代碼的意思是，當接收到“SIGBREAK”信號，就執行接下來的代碼，這個信號是需要Attach到JVM上的信號發出來，這個后面會再分析。我們先來看一句關鍵的代碼：AttachListener：：is_init_trigger（）：

首先檢查了一下是否在JVM啟動時啟動了Attach Listener，或者是否已經啟動過。如果沒有，才繼續執行，在/tmp目錄下創建一個叫做.attach_pid%d的文件，然后執行AttachListener的init函數，這個函數就是用來創建Attach Listener線程的函數，上面已經提到多次并進行了分析。到此，我們知道Attach機制的奧秘所在，也就是Attach Listener線程的創建依靠Signal Dispatcher線程，Signal Dispatcher是用來處理信號的線程，當Signal Dispatcher線程接收到“SIGBREAK”信號之后，就會執行初始化Attach Listener的工作。

2.3.2 運行時加載Agent的實現

我們繼續分析，到底是如何將一個Agent掛載到運行著的目標JVM上，在上文中提到了一段代碼，用來進行運行時掛載Agent，可以參考上文中展示的關于“attachAgentToTargetJvm”方法的代碼。這個方法里面的關鍵是調用VirtualMachine的attach方法進行Agent掛載的功能。下面我們就來分析一下VirtualMachine的attach方法具體是怎么實現的。

這個方法通過attachVirtualMachine方法進行attach操作，在MacOS系統中，AttachProvider的實現類是BsdAttachProvider。我們來看一下BsdAttachProvider的attachVirtualMachine方法是如何實現的：

findSocketFile方法用來查詢目標JVM上是否已經啟動了Attach Listener，它通過檢查“tmp/”目錄下是否存在java_pid{pid}來進行實現。如果已經存在了，則說明Attach機制已經準備就緒，可以接受客戶端的命令了，這個時候客戶端就可以通過connect連接到目標JVM進行命令的發送，比如可以發送“load”命令來加載Agent。如果java_pid{pid}文件還不存在，則需要通過sendQuitTo方法向目標JVM發送一個“SIGBREAK”信號，讓它初始化Attach Listener線程并準備接受客戶端連接。可以看到，發送了信號之后客戶端會循環等待java_pid{pid}這個文件，之后再通過connect連接到目標JVM上。

2.3.3 load命令的實現

下面來分析一下，“load”命令在JVM層面的實現：

這個函數先確保加載了java.instrument模塊，之后真正執行Agent加載的函數是 load_agent_library ，這個函數的套路就是加載Agent動態鏈接庫，如果是通過Java instrument API實現的Agent，則加載的是libinstrument動態鏈接庫，然后通過libinstrument里面的代碼實現運行agentmain方法的邏輯，這一部分內容和libinstrument實現premain方法運行的邏輯其實差不多，這里不再做分析。至此，我們對Java Agent技術已經有了一個全面而細致的了解。

3. 動態替換類字節碼技術

3.1 動態字節碼修改的限制

上文中已經詳細分析了Agent技術的實現，我們使用Java Instrumentation API來完成動態類修改的功能，在Instrumentation接口中，通過addTransformer方法來增加一個類轉換器，類轉換器由類ClassFileTransformer接口實現。ClassFileTransformer接口中唯一的方法transform用于實現類轉換，當類被加載的時候，就會調用transform方法，進行類轉換。在運行時，我們可以通過Instrumentation的redefineClasses方法進行類重定義，在方法上有一段注釋需要特別注意：

這里面提到，我們不可以增加、刪除或者重命名字段和方法，改變方法的簽名或者類的繼承關系。認識到這一點很重要，當我們通過ASM獲取到增強的字節碼之后，如果增強后的字節碼沒有遵守這些規則，那么調用redefineClasses方法來進行類的重定義就會失敗。那redefineClasses方法具體是怎么實現類的重定義的呢？它對運行時的JVM會造成什么樣的影響呢？下面來分析redefineClasses的實現細節。

3.2 重定義類字節碼的實現細節

上文中我們提到，libinstrument動態鏈接庫中，JPLISAgent不僅實現了Agent入口代碼執行的路由，而且還是Java代碼與JVMTI之間的一道橋梁。我們在Java代碼中調用Java Instrumentation API的redefineClasses，其實會調用libinstrument中的相關代碼，我們來分析一下這條路徑。

這是InstrumentationImpl中的redefineClasses實現，該方法的具體實現依賴一個Native方法redefineClasses（），我們可以在libinstrument中找到這個Native方法的實現：

redefineClasses這個函數的實現比較復雜，代碼很長。下面是一段關鍵的代碼片段：

可以看到，其實是調用了JVMTI的RetransformClasses函數來完成類的重定義細節。

重定義類的請求會被JVM包裝成一個VM_RedefineClasses類型的VM_Operation，VM_Operation是JVM內部的一些操作的基類，包括GC操作等。VM_Operation由VMThread來執行，新的VM_Operation操作會被添加到VMThread的運行隊列中去，VMThread會不斷從隊列里面拉取VM_Operation并調用其doit等函數執行具體的操作。VM_RedefineClasses函數的流程較為復雜，下面是VM_RedefineClasses的大致流程：

加載新的字節碼，合并常量池，并且對新的字節碼進行校驗工作

清除方法上的斷點

JIT逆優化

進行字節碼替換工作，需要進行更新類itable/vtable等操作

進行類重定義通知

VM_RedefineClasses實現比較復雜的，詳細實現可以參考 RedefineClasses的實現。

4. Java-debug-tool設計與實現

Java-debug-tool是一個使用Java Instrument API來實現的動態調試工具，它通過在目標JVM上啟動一個TcpServer來和調試客戶端通信。調試客戶端通過命令行來發送調試命令給TcpServer，TcpServer中有專門用來處理命令的handler，handler處理完命令之后會將結果發送回客戶端，客戶端通過處理將調試結果展示出來。下面將詳細介紹Java-debug-tool的整體設計和實現。

4.1 Java-debug-tool整體架構

Java-debug-tool包括一個Java Agent和一個用于處理調試命令的核心API，核心API通過一個自定義的類加載器加載進來，以保證目標JVM的類不會被污染。整體上Java-debug-tool的設計是一個Client-Server的架構，命令客戶端需要完整的完成一個命令之后才能繼續執行下一個調試命令。Java-debug-tool支持多人同時進行調試，下面是整體架構圖：

圖4-1-1

下面對每一層做簡單介紹：

交互層：負責將程序員的輸入轉換成調試交互協議，并且將調試信息呈現出來。

連接管理層：負責管理客戶端連接，從連接中讀調試協議數據并解碼，對調試結果編碼并將其寫到連接中去；同時將那些超時未活動的連接關閉。

業務邏輯層：實現調試命令處理，包括命令分發、數據收集、數據處理等過程。

基礎實現層：Java-debug-tool實現的底層依賴，通過Java Instrumentation提供的API進行類查找、類重定義等能力，Java Instrumentation底層依賴JVMTI來完成具體的功能。

在Agent被掛載到目標JVM上之后，Java-debug-tool會安排一個Spy在目標JVM內活動，這個Spy負責將目標JVM內部的相關調試數據轉移到命令處理模塊，命令處理模塊會處理這些數據，然后給客戶端返回調試結果。命令處理模塊會增強目標類的字節碼來達到數據獲取的目的，多個客戶端可以共享一份增強過的字節碼，無需重復增強。下面從Java-debug-tool的字節碼增強方案、命令設計與實現等角度詳細說明。

4.2 Java-debug-tool的字節碼增強方案

Java-debug-tool使用字節碼增強來獲取到方法運行時的信息，比如方法入參、出參等，可以在不同的字節碼位置進行增強，這種行為可以稱為“插樁”，每個“樁”用于獲取數據并將他轉儲出去。Java-debug-tool具備強大的插樁能力，不同的樁負責獲取不同類別的數據，下面是Java-debug-tool目前所支持的“樁”：

方法進入點：用于獲取方法入參信息。

Fields獲取點1：在方法執行前獲取到對象的字段信息。

變量存儲點：獲取局部變量信息。

Fields獲取點2：在方法退出前獲取到對象的字段信息。

方法退出點：用于獲取方法返回值。

拋出異常點：用于獲取方法拋出的異常信息。

通過上面這些代碼樁，Java-debug-tool可以收集到豐富的方法執行信息，經過處理可以返回更加可視化的調試結果。

4.2.1 字節碼增強

Java-debug-tool在實現上使用了ASM工具來進行字節碼增強，并且每個插樁點都可以進行配置，如果不想要什么信息，則沒必要進行對應的插樁操作。這種可配置的設計是非常有必要的，因為有時候我們僅僅是想要知道方法的入參和出參，但Java-debug-tool卻給我們返回了所有的調試信息，這樣我們就得在眾多的輸出中找到我們所關注的內容。如果可以進行配置，則除了入參點和出參點外其他的樁都不插，那么就可以快速看到我們想要的調試數據，這種設計的本質是為了讓調試者更加專注。下面是Java-debug-tool的字節碼增強工作方式：

圖4-2-1

如圖4-2-1所示，當調試者發出調試命令之后，Java-debug-tool會識別命令并判斷是否需要進行字節碼增強，如果命令需要增強字節碼，則判斷當前類+當前方法是否已經被增強過。上文已經提到，字節碼替換是有一定損耗的，這種具有損耗的操作發生的次數越少越好，所以字節碼替換操作會被記錄起來，后續命令直接使用即可，不需要重復進行字節碼增強，字節碼增強還涉及多個調試客戶端的協同工作問題，當一個客戶端增強了一個類的字節碼之后，這個客戶端就鎖定了該字節碼，其他客戶端變成只讀，無法對該類進行字節碼增強，只有當持有鎖的客戶端主動釋放鎖或者斷開連接之后，其他客戶端才能繼續增強該類的字節碼。

字節碼增強模塊收到字節碼增強請求之后，會判斷每個增強點是否需要插樁，這個判斷的根據就是上文提到的插樁配置，之后字節碼增強模塊會生成新的字節碼，Java-debug-tool將執行字節碼替換操作，之后就可以進行調試數據收集了。

經過字節碼增強之后，原來的方法中會插入收集運行時數據的代碼，這些代碼在方法被調用的時候執行，獲取到諸如方法入參、局部變量等信息，這些信息將傳遞給數據收集裝置進行處理。數據收集的工作通過Advice完成，每個客戶端同一時間只能注冊一個Advice到Java-debug-tool調試模塊上，多個客戶端可以同時注冊自己的Advice到調試模塊上。Advice負責收集數據并進行判斷，如果當前數據符合調試命令的要求，Java-debug-tool就會卸載這個Advice，Advice的數據就會被轉移到Java-debug-tool的命令結果處理模塊進行處理，并將結果發送到客戶端。

4.2.2 Advice的工作方式

Advice是調試數據收集器，不同的調試策略會對應不同的Advice。Advice是工作在目標JVM的線程內部的，它需要輕量級和高效，意味著Advice不能做太過于復雜的事情，它的核心接口“match”用來判斷本次收集到的調試數據是否滿足調試需求。如果滿足，那么Java-debug-tool就會將其卸載，否則會繼續讓他收集調試數據，這種“加載Advice” -》 “卸載Advice”的工作模式具備很好的靈活性。

關于Advice，需要說明的另外一點就是線程安全，因為它加載之后會運行在目標JVM的線程中，目標JVM的方法極有可能是多線程訪問的，這也就是說，Advice需要有能力處理多個線程同時訪問方法的能力，如果Advice處理不當，則可能會收集到雜亂無章的調試數據。下面的圖片展示了Advice和Java-debug-tool調試分析模塊、目標方法執行以及調試客戶端等模塊的關系。

圖4-2-2

Advice的首次掛載由Java-debug-tool的命令處理器完成，當一次調試數據收集完成之后，調試數據處理模塊會自動卸載Advice，然后進行判斷，如果調試數據符合Advice的策略，則直接將數據交由數據處理模塊進行處理，否則會清空調試數據，并再次將Advice掛載到目標方法上去，等待下一次調試數據。非首次掛載由調試數據處理模塊進行，它借助Advice按需取數據，如果不符合需求，則繼續掛載Advice來獲取數據，否則對調試數據進行處理并返回給客戶端。

4.3 Java-debug-tool的命令設計與實現

4.3.1 命令執行

上文已經完整的描述了Java-debug-tool的設計以及核心技術方案，本小節將詳細介紹Java-debug-tool的命令設計與實現。首先需要將一個調試命令的執行流程描述清楚，下面是一張用來表示命令請求處理流程的圖片：

圖4-3-1

圖4-3-1簡單的描述了Java-debug-tool的命令處理方式，客戶端連接到服務端之后，會進行一些協議解析、協議認證、協議填充等工作，之后將進行命令分發。服務端如果發現客戶端的命令不合法，則會立即返回錯誤信息，否則再進行命令處理。命令處理屬于典型的三段式處理，前置命令處理、命令處理以及后置命令處理，同時會對命令處理過程中的異常信息進行捕獲處理，三段式處理的好處是命令處理被拆成了多個階段，多個階段負責不同的職責。前置命令處理用來做一些命令權限控制的工作，并填充一些類似命令處理開始時間戳等信息，命令處理就是通過字節碼增強，掛載Advice進行數據收集，再經過數據處理來產生命令結果的過程，后置處理則用來處理一些連接關閉、字節碼解鎖等事項。

Java-debug-tool允許客戶端設置一個命令執行超時時間，超過這個時間則認為命令沒有結果，如果客戶端沒有設置自己的超時時間，就使用默認的超時時間進行超時控制。Java-debug-tool通過設計了兩階段的超時檢測機制來實現命令執行超時功能：首先，第一階段超時觸發，則Java-debug-tool會友好的警告命令處理模塊處理時間已經超時，需要立即停止命令執行，這允許命令自己做一些現場清理工作，當然需要命令執行線程自己感知到這種超時警告；當第二階段超時觸發，則Java-debug-tool認為命令必須結束執行，會強行打斷命令執行線程。超時機制的目的是為了不讓命令執行太長時間，命令如果長時間沒有收集到調試數據，則應該停止執行，并思考是否調試了一個錯誤的方法。當然，超時機制還可以定期清理那些因為未知原因斷開連接的客戶端持有的調試資源，比如字節碼鎖。

4.3.4 獲取方法執行視圖

Java-debug-tool通過下面的信息來向調試者呈現出一次方法執行的視圖：

正在調試的方法信息。

方法調用堆棧。

調試耗時，包括對目標JVM造成的STW時間。

方法入參，包括入參的類型及參數值。

方法的執行路徑。

代碼執行耗時。

局部變量信息。

方法返回結果。

方法拋出的異常。

對象字段值快照。

圖4-3-2展示了Java-debug-tool獲取到正在運行的方法的執行視圖的信息。

圖4-3-2

4.4 Java-debug-tool與同類產品對比分析

Java-debug-tool的同類產品主要是greys，其他類似的工具大部分都是基于greys進行的二次開發，所以直接選擇greys來和Java-debug-tool進行對比。

5. 總結

本文詳細剖析了Java動態調試關鍵技術的實現細節，并介紹了我們基于Java動態調試技術結合實際故障排查場景進行的一點探索實踐；動態調試技術為研發人員進行線上問題排查提供了一種新的思路，我們基于動態調試技術解決了傳統斷點調試存在的問題，使得可以將斷點調試這種技術應用在線上，以線下調試的思維來進行線上調試，提高問題排查效率。
責任編輯人：CC