：Java線上問題排查利器，無需重啟即可診斷JVM)
真香定律放在技術(shù)圈一樣適用。以前總覺得線上排查問題靠日志、靠監(jiān)控、靠人肉加日志就夠用了直到真正把 Arthas 用起來才發(fā)現(xiàn)以前那些操作有多繞。Arthas 是一個開源的 Java 診斷工具不用改代碼、不用重啟服務(wù)可以直接 attach 到正在運行的 JVM 進程上實時查看類加載情況、方法出入?yún)ⅰ⒄{(diào)用棧、線程狀態(tài)、JVM 指標還能反編譯和在線熱更新。它專門解決一類問題線上偶發(fā)、日志不全、無法本地復現(xiàn)、一重啟現(xiàn)場就沒了。無論你是后端開發(fā)、維護過老項目還是正在被“線上 bug 怎么都復現(xiàn)不了”折磨這篇文章都值得花十分鐘讀完。1. 為什么說它是排查線上問題的“真香”工具1.1 傳統(tǒng)排查方式的三座大山先聊聊大家最熟悉的排查流程。遇到線上故障第一反應(yīng)通常是翻日志。但日志工具抄出來的往往是“結(jié)果”不是“過程”很多關(guān)鍵參數(shù)、臨時變量、調(diào)用時序根本不存在。如果日志里什么都有那問題可能早就被監(jiān)控平臺發(fā)現(xiàn)了現(xiàn)實往往是日志不夠、不夠細、沒有參數(shù)上下文。接著你會想本地復現(xiàn)把線上數(shù)據(jù)導出來構(gòu)造請求打一遍結(jié)果發(fā)現(xiàn)本地怎么都復現(xiàn)不出來。因為并發(fā)量、緩存狀態(tài)、時鐘順序、臟數(shù)據(jù)都可能影響最終結(jié)果本地環(huán)境永遠只是線上環(huán)境的一種近似。最后一招是加日志重啟改一行 log.info編譯打包發(fā)版等流量進入再看日志這中間耗時少說半小時多則幾個小時而且頻繁重啟會讓現(xiàn)場被破壞流量重放也未必能還原問題。這三座大山我相信每個后端都經(jīng)歷過。Arthas 恰好能繞開它們不需要提前埋點因為它能在運行時直接查看真實出入?yún)⒉恍枰磸桶l(fā)布因為它直接操作當前進程不需要靠猜因為它能把調(diào)用路徑和方法執(zhí)行細節(jié)攤開給你看。用過一次之后你會真心覺得“真香”。1.2 原理attach 與字節(jié)碼增強要理解 Arthas 為什么能做到這些得先知道它的原理基礎(chǔ)。Arthas 本質(zhì)上利用了 Java 的 attach 機制和字節(jié)碼增強技術(shù)。attach 是 JDK 提供的一種能力允許一個 JVM 進程運行時連接另一個 JVM 進程并通過 Agent 方式執(zhí)行操作。字節(jié)碼增強則是在類加載或運行時對已經(jīng)加載的類做動態(tài)修改在方法執(zhí)行前后插入攔截邏輯相當于給方法裝上一套“臨時探針”。這套探針是臨時的JVM 一重啟就沒了不會影響原有邏輯。原理本身在 Java 生態(tài)里不算多新鮮但真正難的是把這一套能力封裝得好用做成命令行交互式的產(chǎn)品。Arthas 做到的正是這一點從啟動到使用幾乎不需要在應(yīng)用代碼里增加任何依賴這對排查場景來說是極大的優(yōu)勢。1.3 什么時候該想到用它很多人問什么場景下 Arthas 才是剛需。我的判斷標準很簡單只要你遇到“日志看不出來、重啟代價高、需要確認運行期狀態(tài)”這三個條件中的兩個就該考慮它。典型場景包括接口耗時突然變長、CPU 飆升、線程池被打滿、緩存數(shù)據(jù)異常、灰度環(huán)境某個請求表現(xiàn)不一致、老項目沒有源碼無法重新編譯。這里有一個容易被忽略的點Arthas 不是只給“救火”用的。在正常的壓測、聯(lián)調(diào)、性能分析階段也可以主動用它。我經(jīng)常在壓測時開著 dashboard一邊加壓一邊觀察線程池大小、GC 頻率和熱點方法比事后看測試報告直觀得多。因為它不是從統(tǒng)計數(shù)據(jù)里做推測而是直接從運行中的 JVM 里拿事實。1.4 為什么團隊應(yīng)該統(tǒng)一學習Arthas 這類工具個人會用和團隊都會用的效果差別很大。一個人掌握遇到問題只能是他上團隊都掌握任何值班的人都能快速定位初級問題不用每次都把核心開發(fā)叫起來看服務(wù)器。我見過不少團隊把 Arthas 列為后端必修技能要求每個人至少掌握 dashboard、thread、watch、trace 四個命令的基本用法我覺得是非常務(wù)實的做法。2. 上手必須先掌握的 6 個高頻命令命令速查表先放在前面后面會逐個細講命令用途典型場景dashboard全局面板CPU、內(nèi)存、GC、線程狀態(tài)一眼看全watch觀察方法出入?yún)⒋_認參數(shù)是否正常、異常在哪拋出trace方法調(diào)用鏈耗時定位慢請求卡在哪個子調(diào)用thread線程分析CPU飆高、死鎖、線程阻塞jad反編譯看線上實際運行的代碼mc redefine熱更新緊急修復后臨時止損2.1 啟動與選擇進程java -jar arthas-boot.jarArthas 的使用路徑非常直接。第一步下載 arthas-boot.jar放到服務(wù)器某個目錄下執(zhí)行java -jar arthas-boot.jar啟動后它會自動列出當前機器上所有 Java 進程輸入序號就能 attach。如果想跳過交互直接選進程可以在后面直接加 PIDjava -jar arthas-boot.jar 1234512345 是目標進程的進程號。剛上手時我建議大家執(zhí)行 help 看看當前版本支持的命令列表因為不同版本之間命令細節(jié)會有差異老是照著老資料敲容易踩坑。有一個小細節(jié)Arthas 本身運行需要 JDK但需要 attach 的目標進程不一定要用 JDK 啟動部分 JRE 環(huán)境也可以兼容。不過實際部署中建議用和運行環(huán)境同一版本的 JDK 去啟動 Arthas 客戶端減少無謂的兼容性問題。attach 成功后會進入交互終端提示符變成$所有命令都在這里輸入。2.2 dashboard 一眼看全局attach 成功后的第一個建議命令是 dashboard。它會實時刷新一個面板展示 CPU 占用率、內(nèi)存使用、GC 次數(shù)、線程狀態(tài)分布、每個線程的 CPU 消耗等信息。這等于給 JVM 裝了一個實時監(jiān)控屏幕打開它就能快速判斷問題在哪一層是 CPU 整體打滿還是內(nèi)存上漲觸發(fā)頻繁 GC還是某個線程卡死。初次使用的人容易被大量指標淹沒我一般只看四樣東西最上面的 CPU 使用率、內(nèi)存區(qū)域變化、GC 頻率、線程狀態(tài)里 BLOCKED 和 WAITING 的數(shù)量。如果 GC 頻率異常優(yōu)先排查堆內(nèi)存和對象分配如果有大量 BLOCKED 線程優(yōu)先找鎖競爭。面板是持續(xù)刷新的按 q 可以退出回到交互終端。2.3 watch 查看入?yún)?、返回值和異常watch 是線上排查使用頻率最高的命令沒有之一。它的作用是對指定方法觀察當方法被調(diào)用時打印出入?yún)ⅰ⒎祷刂祷蛘弋惓Ｐ畔?。watch com.example.order.OrderServiceImpl createOrder {params, returnObj, throwExp} -x 2這條命令的意思是觀察 OrderServiceImpl 類的 createOrder 方法當它執(zhí)行時打印入?yún)?、返回值和異常對象嵌套展開深度 2 層。這里用了 OGNL 表達式用單引號包裹內(nèi)置變量包括 params 數(shù)組、returnObj 和 throwExp。我第一次用 watch 排查問題時整個人的感覺就是開了天眼。以前要加日志重新發(fā)版才能看到的參數(shù)現(xiàn)在直接在當前進程里實時看到而且可以臨時加條件只觀察特定用戶或特定業(yè)務(wù)類型watch com.example.order.OrderServiceImpl createOrder {params[0]} params[0].userId 10086 -x 3條件表達式寫最后返回布爾值只有滿足條件才打印。這樣在流量大的接口下看不會被無關(guān)請求刷屏。2.4 trace 定位方法耗時分布如果說 watch 解決的是“參數(shù)對不對”trace 解決的就是“時間花在哪”。它會輸出指定方法的調(diào)用鏈路上每個子方法的耗時自動計算總耗時和每個節(jié)點耗時執(zhí)行效果類似一棵調(diào)用樹trace com.example.order.OrderServiceImpl createOrder命令執(zhí)行后目標方法一旦被調(diào)用你會看到類似下面的輸出---createOrder() # 總耗時 823ms ---checkStock() # 56ms ---deductBalance() # 720ms ---sendMessage() # 47ms順著耗時最大的節(jié)點繼續(xù)往下 trace逐層鉆取就能鎖定真正慢的底層方法。這個過程就像剝洋蔥把慢請求一層層拆到最小執(zhí)行單元。有一點要提醒trace 是通過字節(jié)碼增強實現(xiàn)的它只增強執(zhí)行命令之后發(fā)生的調(diào)用歷史調(diào)用不會回溯。所以想抓到想要的 trace 結(jié)果必須讓目標請求再進來一次。如果接口觸發(fā)頻率低可以配合定時任務(wù)或者手動打一個測試請求。2.5 thread比 jstack 更實用的線程分析很多同學排查線程問題只會 jstack但 jstack 一下輸出大量線程棧分不清哪個線程才是問題源頭。Arthas 的 thread 命令可以直接按 CPU 消耗排序這個能力非常實用thread -n 3它會打印出 CPU 占用最高的 3 個線程同時帶上對應(yīng)線程棧。對比 jstack 還得自己去數(shù)線程 ID、對應(yīng) 16 進制換算效率高了一個量級。它還能直接查死鎖thread -bFound one Java-level deadlock: thread-1: waiting to lock monitor ...thread -b會直接輸出檢測結(jié)果和相關(guān)線程棧不用再從 jstack 輸出里手工解析 Locked ownable synchronizers。如果需要看指定線程可以帶線程 ID 精確查看這個在分析阻塞場景時很管用。2.6 jad mc redefine 實現(xiàn)在線熱更新這一組命令要謹慎使用但在緊急情況下非常救命。jad 用于反編譯已加載的類可以看線上運行的真實代碼而不是本地倉庫里可能已經(jīng)過期的版本mc 是內(nèi)存編譯基于 jad 查看后的源碼在內(nèi)存里重新編譯redefine 是把編譯好的字節(jié)碼替換到運行中的 JVM 里。jad --source-only com.example.order.OrderServiceImpl /tmp/OrderServiceImpl.java mc /tmp/OrderServiceImpl.java -d /tmp redefine /tmp/com/example/order/OrderServiceImpl.class熱更新最典型的使用場景是線上有 bug 需要臨時改一行邏輯發(fā)布流程要走審批這時先用 Arthas 做臨時修復讓服務(wù)先恢復然后馬上走正規(guī)發(fā)布。要注意這個操作不會改磁盤上的 class 文件也不會寫回 jar 包服務(wù)一重啟就失效。而且不是所有代碼都能熱更新成功增加類、改變方法簽名的場景通常會失敗。3. 實戰(zhàn)從幾個真實故障看 Arthas 的實際用法3.1 場景一CPU 飆高快速定位到正則災難性回溯我先講一個最常見的 CPU 100% 問題。某服務(wù)在活動流量上來后CPU 使用率持續(xù)接近滿核業(yè)務(wù)方反饋接口響應(yīng)很慢。按老辦法先看 top 找到進程 PID然后 jstack 導出線程棧再做 16 進制轉(zhuǎn)換找到對應(yīng)線程整個過程相當繁瑣。用 Arthas 的流程會快很多。attach 之后先執(zhí)行 dashboard整體看一眼 CPU 和線程狀態(tài)當時很明顯看到幾個線程占用 CPU 非常夸張。然后執(zhí)行thread -n 5它直接給出了 CPU 最高的 5 個線程及其調(diào)用棧。我看到一個線程棧反復停在同一個業(yè)務(wù)方法里跟進 trace 這個方法發(fā)現(xiàn)內(nèi)部有一段非常復雜的字符串正則匹配在特定輸入下觸發(fā)災難性回溯CPU 全部耗在了正則引擎內(nèi)部。定位過程前后不到五分鐘全程沒有重啟服務(wù)。定位到原因之后我用 jad 反編譯出當前代碼把正則邏輯臨時替換成樸素的字符串前綴匹配通過 mc 和 redefine 熱更新到線上進程服務(wù)立刻恢復。這個案例給我的最大感觸是CPU 飆高和接口慢本質(zhì)上都是“定位問題”的效率問題。只要能看到線程在干什么排查時間就能從小時級縮短到分鐘級。3.2 場景二接口偶發(fā)超時trace 逐層揪出隱藏阻塞另一個案例是某接口偶發(fā)超時頻率不高大概每天幾次。這種偶發(fā)問題最折磨人日志里偶爾看到超時但不知道卡在哪個環(huán)節(jié)。我先用 watch 看接口入?yún)l(fā)現(xiàn)超時請求和正常請求的參數(shù)沒有明顯區(qū)別于是改用 trace 觀察調(diào)用鏈路。第一次 trace 還沒有抓到超時等了差不多十幾分鐘才有一次超時出現(xiàn)。這次 trace 輸出里接口方法總耗時接近 3 秒其中一個下游 RPC 調(diào)用的子節(jié)點耗時占 2.5 秒其他子節(jié)點都只有幾十毫秒。順著這個異步下游繼續(xù)往下定位最后發(fā)現(xiàn)是某個配置中心客戶端的刷新邏輯在特定時刻阻塞導致請求串行等待。這個例子想說明一個關(guān)鍵點很多偶發(fā)問題根本不體現(xiàn)在業(yè)務(wù)日志里因為業(yè)務(wù)代碼里沒有打印每一次下游調(diào)用的耗時明細。Arthas 的運行時觀察能力等于給線上系統(tǒng)裝了一臺顯微鏡它能把正常日志看不到的細節(jié)全部拉到眼前。3.3 場景三驗證修復方案不用發(fā)布就能試還有一種很常見的用法不是緊急救火而是驗證方案。曾經(jīng)有一個灰度問題我們懷疑是某個枚舉映射導致數(shù)據(jù)錯亂但不敢完全確定。改代碼發(fā)布會話成本高而且如果改完還是錯的等于白折騰。我先用 jad 反編譯出線上實際運行的類確認枚舉字段順序和本地代碼不一致這是一個非常關(guān)鍵的信息。因為本地代碼經(jīng)過多次迭代線上的 class 可能已經(jīng)和 git 分支對不上。確認問題后我在本地改好用 mc 和 redefine 熱更新到灰度進程再跑一次請求問題復現(xiàn)時已經(jīng)不出現(xiàn)了這才放心走正式發(fā)布流程。很多人擔心熱更新有副作用。我的經(jīng)驗是先在測試環(huán)境或灰度環(huán)境做驗證確認無誤后再對生產(chǎn)操作操作完成之后立刻用 watch 或重新發(fā)一次請求確認行為符合預期。熱更新在 JVM 層是支持的但生產(chǎn)環(huán)境的變更仍要符合團隊變更流程最好有同事在場一起確認至少留一條操作記錄。4. 常見問題與排查技巧實錄4.1 attach 不上目標進程怎么辦我遇到最多的問題是 attach 失敗報錯或者列不出進程。這里有一個速查表基本覆蓋我遇到過的原因常見原因現(xiàn)象處理建議用戶權(quán)限不一致attach 時報錯或無權(quán)限切換成目標進程同一用戶啟動/tmp 空間滿了attach 后立刻異常退出清理 /tmp 下臨時文件目標進程已退出進程列表里找不到用 jps 確認進程狀態(tài)端口被占用telnet 連接失敗指定新端口啟動Linux 下 attach 有權(quán)限限制最好用和目標進程相同的用戶操作。Arthas attach 時會在 /tmp 寫臨時文件空間不足會導致各種奇怪問題。如果還是不行可以在啟動 arthas-boot.jar 時帶上--telnet-port和--http-port參數(shù)換兩個沒被占用的端口很多端口沖突的問題就解決了。4.2 對線上服務(wù)的影響到底有多大這是每個初次接觸的人都會問的問題。字節(jié)碼增強確實會帶來一些性能開銷但實際影響通常很小。我的實測經(jīng)驗是在常規(guī)業(yè)務(wù)方法上開啟 watch 或 trace單次調(diào)用的額外開銷在幾毫秒以內(nèi)對整個請求來說幾乎感知不到。但如果是對超級熱點方法開 trace比如某個每秒調(diào)用上萬次的基礎(chǔ)工具方法開銷就會放大。這種基礎(chǔ)方法被所有上層業(yè)務(wù)調(diào)用攔截和記錄的成本會被放大到不可忽略。我的建議是精準選擇目標方法不要對整個包路徑做通配觀察觀察期間留意 dashboard 的 CPU 變化如果發(fā)現(xiàn)明顯升高立刻縮小范圍或者停掉觀察命令。4.3 權(quán)限控制不能忽視Arthas 很強強到可以隨時查看進程內(nèi)數(shù)據(jù)、修改運行中的代碼所以它也是一把雙刃劍。在團隊里使用至少要做到三件事控制在指定的運維和開發(fā)人員范圍內(nèi)使用不要全員開放服務(wù)器權(quán)限生產(chǎn)環(huán)境使用前提前申請臨時權(quán)限并記錄操作原因操作完成后及時退出交互終端不要長期掛著會話。有些團隊會把 Arthas 封裝成內(nèi)部平臺通過 Web 界面暴露受限接口避免開發(fā)人員直接登錄服務(wù)器亂敲命令。我比較認可這種思路能力強大和可控并不矛盾。安全這塊做到位工具才能長期用下去。4.4 部分命令在生產(chǎn)環(huán)境不可用跟具體 JDK 版本相關(guān)的問題也值得關(guān)注。某些 JDK 版本下 jad 反編譯可能不完美尤其是涉及 Lambda 表達式或者動態(tài)代理生成的類時反編譯結(jié)果會讓人看得很困惑。redefine 的限制更多對新增成員變量、改變方法簽名這類結(jié)構(gòu)性變更通常不支持強行操作會報錯。遇到這種情況不要死磕熱更新。先用 watch 拿到足夠信息確認根因后該走發(fā)布流程就走發(fā)布流程。工具的作用是幫你看清現(xiàn)場而不是替代正常的變更管理。5. 使用經(jīng)驗和技巧分享5.1 條件表達式讓 watch 不再刷屏watch 默認打印所有請求在流量大的接口下輸出會刷得飛快關(guān)鍵是里面有價值的請求可能只占很小比例。用條件表達式可以做到精準觀察比如只看某類訂單創(chuàng)建失敗的請求watch com.example.order.OrderServiceImpl createOrder {params[0], returnObj} params[0].orderType 2 returnObj.success false條件表達式寫在命令最后返回布爾值滿足條件才觸發(fā)打印。這個技巧能讓你在繁忙環(huán)境下直接鎖定目標請求不用從大量日志輸出里去撈。5.2 ognl 命令主動觸發(fā)靜態(tài)方法調(diào)用有些時候你不僅想看還想主動觸發(fā)某個方法比如清理某個靜態(tài)緩存、查看某個配置項。Arthas 提供 ognl 命令可以不寫代碼直接執(zhí)行靜態(tài)方法調(diào)用ognl com.example.config.CacheManagerclear()這種操作在應(yīng)急時很有效但風險也高它相當于直接往 JVM 里執(zhí)行代碼。我建的建議是先把命令在測試環(huán)境驗證一次再上生產(chǎn)并且必須明確這個調(diào)用會影響什么、會不會有并發(fā)問題。5.3 腳本批量采集線程現(xiàn)場遇到周期性出現(xiàn)的問題比如每小時整點偶發(fā)一次卡頓單次執(zhí)行 thread 不一定能抓到現(xiàn)場?？梢杂靡粭l簡單的 shell 循環(huán)把 Arthas 的批處理模式用起來while true; do echo --- $(date) --- thread_dump.log java -jar arthas-boot.jar PID -c thread -n 5 -i 1000 thread_dump.log 21 sleep 5 done這里用到了-c參數(shù)可以讓 Arthas 執(zhí)行一條命令后自動退出非常適合在腳本里批量使用。-i 1000是采樣間隔單位是毫秒。把多次采集到的線程快照放在一起對比周期性問題的觸發(fā)特征就很容易暴露出來。5.4 工具是幫手不是萬能藥最后說一點個人觀察。Arthas 確實香但解決的是“運行態(tài)信息不可見”的問題很多線上故障的根因其實是代碼邏輯、容量規(guī)劃或者架構(gòu)設(shè)計。工具能幫你更快定位問題但定位完之后該重構(gòu)要重構(gòu)、該擴容要擴容不能把熱更新當成常態(tài)化修復方式。我現(xiàn)在的習慣是復雜問題先用 Arthas 快速觀察現(xiàn)場拿到關(guān)鍵證據(jù)后把結(jié)論和操作記錄整理到運維工單然后走穩(wěn)定的修復流程。工具負責把定位時間從小時降到分鐘剩下的工程質(zhì)量問題還是要靠扎實的代碼和可靠的變更流程解決。前后踩過幾次坑之后我對 Arthas 的態(tài)度已經(jīng)從“要不要學”變成了“怎么用得更穩(wěn)”。如果你也被線上問題復現(xiàn)難、定位慢困擾別猶豫找個低峰期在測試環(huán)境把 watch、trace、thread 這幾個基礎(chǔ)命令練熟真到救火那一刻你會感謝這個“真香”工具。 Arthas實戰(zhàn)：Java線上問題排查利器，無需重啟即可診斷JVM
真香定律放在技術(shù)圈一樣適用。以前總覺得線上排查問題靠日志、靠監(jiān)控、靠人肉加日志就夠用了直到真正把 Arthas 用起來才發(fā)現(xiàn)以前那些操作有多繞。Arthas 是一個開源的 Java 診斷工具不用改代碼、不用重啟服務(wù)可以直接 attach 到正在運行的 JVM 進程上實時查看類加載情況、方法出入?yún)ⅰ⒄{(diào)用棧、線程狀態(tài)、JVM 指標還能反編譯和在線熱更新。它專門解決一類問題線上偶發(fā)、日志不全、無法本地復現(xiàn)、一重啟現(xiàn)場就沒了。無論你是后端開發(fā)、維護過老項目還是正在被“線上 bug 怎么都復現(xiàn)不了”折磨這篇文章都值得花十分鐘讀完。1. 為什么說它是排查線上問題的“真香”工具1.1 傳統(tǒng)排查方式的三座大山先聊聊大家最熟悉的排查流程。遇到線上故障第一反應(yīng)通常是翻日志。但日志工具抄出來的往往是“結(jié)果”不是“過程”很多關(guān)鍵參數(shù)、臨時變量、調(diào)用時序根本不存在。如果日志里什么都有那問題可能早就被監(jiān)控平臺發(fā)現(xiàn)了現(xiàn)實往往是日志不夠、不夠細、沒有參數(shù)上下文。接著你會想本地復現(xiàn)把線上數(shù)據(jù)導出來構(gòu)造請求打一遍結(jié)果發(fā)現(xiàn)本地怎么都復現(xiàn)不出來。因為并發(fā)量、緩存狀態(tài)、時鐘順序、臟數(shù)據(jù)都可能影響最終結(jié)果本地環(huán)境永遠只是線上環(huán)境的一種近似。最后一招是加日志重啟改一行 log.info編譯打包發(fā)版等流量進入再看日志這中間耗時少說半小時多則幾個小時而且頻繁重啟會讓現(xiàn)場被破壞流量重放也未必能還原問題。這三座大山我相信每個后端都經(jīng)歷過。Arthas 恰好能繞開它們不需要提前埋點因為它能在運行時直接查看真實出入?yún)⒉恍枰磸桶l(fā)布因為它直接操作當前進程不需要靠猜因為它能把調(diào)用路徑和方法執(zhí)行細節(jié)攤開給你看。用過一次之后你會真心覺得“真香”。1.2 原理attach 與字節(jié)碼增強要理解 Arthas 為什么能做到這些得先知道它的原理基礎(chǔ)。Arthas 本質(zhì)上利用了 Java 的 attach 機制和字節(jié)碼增強技術(shù)。attach 是 JDK 提供的一種能力允許一個 JVM 進程運行時連接另一個 JVM 進程并通過 Agent 方式執(zhí)行操作。字節(jié)碼增強則是在類加載或運行時對已經(jīng)加載的類做動態(tài)修改在方法執(zhí)行前后插入攔截邏輯相當于給方法裝上一套“臨時探針”。這套探針是臨時的JVM 一重啟就沒了不會影響原有邏輯。原理本身在 Java 生態(tài)里不算多新鮮但真正難的是把這一套能力封裝得好用做成命令行交互式的產(chǎn)品。Arthas 做到的正是這一點從啟動到使用幾乎不需要在應(yīng)用代碼里增加任何依賴這對排查場景來說是極大的優(yōu)勢。1.3 什么時候該想到用它很多人問什么場景下 Arthas 才是剛需。我的判斷標準很簡單只要你遇到“日志看不出來、重啟代價高、需要確認運行期狀態(tài)”這三個條件中的兩個就該考慮它。典型場景包括接口耗時突然變長、CPU 飆升、線程池被打滿、緩存數(shù)據(jù)異常、灰度環(huán)境某個請求表現(xiàn)不一致、老項目沒有源碼無法重新編譯。這里有一個容易被忽略的點Arthas 不是只給“救火”用的。在正常的壓測、聯(lián)調(diào)、性能分析階段也可以主動用它。我經(jīng)常在壓測時開著 dashboard一邊加壓一邊觀察線程池大小、GC 頻率和熱點方法比事后看測試報告直觀得多。因為它不是從統(tǒng)計數(shù)據(jù)里做推測而是直接從運行中的 JVM 里拿事實。1.4 為什么團隊應(yīng)該統(tǒng)一學習Arthas 這類工具個人會用和團隊都會用的效果差別很大。一個人掌握遇到問題只能是他上團隊都掌握任何值班的人都能快速定位初級問題不用每次都把核心開發(fā)叫起來看服務(wù)器。我見過不少團隊把 Arthas 列為后端必修技能要求每個人至少掌握 dashboard、thread、watch、trace 四個命令的基本用法我覺得是非常務(wù)實的做法。2. 上手必須先掌握的 6 個高頻命令命令速查表先放在前面后面會逐個細講命令用途典型場景dashboard全局面板CPU、內(nèi)存、GC、線程狀態(tài)一眼看全watch觀察方法出入?yún)⒋_認參數(shù)是否正常、異常在哪拋出trace方法調(diào)用鏈耗時定位慢請求卡在哪個子調(diào)用thread線程分析CPU飆高、死鎖、線程阻塞jad反編譯看線上實際運行的代碼mc redefine熱更新緊急修復后臨時止損2.1 啟動與選擇進程java -jar arthas-boot.jarArthas 的使用路徑非常直接。第一步下載 arthas-boot.jar放到服務(wù)器某個目錄下執(zhí)行java -jar arthas-boot.jar啟動后它會自動列出當前機器上所有 Java 進程輸入序號就能 attach。如果想跳過交互直接選進程可以在后面直接加 PIDjava -jar arthas-boot.jar 1234512345 是目標進程的進程號。剛上手時我建議大家執(zhí)行 help 看看當前版本支持的命令列表因為不同版本之間命令細節(jié)會有差異老是照著老資料敲容易踩坑。有一個小細節(jié)Arthas 本身運行需要 JDK但需要 attach 的目標進程不一定要用 JDK 啟動部分 JRE 環(huán)境也可以兼容。不過實際部署中建議用和運行環(huán)境同一版本的 JDK 去啟動 Arthas 客戶端減少無謂的兼容性問題。attach 成功后會進入交互終端提示符變成$所有命令都在這里輸入。2.2 dashboard 一眼看全局attach 成功后的第一個建議命令是 dashboard。它會實時刷新一個面板展示 CPU 占用率、內(nèi)存使用、GC 次數(shù)、線程狀態(tài)分布、每個線程的 CPU 消耗等信息。這等于給 JVM 裝了一個實時監(jiān)控屏幕打開它就能快速判斷問題在哪一層是 CPU 整體打滿還是內(nèi)存上漲觸發(fā)頻繁 GC還是某個線程卡死。初次使用的人容易被大量指標淹沒我一般只看四樣東西最上面的 CPU 使用率、內(nèi)存區(qū)域變化、GC 頻率、線程狀態(tài)里 BLOCKED 和 WAITING 的數(shù)量。如果 GC 頻率異常優(yōu)先排查堆內(nèi)存和對象分配如果有大量 BLOCKED 線程優(yōu)先找鎖競爭。面板是持續(xù)刷新的按 q 可以退出回到交互終端。2.3 watch 查看入?yún)?、返回值和異常watch 是線上排查使用頻率最高的命令沒有之一。它的作用是對指定方法觀察當方法被調(diào)用時打印出入?yún)ⅰ⒎祷刂祷蛘弋惓Ｐ畔?。watch com.example.order.OrderServiceImpl createOrder {params, returnObj, throwExp} -x 2這條命令的意思是觀察 OrderServiceImpl 類的 createOrder 方法當它執(zhí)行時打印入?yún)?、返回值和異常對象嵌套展開深度 2 層。這里用了 OGNL 表達式用單引號包裹內(nèi)置變量包括 params 數(shù)組、returnObj 和 throwExp。我第一次用 watch 排查問題時整個人的感覺就是開了天眼。以前要加日志重新發(fā)版才能看到的參數(shù)現(xiàn)在直接在當前進程里實時看到而且可以臨時加條件只觀察特定用戶或特定業(yè)務(wù)類型watch com.example.order.OrderServiceImpl createOrder {params[0]} params[0].userId 10086 -x 3條件表達式寫最后返回布爾值只有滿足條件才打印。這樣在流量大的接口下看不會被無關(guān)請求刷屏。2.4 trace 定位方法耗時分布如果說 watch 解決的是“參數(shù)對不對”trace 解決的就是“時間花在哪”。它會輸出指定方法的調(diào)用鏈路上每個子方法的耗時自動計算總耗時和每個節(jié)點耗時執(zhí)行效果類似一棵調(diào)用樹trace com.example.order.OrderServiceImpl createOrder命令執(zhí)行后目標方法一旦被調(diào)用你會看到類似下面的輸出---createOrder() # 總耗時 823ms ---checkStock() # 56ms ---deductBalance() # 720ms ---sendMessage() # 47ms順著耗時最大的節(jié)點繼續(xù)往下 trace逐層鉆取就能鎖定真正慢的底層方法。這個過程就像剝洋蔥把慢請求一層層拆到最小執(zhí)行單元。有一點要提醒trace 是通過字節(jié)碼增強實現(xiàn)的它只增強執(zhí)行命令之后發(fā)生的調(diào)用歷史調(diào)用不會回溯。所以想抓到想要的 trace 結(jié)果必須讓目標請求再進來一次。如果接口觸發(fā)頻率低可以配合定時任務(wù)或者手動打一個測試請求。2.5 thread比 jstack 更實用的線程分析很多同學排查線程問題只會 jstack但 jstack 一下輸出大量線程棧分不清哪個線程才是問題源頭。Arthas 的 thread 命令可以直接按 CPU 消耗排序這個能力非常實用thread -n 3它會打印出 CPU 占用最高的 3 個線程同時帶上對應(yīng)線程棧。對比 jstack 還得自己去數(shù)線程 ID、對應(yīng) 16 進制換算效率高了一個量級。它還能直接查死鎖thread -bFound one Java-level deadlock: thread-1: waiting to lock monitor ...thread -b會直接輸出檢測結(jié)果和相關(guān)線程棧不用再從 jstack 輸出里手工解析 Locked ownable synchronizers。如果需要看指定線程可以帶線程 ID 精確查看這個在分析阻塞場景時很管用。2.6 jad mc redefine 實現(xiàn)在線熱更新這一組命令要謹慎使用但在緊急情況下非常救命。jad 用于反編譯已加載的類可以看線上運行的真實代碼而不是本地倉庫里可能已經(jīng)過期的版本mc 是內(nèi)存編譯基于 jad 查看后的源碼在內(nèi)存里重新編譯redefine 是把編譯好的字節(jié)碼替換到運行中的 JVM 里。jad --source-only com.example.order.OrderServiceImpl /tmp/OrderServiceImpl.java mc /tmp/OrderServiceImpl.java -d /tmp redefine /tmp/com/example/order/OrderServiceImpl.class熱更新最典型的使用場景是線上有 bug 需要臨時改一行邏輯發(fā)布流程要走審批這時先用 Arthas 做臨時修復讓服務(wù)先恢復然后馬上走正規(guī)發(fā)布。要注意這個操作不會改磁盤上的 class 文件也不會寫回 jar 包服務(wù)一重啟就失效。而且不是所有代碼都能熱更新成功增加類、改變方法簽名的場景通常會失敗。3. 實戰(zhàn)從幾個真實故障看 Arthas 的實際用法3.1 場景一CPU 飆高快速定位到正則災難性回溯我先講一個最常見的 CPU 100% 問題。某服務(wù)在活動流量上來后CPU 使用率持續(xù)接近滿核業(yè)務(wù)方反饋接口響應(yīng)很慢。按老辦法先看 top 找到進程 PID然后 jstack 導出線程棧再做 16 進制轉(zhuǎn)換找到對應(yīng)線程整個過程相當繁瑣。用 Arthas 的流程會快很多。attach 之后先執(zhí)行 dashboard整體看一眼 CPU 和線程狀態(tài)當時很明顯看到幾個線程占用 CPU 非常夸張。然后執(zhí)行thread -n 5它直接給出了 CPU 最高的 5 個線程及其調(diào)用棧。我看到一個線程棧反復停在同一個業(yè)務(wù)方法里跟進 trace 這個方法發(fā)現(xiàn)內(nèi)部有一段非常復雜的字符串正則匹配在特定輸入下觸發(fā)災難性回溯CPU 全部耗在了正則引擎內(nèi)部。定位過程前后不到五分鐘全程沒有重啟服務(wù)。定位到原因之后我用 jad 反編譯出當前代碼把正則邏輯臨時替換成樸素的字符串前綴匹配通過 mc 和 redefine 熱更新到線上進程服務(wù)立刻恢復。這個案例給我的最大感觸是CPU 飆高和接口慢本質(zhì)上都是“定位問題”的效率問題。只要能看到線程在干什么排查時間就能從小時級縮短到分鐘級。3.2 場景二接口偶發(fā)超時trace 逐層揪出隱藏阻塞另一個案例是某接口偶發(fā)超時頻率不高大概每天幾次。這種偶發(fā)問題最折磨人日志里偶爾看到超時但不知道卡在哪個環(huán)節(jié)。我先用 watch 看接口入?yún)l(fā)現(xiàn)超時請求和正常請求的參數(shù)沒有明顯區(qū)別于是改用 trace 觀察調(diào)用鏈路。第一次 trace 還沒有抓到超時等了差不多十幾分鐘才有一次超時出現(xiàn)。這次 trace 輸出里接口方法總耗時接近 3 秒其中一個下游 RPC 調(diào)用的子節(jié)點耗時占 2.5 秒其他子節(jié)點都只有幾十毫秒。順著這個異步下游繼續(xù)往下定位最后發(fā)現(xiàn)是某個配置中心客戶端的刷新邏輯在特定時刻阻塞導致請求串行等待。這個例子想說明一個關(guān)鍵點很多偶發(fā)問題根本不體現(xiàn)在業(yè)務(wù)日志里因為業(yè)務(wù)代碼里沒有打印每一次下游調(diào)用的耗時明細。Arthas 的運行時觀察能力等于給線上系統(tǒng)裝了一臺顯微鏡它能把正常日志看不到的細節(jié)全部拉到眼前。3.3 場景三驗證修復方案不用發(fā)布就能試還有一種很常見的用法不是緊急救火而是驗證方案。曾經(jīng)有一個灰度問題我們懷疑是某個枚舉映射導致數(shù)據(jù)錯亂但不敢完全確定。改代碼發(fā)布會話成本高而且如果改完還是錯的等于白折騰。我先用 jad 反編譯出線上實際運行的類確認枚舉字段順序和本地代碼不一致這是一個非常關(guān)鍵的信息。因為本地代碼經(jīng)過多次迭代線上的 class 可能已經(jīng)和 git 分支對不上。確認問題后我在本地改好用 mc 和 redefine 熱更新到灰度進程再跑一次請求問題復現(xiàn)時已經(jīng)不出現(xiàn)了這才放心走正式發(fā)布流程。很多人擔心熱更新有副作用。我的經(jīng)驗是先在測試環(huán)境或灰度環(huán)境做驗證確認無誤后再對生產(chǎn)操作操作完成之后立刻用 watch 或重新發(fā)一次請求確認行為符合預期。熱更新在 JVM 層是支持的但生產(chǎn)環(huán)境的變更仍要符合團隊變更流程最好有同事在場一起確認至少留一條操作記錄。4. 常見問題與排查技巧實錄4.1 attach 不上目標進程怎么辦我遇到最多的問題是 attach 失敗報錯或者列不出進程。這里有一個速查表基本覆蓋我遇到過的原因常見原因現(xiàn)象處理建議用戶權(quán)限不一致attach 時報錯或無權(quán)限切換成目標進程同一用戶啟動/tmp 空間滿了attach 后立刻異常退出清理 /tmp 下臨時文件目標進程已退出進程列表里找不到用 jps 確認進程狀態(tài)端口被占用telnet 連接失敗指定新端口啟動Linux 下 attach 有權(quán)限限制最好用和目標進程相同的用戶操作。Arthas attach 時會在 /tmp 寫臨時文件空間不足會導致各種奇怪問題。如果還是不行可以在啟動 arthas-boot.jar 時帶上--telnet-port和--http-port參數(shù)換兩個沒被占用的端口很多端口沖突的問題就解決了。4.2 對線上服務(wù)的影響到底有多大這是每個初次接觸的人都會問的問題。字節(jié)碼增強確實會帶來一些性能開銷但實際影響通常很小。我的實測經(jīng)驗是在常規(guī)業(yè)務(wù)方法上開啟 watch 或 trace單次調(diào)用的額外開銷在幾毫秒以內(nèi)對整個請求來說幾乎感知不到。但如果是對超級熱點方法開 trace比如某個每秒調(diào)用上萬次的基礎(chǔ)工具方法開銷就會放大。這種基礎(chǔ)方法被所有上層業(yè)務(wù)調(diào)用攔截和記錄的成本會被放大到不可忽略。我的建議是精準選擇目標方法不要對整個包路徑做通配觀察觀察期間留意 dashboard 的 CPU 變化如果發(fā)現(xiàn)明顯升高立刻縮小范圍或者停掉觀察命令。4.3 權(quán)限控制不能忽視Arthas 很強強到可以隨時查看進程內(nèi)數(shù)據(jù)、修改運行中的代碼所以它也是一把雙刃劍。在團隊里使用至少要做到三件事控制在指定的運維和開發(fā)人員范圍內(nèi)使用不要全員開放服務(wù)器權(quán)限生產(chǎn)環(huán)境使用前提前申請臨時權(quán)限并記錄操作原因操作完成后及時退出交互終端不要長期掛著會話。有些團隊會把 Arthas 封裝成內(nèi)部平臺通過 Web 界面暴露受限接口避免開發(fā)人員直接登錄服務(wù)器亂敲命令。我比較認可這種思路能力強大和可控并不矛盾。安全這塊做到位工具才能長期用下去。4.4 部分命令在生產(chǎn)環(huán)境不可用跟具體 JDK 版本相關(guān)的問題也值得關(guān)注。某些 JDK 版本下 jad 反編譯可能不完美尤其是涉及 Lambda 表達式或者動態(tài)代理生成的類時反編譯結(jié)果會讓人看得很困惑。redefine 的限制更多對新增成員變量、改變方法簽名這類結(jié)構(gòu)性變更通常不支持強行操作會報錯。遇到這種情況不要死磕熱更新。先用 watch 拿到足夠信息確認根因后該走發(fā)布流程就走發(fā)布流程。工具的作用是幫你看清現(xiàn)場而不是替代正常的變更管理。5. 使用經(jīng)驗和技巧分享5.1 條件表達式讓 watch 不再刷屏watch 默認打印所有請求在流量大的接口下輸出會刷得飛快關(guān)鍵是里面有價值的請求可能只占很小比例。用條件表達式可以做到精準觀察比如只看某類訂單創(chuàng)建失敗的請求watch com.example.order.OrderServiceImpl createOrder {params[0], returnObj} params[0].orderType 2 returnObj.success false條件表達式寫在命令最后返回布爾值滿足條件才觸發(fā)打印。這個技巧能讓你在繁忙環(huán)境下直接鎖定目標請求不用從大量日志輸出里去撈。5.2 ognl 命令主動觸發(fā)靜態(tài)方法調(diào)用有些時候你不僅想看還想主動觸發(fā)某個方法比如清理某個靜態(tài)緩存、查看某個配置項。Arthas 提供 ognl 命令可以不寫代碼直接執(zhí)行靜態(tài)方法調(diào)用ognl com.example.config.CacheManagerclear()這種操作在應(yīng)急時很有效但風險也高它相當于直接往 JVM 里執(zhí)行代碼。我建的建議是先把命令在測試環(huán)境驗證一次再上生產(chǎn)并且必須明確這個調(diào)用會影響什么、會不會有并發(fā)問題。5.3 腳本批量采集線程現(xiàn)場遇到周期性出現(xiàn)的問題比如每小時整點偶發(fā)一次卡頓單次執(zhí)行 thread 不一定能抓到現(xiàn)場?？梢杂靡粭l簡單的 shell 循環(huán)把 Arthas 的批處理模式用起來while true; do echo --- $(date) --- thread_dump.log java -jar arthas-boot.jar PID -c thread -n 5 -i 1000 thread_dump.log 21 sleep 5 done這里用到了-c參數(shù)可以讓 Arthas 執(zhí)行一條命令后自動退出非常適合在腳本里批量使用。-i 1000是采樣間隔單位是毫秒。把多次采集到的線程快照放在一起對比周期性問題的觸發(fā)特征就很容易暴露出來。5.4 工具是幫手不是萬能藥最后說一點個人觀察。Arthas 確實香但解決的是“運行態(tài)信息不可見”的問題很多線上故障的根因其實是代碼邏輯、容量規(guī)劃或者架構(gòu)設(shè)計。工具能幫你更快定位問題但定位完之后該重構(gòu)要重構(gòu)、該擴容要擴容不能把熱更新當成常態(tài)化修復方式。我現(xiàn)在的習慣是復雜問題先用 Arthas 快速觀察現(xiàn)場拿到關(guān)鍵證據(jù)后把結(jié)論和操作記錄整理到運維工單然后走穩(wěn)定的修復流程。工具負責把定位時間從小時降到分鐘剩下的工程質(zhì)量問題還是要靠扎實的代碼和可靠的變更流程解決。前后踩過幾次坑之后我對 Arthas 的態(tài)度已經(jīng)從“要不要學”變成了“怎么用得更穩(wěn)”。如果你也被線上問題復現(xiàn)難、定位慢困擾別猶豫找個低峰期在測試環(huán)境把 watch、trace、thread 這幾個基礎(chǔ)命令練熟真到救火那一刻你會感謝這個“真香”工具。