Java應用後端響應慢問題排查思路
java應用後端響應緩慢，在未知是否資料庫寫入讀取慢、網絡鍊路正常的情況下，應該如何排查。
這裡引入arthas 的排查思路。（arthas 需要JDK 1.6 以上，且僅支援Java應用，指令詳細使用見官方文檔：https://arthas.aliyun.com/doc/）
java應用響應慢，較大機率是資料庫響應慢、自身Full GC以及業務邏輯過于複雜。鍊路調用的網絡問題在此不做讨論
一、擷取前端通路的後端接口
java 後端應用響應緩慢，需要先确認是哪個接口的傳回較慢。
- WEB應用：可通過前端浏覽器，開發者工具，network 檢視前端耗時較長的接口，逐層定位
- 是以應用适用：根據日志調用資訊，排查耗時較高的接口，串聯日志排查（比如根據業務資料在日志中的路徑，trace ID 等）
- 如果有全鍊路監控，接口監控（如zipkin、pinpoint等），根據接口定位響應緩慢的接口
- 簡單粗暴，和研發确認該功能的調用棧
- 通過arthas monitor 指令監控可疑方法
[arthas@123]$ monitor -c 5 demo.MathGame primeFactors #每隔5秒列印一次類demo.MathGame中方法primeFactors的調用情況
二、知道了響應緩慢的接口，如何進行下一步排查
通過第一步，我們基本确認了是哪個接口響應慢，接下來，借用arthas進行下一步分析。
首先應排除是否資料庫響應慢導緻，該步驟不在此讨論
1、 檢查應用GC 情況，可通過監控、GC log來檢視，在arthas 中，可通過dashboard 檢視,GC 問題可通過heapdump、threaddump 分析。
[arthas@123]$ dashboard #arthas 控制台
[arthas@123]$ jvm #jvm基本資訊
[arthas@123]$ heapdump --live /tmp/dump.hprof #列印heapdump 資訊，類似jmap:jmap -dump:[live,]format=b,file=/tmp/dump.hprof <pid>
#使用jdk 自帶指令檢視GC資訊
$ jstack -l <pid>
$ jstack[ option ] pid
dashboard 結果圖示
2、檢視是否有線程死鎖、線程阻塞。通過thread 檢視線程資訊
[arthas@123]$ thread #檢視所有線程資訊
[arthas@123]$ thread 23 #檢視線程ID是23 的線程
[arthas@123]$ thread -b #檢視阻塞線程，block 線程
[arthas@123]$ thread -n 3 #檢視最繁忙的3個線程 3、但無法确實是線程等待、block的原因時，通過trace 檢視調用鍊路及耗時
根據逐層查到耗時高的方法排查
[arthas@123]$ trace com.XXXController XXX # trace 類 方法
[arthas@123]$ trace com.XXXController XXX -n 3 # 捕捉到3次後退出
[arthas@123]$ trace com.XXXController XXX '#cost > 10' #耗時大于10ms 的請求
#更詳細用法參考官方文檔 4、根據逐層排查到的方法，最終應用是在哪裡響應較慢，結合代碼邏輯進行分析定位根因
比如是調用資料庫傳回較慢，最後一層調用應該是資料庫連接配接層耗時較高。