簡明的 Arthas 入門教程
Arthas是一款強大的開源Java診斷程序，它可以非常方便的啟動并以界面式的方式和Java程序進行交互,支持監控程序的內存使用情況、線程信息、gc情況、甚至可以反編譯并修改現上代碼等。
如下圖，arthas的運行原理大致是以下幾個步驟:
- 啟動arthas選擇目標Java程序后，artahs會向目標程序注入一個代理。
- 代理會創建一個集HTTP和Telnet的服務器與客戶端建立連接。
- 客戶端與服務端建立連接。
- 后續客戶端需要監控或者調整程序都可以通過服務端Java Instrumentation機制和應用程序產生交互。
為了讓讀者可以快速了并熟練掌握Arhtas的基本使用，筆者就以幾個比較常見的例子來演示一下Arthas的日常使用的常規套路。
詳解Arthas配置與使用
快速開始
在介紹幾個典型的案例之前，我們需要先下載一下Arthas，并了解Arthas的一些簡單的使用方式(注意:筆者為了方便演示所用的環境都是基于win 10，對于Linux環境而言操作也差不多)，Arthas的官方地址如下:
https://arthas.aliyun.com/
考慮到方便筆者一般是使用命令行的方式下載:
curl -O https://arthas.aliyun.com/arthas-boot.jar完成后我們通過下面這個命令就可以將Arthas啟動了。
java -jar arthas-boot.jar可以看到剛剛進入界面時，Arthas就會分別為每個服務器中正在運行的Java程序標上序號，我們只需輸入對應序號并點擊回車即可進行對目標程序的監控，為了演示筆者任意選擇一個2，并點擊回車。
隨后我們就進入的交互界面，如下圖:
Arthas最常用的監控指令就是dashboard，對于dashboard的使用說明，我們可以像使用Linux一下在dashboard命令后面追加一個--help。
如下圖所示，可以看出dashboard的用法大抵是這樣的:
- 默認參數都不加，每隔5s刷新一次面板。
- -i 指定刷新面板間隔。
- -n 指定刷新次數。
所以假如我們希望每10s刷新一次，重復執行3次的指令就是:
dashboard -i 10000 -n 3此時面板就會每隔10s刷新一次界面，監控界面如下圖所示，從圖中不難看出dashboard大抵范圍3個板塊:
- 線程信息版塊，對應的列名分別是:id、線程名、所屬線程組、優先級、線程運行狀態、cpu使用率、延遲時間、運行時間、是否被打斷。
- 內存使用版塊，大體都是記錄著各代內存和gc情況。
- 服務器運行參數版塊，這一版塊記錄著程序當前運行服務器的內核版本信息、jdk版本等。
在Arthas中，如果我們希望退出dashboard直接按ctrl+c即可，如果我們希望退出當前Java程序的交互界面，輸入exit即可。
定位CPU 100%問題
CPU 100%問題算是生產環境下最難排查的問題了，在沒有Arthas之前，我們常規的排查思路大致為:
- 使用top確定是否為java進程。
- 如果是，則使用jps定位Java進程號。
- 找到最吃資源的線程號。
- 將線程號轉為十六進制。
- 通過jstack導出日志并使用全局搜索十六進制線程號定位到問題代碼段。
如上所述，是不是很繁瑣呢？有了Arthas之后，問題的定位就會簡單快速許多，為了演示這個例子，筆者使用Spring Boot項目編寫了一段模擬CPU 100%問題的代碼段，可以看到筆者使用：
/**
* 一個線程數只有1的線程池
*/
private static ExecutorService threadPool = Executors.newCachedThreadPool();
@RequestMapping("cpu-100")
public static void cpu() {
loopThread();
cpuHigh();
}
/**
* 極度消耗CPU的線程
*/
private static void cpuHigh() {
// 添加到線程
threadPool.submit(() -> {
while (true) {
log.info("cpu working");
}
});
}
/**
* 無限循環的線程
*/
private static void loopThread() {
for (int i = 0; i < 10; i++) {
new Thread(() -> {
while (true) {
log.info("死循環線程工作中");
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}, "thread" + i).start();
}
}完成編寫后，我們將項目啟動并請求該地址，不久后你就會發現CPU直接飆升接近100%，此時我們的arthas就派上用場了，首先我們自然是將arthas啟動。
java -jar arthas-boot.jar此時控制臺會出現下面幾個選項，它通過不同序號標明不同的Java程序，我們看到我們的目標程序ArthasExampleApplication，序號為1，所以我們輸入1按回車。
F:\github>java -jar arthas-boot.jar
[INFO] JAVA_HOME: D:\myinstall\jdk8\jre8
[INFO] arthas-boot version: 3.6.9
[INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER.
* [1]: 18720 com.example.arthasExample.ArthasExampleApplication
[2]: 19300 org.jetbrains.jps.cmdline.Launcher
[3]: 7876 org.jetbrains.idea.maven.server.RemoteMavenServer
[4]: 14488進入控制臺，我們直接鍵入thread命令可以看到，有一個名為 pool-1-thread-1的線程CPU使用率非常高，所以我們需要定位它所工作的代碼段。
由控制臺可知，它的序號為59，所以我們直接鍵入:
thread 59很快的，我們直接定位到了問題代碼段，在TestController的42行。
知道了代碼的位置之后，我們根據類的包路徑com.example.arthasExample.TestController直接通過Arthas反編譯查看源碼，命令如下:
jad --source-only com.example.arthasExample.TestController最終我們定位到了問題代碼，即時修復即可。
定位線程死鎖問題
對于線程死鎖問題，我們也給出下面這樣一段示例代碼，線程1先取鎖1再取鎖2，線程2反之，兩者取鎖順序構成環路造成死鎖。
//兩把鎖
private Object lock1 = new Object();
private Object lock2 = new Object();
@RequestMapping("dead-lock")
public void deadLock() {
//線程1先取得鎖1，休眠后取鎖2
new Thread(() -> {
synchronized (lock1) {
try {
log.info("t1 successfully acquired the lock1......");
TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lock2) {
log.info("t1 successfully acquired the lock1......");
}
}
}, "t1").start();
//線程2先取得鎖2，休眠后取鎖1
new Thread(() -> {
synchronized (lock2) {
try {
log.info("t2 successfully acquired the lock2......");
TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lock1) {
log.info("t2 successfully acquired the lock1......");
}
}
}, "t2").start();
}了解代碼流程之后，我們直接調用這個接口，打開Arthas查看鍵入thread線程信息可以看到我們的t1和t2兩個線程處于等待狀態，大概率存在問題。
隨后我們直接鍵入thread -b，發現t2線程被鎖住了，由此斷定這兩個線程看定存在死鎖，
由上述結果我們可知兩個線程的id分別是65和66，所以使用thread id號的命令直接定位到問題代碼段并解決問題即可。
反編譯查看代碼
上文我們其實已經用到了jad這個反編譯命令，對于筆者來說，jad有兩種比較常見的用法，除了上述那種反編譯類的指令jad --source-only 類的包路徑，還有一種定位方法代碼段的命令jad --source-only 類的包路徑 方法名。
例如筆者想定位TestController的deadLock代碼，我們就可以鍵入:
jad --source-only com.example.arthasExample.TestController deadLock如下圖，我們可以直接看到的方法的代碼:
定位字段信息(不常用)
我們希望看到某個類下所有字段的詳情，我們就可以使用這條命令
sc -d -f 類的包路徑例如筆者想查看TestController的字段詳情，就可以鍵入這條命令
sc -d -f com.example.arthasExample.TestController可以看到這條指令不僅可以查看字段的定義和注解，還可以查看線程池的使用情況以及集合內部的value。
查看方法列表(不常用)
這條命令筆者不是很常用，為了教程的完整性筆者也演示一下，假如我們希望查看某個類的方法，可以使用:
sm 類的包路徑以筆者為例,查看TestController的方法為:
sm com.example.arthasExample.TestController輸出結果如下:
靜態變量監控(常用)
Arthas提供了對靜態變量的分析，以下面這段代碼為例，如果筆者希望看到list 內部詳情，我們就可以使用ognl。
private static List<String> list = new ArrayList<>();
@RequestMapping("add")
public void add() {
for (int i = 0; i < 10; i++) {
list.add("val" + i);
}
}在我們執行完接口完成添加操作之后，我們可以直接使用ognl進行監控。例如我們希望查看上述list的內容，我們就可以使用命令:
ognl '@類的包路徑@變量名'所以如果筆者查看list的命令為:
ognl '@com.example.arthasExample.TestController@list'輸出結果如下：
當然ognl還有一些比較特殊的用法，例如查看集合的長度，添加元素到集合中等操作，具體可以參考GitHub這個issue:
https://github.com/alibaba/arthas/issues/71
運行耗時性能問題排查
對于統計耗時的操作我們經常會用打日志的方式來監控，在環境復雜的生產環境，我們常因為欠缺考慮而忘記對某些方法進行監控。 同樣的Arthas也為我們提供了一些便捷的命令來完成對方法耗時的監控與統計:
筆者這里給出一段UserServiceImpl 模擬用戶查詢時進行參數校驗、其他service調用、redis調用、MySQL調用。
@Service
@Slf4j
public class UserServiceImpl {
public JSONObject queryUser(Integer uid) throws Exception {
check(uid);
service(uid);
redis(uid);
return mysql(uid);
}
public void service(Integer uid) throws Exception {
log.info("調用其他service。。。。。");
TimeUnit.SECONDS.sleep(RandomUtil.randomLong(1, 2));
}
public void redis(Integer uid) throws Exception {
log.info("查看redis緩存數據。。。。。");
TimeUnit.MILLISECONDS.sleep(RandomUtil.randomInt(100, 200));
}
public JSONObject mysql(Integer uid) throws Exception {
log.info("查詢MySQL數據......");
TimeUnit.SECONDS.sleep(RandomUtil.randomInt(3, 4));
JSONObject jsonObject = new JSONObject();
jsonObject.putOnce("name", "xiaoming");
jsonObject.putOnce("age", 18);
return jsonObject;
}
public boolean check(Integer uid) throws Exception {
if (uid == null || uid < 0) {
log.error("非法用戶id，uid:{}", uid);
throw new Exception("非法用戶id");
}
return true;
}
}對應的controller代碼如下，假如我們在生產環境下發現這個接口非常耗時，我們又沒有日志，那么我們如何利用Arthas排查耗時問題呢？
@Autowired
private UserServiceImpl userService;
@GetMapping(value = "/user")
public JSONObject queryUser(Integer uid) throws Exception {
return userService.queryUser(uid);
}我們可以用trace命令，我們首先用trace追蹤一下TestController 的queryUser耗時的調用:
trace com.example.arthasExample.TestController queryUser可以發現TestController 并無異常，所有的耗時都在UserServiceImpl：
所以我們再對UserServiceImpl 的queryUser進行追鐘。
trace com.example.arthasExample.UserServiceImpl queryUser完成命令鍵入后，控制臺就會阻塞監控這個方法，然后我們調用一下這個接口，可以發現原來是MySQL查詢非常耗時，由此我們就可以進一步去推斷問題了。
方法耗時統計
有時候我們希望監控某個方法單位時間內請求的耗時和調用情況，我們就可以使用monitor命令，例如我們希望每5s查看TestController 的queryUser的情況，我們就可以鍵入:
monitor -c 5 com.example.arthasExample.TestController queryUser可以看到控制臺會每5s輸入請求次數、成功和失敗次數以及平均耗時等信息。
定位出入參錯誤問題
有時候我們希望定位某個日志沒有打到的方法的出入參詳情，例如上面的mysql()的出入參，我們完全可以通過Arthas的watch方法做到，對應命令為:
watch com.example.arthasExample.UserServiceImpl mysql '{params[0],returnObj}'可以看到，我們的入參為1，出參是一個對象。
更進一步，假如我們希望可以打印出對象的內容，那么我們就可以使用toString方法做到：
watch com.example.arthasExample.UserServiceImpl mysql '{params[0],returnObj.toString()}'
除此之外watch 還支持很多的騷操作，具體可以參考官方文檔：https://arthas.aliyun.com/doc/watch.html
監控方法調用路徑
還是以上文mysql方法為例，如果我們希望快速定位到它的調用路徑，我們可以使用stack方法:
stack com.example.arthasExample.UserServiceImpl mysql可以看到詳細的調用路徑直接輸出到控制臺。
獲取方法調用的過程
我們希望查看方法調用時出現異常的原因，出參和入參時，可以使用tt這條指令,例如我們想查看check方法為何會報錯，我們就可以使用tt：
tt -t com.example.arthasExample.UserServiceImpl check從輸出結果來看，第二次拋出異常了，我們可以基于1001這個索引去定位問題。
tt -i 1001最終可以得出，入參為-1：
如果我們想重新發起調用，可以直接使用：
tt -i 1001 -poom問題
以下面這段代碼為例，筆者將堆內存改為100m，命令為-Xms100m -Xmx100m,啟動后直接重現oom問題：
final ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(100, 100, 1, TimeUnit.MINUTES,
new LinkedBlockingQueue<>());// 創建線程池，通過線程池，保證創建的線程存活
@RequestMapping(value = "/oom")
public String oom(HttpServletRequest request) {
poolExecutor.execute(() -> {
Byte[] c = new Byte[4* 1024* 1024];
localVariable.set(c);// 為線程添加變量
});
return "success";
}然后通過arthas發現老年代內存幾乎已滿，gc也十分頻繁。
由此我們可以直接使用Arthas的heapdump 導出文件到mat中進行進一步分析。
heapdump D://heap.hprof導出的結果如下，后續我們就可以點擊detail推斷到問題的源頭了。
最終我們很快速的定位到了問題代碼:
線上替換代碼
有時候我們測試難免會遺漏一些情況，如下所示，我們業務要求id小于1才拋出異常，但是我們因為粗心而將判斷條件寫成id<2，結果懵懵懂懂的就將這段代碼部到了生產環境，導致業務查詢出了問題。
@GetMapping(value={"/user/{id}"})
public JSONObject findUserById(@PathVariable Integer id) {
log.info("id: {}",id);
if (id != null && id < 2) {
throw new IllegalArgumentException("id < 1");
}
return new JSONObject().putOnce("name","user"+id).putOnce("age",18);
}對于生產環境，我們肯定是無法立刻重啟替換jar包的，對于這類問題，我們完全可以使用arthas實現在線熱更新。
首先第一步，我們將生產環境的字節碼反編譯并導出到本地，如下所示：
jad --source-only com.example.arthasExample.TestController > d://TestController.java然后我們修改一下對應的代碼段：
然后我們需要找到這個類對應類加載器的hash碼：
sc -d *TestController | grep classLoaderHash
找到對應hash碼之后，我們就可以基于這個類加載器將修改后的Java文件編譯成字節碼文件:
mc -c 18b4aac2 d://TestController.java -d d://最后我們將代碼熱更新到正在運行的程序：
redefine d://com/example/arthasExample/TestController.class此時我們傳1作為參數就不會報錯了，說明代碼熱更新成功了。
獲取spring上下文進行進一步分析操作
有時候我們希望在線上獲取Spring容器分析定位問題，我們完全可以通過arthas攔截到這個類并進行進一步調用和分析。
讀過Spring MVC源碼的讀者可能都知道，每當又HTTP請求發送到web容器時請求進行映射轉發處理時都會經過RequestMappingHandlerAdapter，從下面的類圖不難看出它繼承了WebApplicationObjectSupport，而該類有一個方法getWebApplicationContext可以讓我們獲取到spring容器的上下文，進而去分析管理spring容器。
所以我們可以使用arthas的tt指令追蹤這個類的調用：
tt -t org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter invokeHandlerMethod然后我們隨便調用一個接口，得到調用記錄：
我們就以索引為1000的調用記錄，通過-w指定ognl獲取到spring上下文并獲取到testController然后完成一個方法調用。
tt -i 1000 -w 'target.getApplicationContext().getBean("testController").findUserById(3)'如下圖，可以看到，我們成功的完成了調用并得到了返回結果。
小結
自此我們對Arthas的常見操作都已演示完成，更多關于Arthas的使用讀者可以參考Arthas官網，希望對你有幫助：https://arthas.aliyun.com/doc/
