做者：陳陳html
一個小故事
週末 12 點的鬧鐘在回龍觀均價 3000 的出租屋急促的響起，程序員小A慵懶的拿過手機，滑開手機通知欄，沒有未接電話，點開手機的攔截信箱，沒有報警短信，昨晚的發佈必定很順利。小A幸福的伸了個懶腰。戴上 3000 塊的 BeatsSolo Pro，音樂逐漸響起來，小A緩緩的閉上了眼睛，正午的陽光從窗戶漫進來，撒在小A稀疏的頭髮上。此時的小A正在腦海中勾勒着本身美好的將來。房東說：十年前住在這間屋的小B，如今已是某度的 T10 大佬，五年前住在這兒的小T，如今已經在某條帶領 200 人的團隊，想到這兒，小A的嘴角微微上揚，那我也必定不會太差吧～前端
嘀嘀..耳機裏傳來兩聲消息提示音，小A內心咯噔一聲，刺骨的寒意瀰漫開來，北京三月的陽光忽然就不暖了。小A用力的微微睜開雙眼，通知欄測試同窗小C的頭像一閃而過。程序員
xx線上 BUG 緊急修復羣：小程序
小C: 「@小A 昨晚上線的代碼好像有點有問題，來公司看下？我在公司等你。」 點開羣設置，老闆的頭像赫然在列。api
懷着愧疚、徘徊、悔恨、無奈、憤怒的心情，小A翻身穿上他在路邊買的價值 20 元的人字拖，坐上了前往西二旗的地鐵十號線。瀏覽器
不久，西二旗某辦公室傳來了亙古不變的對話，「這段代碼測試過，在我電腦上沒問題啊」、"你重啓下試試"、「是否是代碼沒上線」、「是否是誰把我代碼沖掉了」、「大家測試數據是否是有問 題呀」…… 因而一個下午過去了、一個晚上過去了、一個週末過去了、一個程序員的青春過去了、一個程序員本就不長的職業生涯過去了。性能優化
一個小總結
上面這個虛構的小故事只是想說明一個簡單的現象，程序員的不少時間被線上 bug fix 佔據。由於線上線下環境不一致、輸入輸出不一等等緣由，不少 bug 定位起來效率低下，耗時巨長，致使不少時候程序員遇到線上 bug 老是頭疼不已，不禁自主的想要甩鍋給外在因素，在肯定是本身的問題的時候再排查問題。那麼線上問題排查到底難在哪兒？首先來看看咱們排查線上問題的一個基本步驟，這個步驟通常是排查大多數線上問題的步驟。併發
步驟1：找到能復現問題的輸入；分佈式
步驟2：判斷該輸入可否在平常環境構造, 若是能，調到步驟 5。若是不能，繼續步驟 3；性能
步驟3：查看線上環境日誌，看可否找到異常輸入相關的異常日誌，輔助排查問題；
步驟4：初步推斷問題緣由，嘗試修復並加上更多日誌輸出。而後打包、發佈。重複步驟 3 直到定位根因；
步驟5：平常構造相同輸入，單點調試，定位問題；
實際的場景中，由於線上線下環境隔離的問題，線上的輸入不少時候難以在平常環境中構造，大多數時候咱們都在步驟 二、三、4 中循環，因而時間就在循環中慢慢的流逝了。
上面作這麼多步驟其實對於查問題而言就是但願能夠知道當某段代碼執行不符合預期的時候，這段代碼的輸入是什麼，輸出是什麼，拋出了什麼異常，以及代碼中每一行的具體執行狀況。那麼是否有一款產品可讓用戶方便快捷的實現這個目標呢？答案是有的。
聊一聊 ARMS
阿里雲的應用實時監控服務 ARMS 是一款應用性能管理（APM）產品，包含應用監控、Prometheus 監控和前端監控三大子產品，涵蓋分佈式應用、容器環境、瀏覽器、小程序、APP 等領域的性能管理，能幫助用戶實現全棧式性能監控和端到端全鏈路追蹤診斷。
ARMS 最新推出了 Arthas 診斷功能，其第一個版本主要包含四個能力，分別是 JVM 概覽、線程耗時分析、方法執行分析以及性能分析。
- JVM 概覽：查看實時的 JVM 內存、GC 信息以及操做系統信息、環境變量、系統變量等信息。
- 線程耗時分析：查看實時的線程耗時狀況，並可查看每一個線程實時的方法堆棧。
- 方法執行分析：實時的抓取知足指定條件的方法執行明細、出入參數以及異常。
- 性能分析：快捷的經過火焰圖的的形式，展現系統性能瓶頸。
ARMS 的 Arthas 功能使用起來也比較簡單，詳情可參照文檔（ https://help.aliyun.com/document_detail/204809.html ）。下面來簡單聊一聊如何利用 ARMS 的 Arthas 診斷能力來進行線上問題的定位。
聊一聊 ARMS Arthas 診斷
上一節簡單介紹了 ARMS 的 Arthas 診斷具有的能力，那麼用這些能力能解決哪些線上問題呢？在這裏，咱們對線上問題進行了一個概括總結，將其分爲下面四類問題：
- 方法執行不符合預期： 包括方法執行耗時、方法返回值、方法拋出了異常等狀況，表如今應用上多是一些接口或者服務的 RT 增高，錯誤率增高，返回值異常等。
- 進程 CPU 耗時突增： 通常有代碼死循環問題、FullGC 致使 GC 線程耗時高、併發使用 HashMap 等。
- 性能優化問題： 主要用於分析性能瓶頸，輔助性能優化，包括 CPU 耗時、內存分配、鎖競爭、itimer 等狀況的性能分析。
- 其餘問題： 好比初始化環境變量讀取錯誤、內核版本不符合要求、類衝突等問題。
下面就以一個實際的 demo 來演示如何利用 ARMS 的 Arthas 執行不符合預期這種問題的診斷，後續的文章會繼續介紹如何利用 Arthas 進行其餘類型問題的診斷。
利用 ARMS Arthas 診斷方法執行不符合預期類問題
問題背景：product 應用的 com.alibabacloud.hipstershop.productserviceapi.service.ProductService@confirmInventory
接口某次發佈後平均 RT 到達 400，發佈之前的平均 RT 在 1ms 如下，以下圖所示。如今想定位耗時具體耗在哪兒 。
首先，進入 ARMS Arthas 診斷的頁面。當咱們進行 Bug 定位的時候，首先須要知道出問題的類名和方法名，按照圖示截圖中的紅色註釋輸入相應的類名和方法名。若是你是 EDAS用戶，可直接選擇一個服務或者接口，後臺會自動推斷相應的實現類和方法。對應到本案例，對應的類是 com.alibabacloud.xxx.xxx.xxx.ProductService，方法是 confirmInventory。填寫完畢後點擊肯定。
以下圖所示，點擊肯定後能夠獲得 confirmInventory 方法執行的紀錄，包含執行的入參，返回值異常以及方法執行明細。
可是此次執行的耗時 2.89 ms，不是咱們預期中的一次耗時高調用。此時，可點擊右上角修改診斷參數，設定抓取耗時大於 300ms 的方法調用(除此之外還能夠設置更多的過濾條件，包括方法參數知足的條件等等，具體可查看文檔)。
點擊肯定後，點擊右上角刷新圖標再次診斷，此次抓取到一次耗時 1501ms 的方法調用，發現原來是在該方法的執行過程當中，執行了 Thread.sleep() 方法。
到這裏，你可能還會好奇，爲何會執行 sleep 方法呢？這塊代碼的邏輯是怎樣的呢？點擊右上角查看方法源碼，一目瞭然的將方法源碼與方法執行明細相結合。以下圖所示，confirmInventory 方法中執行的每一次方法調用最後會以「//-」爲前綴展現該方法執行的耗時狀況。
此外，你還能夠點擊圖5 ，列表最右側的操做列的下鑽，快捷的進一步分析 confirmInventory 調用的子方法的執行狀況。這在根因比較深的場景下十分方便好用。
至此，完成了咱們這個問題的一個定位演示。
相信 ARMS 的 Arthas 診斷功能必定給你留下了深入的印象，也必定會成爲您線上問題診斷的利器，幫助您更快更方便的診斷線上故障。
寫在最後
點此快速免費體驗 ARMS 功能。
此外， 企業級分佈式應用服務EDAS K8s 做爲一款一體化的產品，既具有了應用的託管能力，也集成了 ARMS 的監控診斷能力，一樣能夠體驗 ARMS 的 Arthas 診斷功能，可根據您目前的實際狀況選擇一款產品來體驗 ARMS 的 Arthas 診斷能力。
備註：上述功能目前僅對部署在 K8s 爲集羣中的 Java 應用有效，後續會支持部署的 ECS 上的 Java 應用。