什麼是 Arthas？

Arthas 是一款開源線上診斷工具，採用命令列互動模式，支援 web 端線上診斷，同時提供豐富的 Tab 自動補全功能，進一步方便進行問題的定位和診斷。這是一款開源一年多 GitHub star 2 萬，99% 的阿里研發小哥都在用的 Java 終極診斷利器！相對比直接下載使用，我推薦開發者可以試一下通過 IDE外掛 Cloud Toolkit 中使用Arthas 來實現一鍵遠端診斷功能。

得益於 Arthas 強大且豐富的功能，讓 Arthas 能做的事情超乎想象。下面僅僅列舉幾項常見的使用情況，更多的使用場景可以在熟悉了 Arthas 之後自行探索。

• 是否有一個全域性視角來檢視系統的執行狀況？
• 為什麼 CPU 又升高了，到底是哪裡佔用了 CPU ？
• 執行的多執行緒有死鎖嗎？有阻塞嗎？
• 程式執行耗時很長，是哪裡耗時比較長呢？如何監測呢？
• 這個類從哪個 jar 包載入的？為什麼會報各種類相關的 Exception？
• 我改的程式碼為什麼沒有執行到？難道是我沒 commit？分支搞錯了？
• 遇到問題無法在線上 debug，難道只能通過加日誌再重新發布嗎？
• 有什麼辦法可以監控到 JVM 的實時執行狀態？

Arthas 的命令、功能在其官方文件有詳細介紹，下文將介紹一下近期幾個使用場景。

場景 1：定位壓測時的效能瓶頸

平時伺服器請求都很正常。壓測時，依賴的服務、資料庫也都沒有到達瓶頸，但是機器的 CPU 全部飄紅，why？

通過 jstack 命令，只能看到某一時刻的堆疊，沒有抓到真凶。

thread 檢視當前執行緒資訊，檢視執行緒的堆疊。

thread -n 3 -i 10000 可以統計 10 秒內最忙的 3 個執行緒，並且列印它們的堆疊，很容易發現問題。最終發現的問題比較簡單：日誌中列印了 location 的資訊，包括 類名、方法名和行號。

動態獲取程式碼的方法名、行號等資訊，通常是通過 new Throwable() -> 列印 Throwable 的堆疊 -> 擷取堆疊中最頂層的業務程式碼 -> 拆分字串獲取類、方法、行號等資訊, 列印堆疊對效能損耗是比較大的。

場景 2：檢測偶發的超時

有段時間，總是碰到幾次偶爾的超時，但是看日誌都正常，鷹眼的呼叫鏈路都完全 ok，沒有哪一步資料庫操作或者 HSF 呼叫是特別慢的。

各種監控統計的時間維度的耗時，都十分正常，無法找到那個 rt 的尖刺。

想到了可能是日誌的問題，但是沒有證據支撐。

trace 命令能監控每一步的耗時，並且可以配合條件表示式，當耗時超過 xx ms 時列印詳細日誌。

找臺機器，輸入命令，後面的就是靜等了。再次出現 rt 尖刺時，能夠捕捉到耗時的分佈情況。

通過 Arthas 拿到的結果，定位到是日誌列印的問題。同步日誌改為非同步日誌後，問題解決。

場景3：debug？那要是動態位元組碼生成咋辦？

之前碰到過一個 json 序列化時輸出的數字帶不帶引號的問題。當時各種 debug、看程式碼，發現是通過 ASM 動態位元組碼的方式生成的序列化類。到這完全放棄了，debug 已經無法定位問題了。當時通過另外一種方式避免了這種問題。

反過來看這個問題的時候，我們可以通過 Arthas 的 jad 命令，反編譯動態位元組碼生成的類，結合 watch 等命令，定位排查問題。

jad——反編譯指定已載入類的原始碼

還可以通過 mc(menory compiler), redefine 命令線上熱更新程式碼，歡迎探索。

最後

整理的這些資料希望對Java開發的朋友們有所參考以及少走彎路，本文的重點是你有沒有收穫與成長，其餘的都不重要，希望讀者們能謹記這一點。

再免費分享一波我的Java專題面試真題+視訊學習詳解+Java進階學習書籍

其實面試這一塊早在第一個說的25大面試專題就全都有的。以上提及的這些全部的面試+學習的各種筆記資料，我這差不多來回搞了三個多月，收集整理真的很不容易，其中還有很多自己的一些知識總結。正是因為很麻煩，所以對以上這些學習複習資料感興趣，