服務慢了兩天查不出來，掛上 Arthas 十五分鐘定位：4 版升級讓更多人願意用它的原因

2026 年 11 月 2 日，掘金上一篇標題為「為什麼越來越多人用 Arthas 4？」的長文開始流傳。文章作者「蘇三說技術」用一個真實的排障案例開場：一個跑了三年的老服務，每天下午三點左右固定變慢，介面 P99 延遲從 50 毫秒漲到 800 毫秒，CPU 正常、記憶體正常、GC 日誌看不出毛病，團隊查了兩天沒有頭緒。

轉折點是他掛上 Arthas，用兩條命令解決。第一條 thread -n 5 看 CPU 佔用最高的執行緒，發現某個執行緒長期卡在 HashMap.get()；第二條 trace 追該方法呼叫鏈，發現一處本該走本地快取的程式，因為快取 key 拼錯，每次都落到一個同步的遠端呼叫上。遠端服務一慢，執行緒就跟著卡住。全程沒重啟、沒改碼、沒加日誌，十五分鐘結束戰鬥。

這個案例之所以有傳播力，在於它踩中了很多開發團隊的共同痛點：監控儀表板一片綠燈，使用者就是覺得慢。

Arthas 到底解決了什麼

JDK 自帶的 jstack、jmap、jstat 當然能用，但它們有個共同前提：你得先知道該看哪個指標、用哪個工具。Arthas 的做法不同，它是一個 Java Agent，透過 attach 機制掛到正在運行的 JVM 上，像開一個 shell 一樣互動式診斷。

打個比方，傳統工具像健檢報告，你拿到一堆數字，得自己判讀；Arthas 像腹腔鏡手術，人還在運轉中，直接把探頭伸進去看哪個器官出了問題。掛上去之後，watch 看方法的入參回傳值、trace 看呼叫鏈耗時、tt 錄下呼叫快照事後回放，甚至能用 jad 加 redefine 做方法級的熱更新。

4 版的三個升級點

根據原文整理，Arthas 4 相比 3.x 的改變集中在三個方向。

第一是跟上 JDK 的腳步。Arthas 4 要求 JDK 8 以上，官方明確支援 JDK 17、21、25。這對已經把運行時升到新版 JDK 的團隊很實際，不需要為了診斷工具回頭保留舊版環境。同時 Jackson、Fastjson2、OGNL、Netty 等依賴也整批升級，診斷工具本身也是軟體，它自己的依賴安全同樣要顧。

第二是火焰圖能力的補全。內建的 async-profiler 在 4.2.0 升到 4.4，更關鍵的是 4.0.2 起支援 --wall 參數，可以看牆鐘時間。這解決一類很棘手的問題：CPU 不高，介面就是慢。鎖等待、網路 IO 阻塞、資料庫連線池耗盡，這些情況下執行緒在「等」，不消耗 CPU，傳統 CPU 火焰圖完全看不出來。牆鐘火焰圖把等待時間攤開，時間到底花在哪裡一目了然。

第三是 AI 工作流的整合。4 版讓使用者可以用自然語言請 AI 幫忙跑診斷命令。對不熟 Arthas 命令體系的人來說，入門門檻明顯降低。

所以呢

Arthas 的普及反映出線上系統的一個現實：越來越多問題不再是「資源不夠」，而是「某個環節在悄悄地等」。傳統監控盯的是資源水位，Arthas 這類動態探針盯的是程式實際行為，兩者互補而非取代。

不過要留意分寸。能在運行中的 JVM 做診斷甚至熱更新，代表它同時也是一把利器，存取權限與操作規範需要團隊事先約定。工具讓排障變快是一回事，誰能在生產環境掛探針、能看到哪些資料，是另一回事，而且往往更重要。

對每天在跟 P99 延遲搏鬥的工程師來說，這篇文章給的判斷很簡單：如果還在靠重啟掩蓋問題、靠加日誌等下一版部署才看得到結果，動態診斷工具值得排進學習清單。Arthas 4 把 JDK 支援、牆鐘火焰圖與自然語言介面補齊之後，採用的理由又多了三條。