簡明的 Arthas 使用教程
Arthas是一款強大的開源Java診斷程序，它可以非常方便的啟動并以界面式的方式和Java程序進行交互,支持監控程序的內存使用情況、線程信息、gc情況、甚至可以反編譯并修改現上代碼等。所以它成為筆者進行線上問題排查的重要手段，而本文將從實際使用的角度介紹一下arthas的基本使用技巧，希望對你有幫助。
一、常見的運維操作示例
1. 反編譯查看代碼
上文我們其實已經用到了jad這個反編譯命令，對于筆者來說，jad有兩種比較常見的用法，除了上述那種反編譯類的指令jad --source-only 類的包路徑，還有一種定位方法代碼段的命令jad --source-only 類的包路徑 方法名。
例如筆者想定位TestController的deadLock代碼，我們就可以鍵入:
jad --source-only com.example.arthasExample.TestController deadLock如下圖，我們可以直接看到的方法的代碼:
2. 查看字段詳情
我們希望看到某個類下所有字段的詳情，我們就可以使用這條命令：
sc -d -f 類的包路徑例如筆者想查看TestController的字段詳情，就可以鍵入這條命令：
sc -d -f com.example.arthasExample.TestController可以看到這條指令不僅可以查看字段的定義和注解，還可以查看線程池的使用情況以及集合內部的value：
3. 查看方法列表
這條命令筆者不是很常用，為了教程的完整性筆者也演示一下，假如我們希望查看某個類的方法，可以使用:
sm 類的包路徑以筆者為例,查看TestController的方法為:
sm com.example.arthasExample.TestController輸出結果如下:
4. 靜態變量監控
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'注意，某些場景下使用ongl表達式查看字段信息需要指明classLoader的hashCode，否則會報錯，所以我們需要通過sc指令先獲取當前類的hashCode：
sc -d com.example.arthasExample.TestController如下圖TestController的類加載器的哈希碼為68de145:
于是對應的指令我們可以改為ognl -c 68de145 '@com.example.arthasExample.TestController@list'，而輸出結果如下，可以看到變量的類型和數值都可以看到：
當然ognl還有一些比較特殊的用法，例如查看集合的長度，添加元素到集合中等操作，具體可以參考GitHub這個issue:
https://github.com/alibaba/arthas/issues/71:https://github.com/alibaba/arthas/issues/71
二、基于Arthas進行問題診斷
1. 定位CPU 100%問題
CPU 100%問題算是生產環境下最難排查的問題了，在沒有Arthas之前，我們常規的排查思路大致為:
- 使用top確定是否為java進程。
- 明確是當前java進程之后，通過jps定位java進程號。
- 找到最吃資源的線程號。
- 將線程號轉為十六進制。
- 通過jstack導出日志并使用全局搜索十六進制線程號定位到問題代碼段。
有了Arthas之后，問題的定位就會簡單快速許多，為了演示這個例子，筆者編寫了一段模擬CPU 100%問題的代碼段:
private static ExecutorService threadPool = Executors.newCachedThreadPool();
@RequestMapping("cpu-100")
public static void cpu() {
//無限循環輸出打印
new Thread(() -> {
while (true) {
log.info("cpu working");
}
}, "thread-1").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最終我們定位到了問題代碼，即時修復即可：
2. 定位線程死鎖問題
對于線程死鎖問題，我們也給出下面這樣一段示例代碼，線程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號的命令直接定位到問題代碼段并解決問題即可。
3. 運行耗時性能問題排查
對于統計耗時的操作我們經常會用打日志的方式來監控，在環境復雜的生產環境，我們常因為欠缺考慮而忘記對某些方法進行監控。 同樣的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查詢非常耗時，由此我們就可以進一步去推斷問題了。
4. 方法耗時統計
有時候我們希望監控某個方法單位時間內請求的耗時和調用情況，我們就可以使用monitor命令，例如我們希望每5s查看TestController 的queryUser的情況，我們就可以鍵入:
monitor -c 5 com.example.arthasExample.TestController queryUser可以看到控制臺會每5s輸入請求次數、成功和失敗次數以及平均耗時等信息。
5. 定位出入參錯誤問題
有時候我們希望定位某個日志沒有打到的方法的出入參詳情，例如上面的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:https://arthas.aliyun.com/doc/watch.html
6. 監控方法調用路徑
還是以上文mysql方法為例，如果我們希望快速定位到它的調用路徑，我們可以使用stack方法:
stack com.example.arthasExample.UserServiceImpl mysql可以看到詳細的調用路徑直接輸出到控制臺。
7. 獲取方法調用的過程
我們希望查看方法調用時出現異常的原因，出參和入參時，可以使用tt這條指令,例如我們想查看check方法為何會報錯，我們就可以使用tt：
tt -t com.example.arthasExample.UserServiceImpl check從輸出結果來看，第二次拋出異常了，我們可以基于1001這個索引去定位問題。
tt -i 1001最終可以得出，入參為-1：
如果我們想重新發起調用，可以直接使用：
tt -i 1001 -p需要強調的是，tt 命令是將當前環境的對象引用保存起來，但僅僅也只能保存一個引用而已。如果方法內部對入參進行了變更，或者返回的對象經過了后續的處理，那么在 tt 查看的時候將無法看到當時最準確的值。這也是為什么 watch 命令存在的意義。
所以使用完tt指令后，我們建議清除所有的 tt 記錄：
tt --delete-all8. 內存溢出問題
以下面這段代碼為例，通過不斷發起請求調用，復現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推斷到問題的源頭了。
最終我們很快速的定位到了問題代碼:
三、Arthas的一些進階操作
1. 線上替換代碼
有時候我們測試難免會遺漏一些情況，如下所示，我們業務要求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作為參數就不會報錯了，說明代碼熱更新成功了。
2. 獲取spring上下文進行進一步分析操作
有時候我們希望在線上獲取Spring容器分析定位問題，我們完全可以通過arthas攔截到這個類并進行進一步調用和分析。
讀過Spring MVC源碼的讀者可能都知道，每當又HTTP請求發送到web容器時都會進行請求進行映射轉發處理時都會經過RequestMappingHandlerAdapter這個適配器上，查看RequestMappingHandlerAdapter的類圖，可以看到它繼承了WebApplicationObjectSupport，而該類有一個方法getApplicationContext它就可以直接獲得Spring上下文，所以接下來筆者就演示如何通過tt指令獲得RequestMappingHandlerAdapter從而調用getApplicationContext拿到上下文，開始各種騷操作。
首先我們使用tt指令對RequestMappingHandlerAdapter 進行追逐，如下所示，筆者通過-t知名要追蹤的類的全路徑和方法，后續只要有請求調用該方法，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)'如下圖，可以看到，我們成功的完成了調用并得到了返回結果。
四、常見問題
1. arthas統計方法耗時watch指令的原理是什么
watch指令示例如下：
watch com.example.MyService sayHello "{params, result, throwExp} -> { return 'Exception: ' + throwExp; }" -E我們從指令即可看出他可以獲取到類的全路徑，對此我們不拿理解，它就是基于這個類的全路徑定位到類的全路徑，并對該類型通過字節碼樁技術對類的方法進行增強，即插入一段代碼進行在方法執行前后插入時間，實現耗時統計：
五、小結
自此我們對Arthas的常見操作都已演示完成，更多關于Arthas的使用讀者可以參考Arthas官網，希望對你有幫助：
https://arthas.aliyun.com/doc/:https://arthas.aliyun.com/doc/
