Arthas是阿里開源的 Java 診斷工具,相比 JDK 內置的診斷工具,要更人性化,并且功能強大,可以實現許多問題的一鍵定位,而且可以一鍵反編譯類查看源碼,甚至是直接進行生產代碼熱修復,實現在一個工具內快速定位和修復問題的一站式服務。
今天,我就帶你使用 Arthas 定位一個 CPU 使用高的問題,系統學習下這個工具的使用。
首先,下載并啟動 Arthas:
curl -O https://alibaba.github.io/arthas/arthas-boot.jarjava -jar arthas-boot.jar
啟動后,直接找到我們要排查的 JVM 進程,然后可以看到 Arthas 附加進程成功:
[INFO] arthas-boot version: 3.1.7[INFO] Found existing java process, please choose one and hit RETURN.* [1]: 12707 [2]: 30724 org.jetbrains.jps.cmdline.Launcher [3]: 30725 org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication [4]: 24312 sun.tools.jconsole.JConsole [5]: 26328 org.jetbrains.jps.cmdline.Launcher [6]: 24106 orgbeans.lib.profiler.server.ProfilerServer3[INFO] arthas home: /Users/zhuye/.arthas/lib/3.1.7/arthas[INFO] Try to attach process 30725[INFO] Attach process 30725 success.[INFO] arthas-client connect 127.0.0.1 3658 ,---. ,------. ,--------.,--. ,--. ,---. ,---. / O / | .--. ''--. .--'| '--' | / O / ' .-'| .-. || '--'.' | | | .--. || .-. |`. `-.| | | || |/ / | | | | | || | | |.-' |`--' `--'`--' '--' `--' `--' `--'`--' `--'`-----'wiki https://alibaba.github.io/arthastutorials https://alibaba.github.io/arthas/arthas-tutorialsversion 3.1.7pid 30725time 2020-01-30 15:48:33
輸出 help 命令,可以看到所有支持的命令列表。今天,我們會用到 dashboard、thread、jad、watch、ognl 命令,來定位這個 HighCPUApplication 進程。你可以通過官方文檔:https://arthas.aliyun.com/doc/commands.html,查看這些命令的完整介紹:
圖片
dashboard 命令用于整體展示進程所有線程、內存、GC 等情況,其輸出如下:
圖片
可以看到,CPU 高并不是 GC 引起的,占用 CPU 較多的線程有 8 個,其中 7 個是 ForkJoinPool.commonPool。
ForkJoinPool.commonPool 是并行流默認使用的線程池。
所以,此次 CPU 高的問題,應該出現在某段并行流的代碼上。
接下來,要查看最繁忙的線程在執行的線程棧,可以使用 thread -n 命令。這里,我們查看下最忙的 8 個線程:
thread -n 8
輸出如下:
圖片
可以看到,由于這些線程都在處理 MD5 的操作,所以占用了大量 CPU 資源。我們希望分析出代碼中哪些邏輯可能會執行這個操作,所以需要從方法棧上找出我們自己寫的類,并重點關注。
由于主線程也參與了 ForkJoinPool 的任務處理,因此我們可以通過主線程的??吹叫枰攸c關注 org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication 類的 doTask 方法。
接下來,使用 jad 命令直接對 HighCPUApplication 類反編譯:
jad org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication
可以看到,調用路徑是 main->task()->doTask(),當 doTask 方法接收到的 int 參數等于某個常量的時候,會進行 1 萬次的 MD5 操作,這就是耗費 CPU 的來源。那么,這個魔法值到底是多少呢?
圖片
你可能想到了,通過 jad 命令繼續查看 User 類即可。這里因為是 Demo,所以我沒有給出很復雜的邏輯。在業務邏輯很復雜的代碼中,判斷邏輯不可能這么直白,我們可能還需要分析出 doTask 的“慢”會慢在什么入參上。
這時,我們可以使用 watch 命令來觀察方法入參。如下命令,表示需要監控耗時超過 100 毫秒的 doTask 方法的入參,并且輸出入參,展開 2 層入參參數:
watch org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.HighCPUApplication doTask '{params}' '#cost>100' -x 2
可以看到,所有耗時較久的 doTask 方法的入參都是 0,意味著 User.ADMN_ID 常量應該是 0。
圖片
最后,我們使用 ognl 命令來運行一個表達式,直接查詢 User 類的 ADMIN_ID 靜態字段來驗證是不是這樣,得到的結果果然是 0:
[arthas@31126]$ ognl '@org.geekbang.time.commonmistakes.troubleshootingtools.highcpu.User@ADMIN_ID'@Integer[0]
需要額外說明的是,由于 monitor、trace、watch 等命令是通過字節碼增強技術來實現的,會在指定類的方法中插入一些切面來實現數據統計和觀測,因此診斷結束要執行 shutdown 來還原類或方法字節碼,然后退出 Arthas。
在這個案例中,我們通過 Arthas 工具排查了高 CPU 的問題:
可見,使用 Arthas 來定位生產問題根本用不著原始代碼,也用不著通過增加日志來幫助我們分析入參,一個工具即可完成定位問題、分析問題的全套流程。
對于應用故障分析,除了阿里 Arthas 之外,還可以關注去哪兒的Bistoury :https://github.com/qunarcorp/bistoury工具,其提供了可視化界面,并且可以針對多臺機器進行管理,甚至提供了在線斷點調試等功能,模擬 IDE 的調試體驗。
本文鏈接:http://www.tebozhan.com/showinfo-26-15212-0.html實戰!使用阿里 Arthas 工具分析 CPU 飆高
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 嵌入式框架設計中的四種常用模式