【爆出故障】
2019-03-04，下午16:37，我們的線上BUG羣，有人爆出APP無法使用。我趕緊拿出手機，並第一時間叫了我們的測試負責人一起查看該問題。
【定位問題】
-
我馬上登錄線上服務器，使用“jps -ml”命令，查看支撐APP服務的Java進程是否掛了，發現進程還在
-
然後我使用“df -hl”查看服務器硬盤是否滿了，發現使用了84%，那還不至於不能提供服務，不是服務器容量不夠導致的問題（爲什麼我要查詢服務器硬盤容量呢？是我們之前發生過一次因爲服務器硬盤滿了，導致無法創建數據庫連接，進而導致APP無法請求Java應用。）
-
接着，我使用top命令查看進程的資源佔用情況。top結果的第一條信息，就很明顯的顯示了，某個Java進程CPU使用了140%左右，而且一直維持在這個高位沒有降低。看了這個進程ID，發現剛好是前面“jps -ml”查出來的支撐APP服務的Java服務。
定位到問題：支撐APP的Java進程cpu佔用過高，導致無法正常提供服務。
【緊急處理】
-
由於是線上問題，且是致命的無法提供服務，所以我先用jstack命令，把當前的線程狀態打印出來（這裏我沒做好，應該先用“ps -mp pid -o THREAD,tid,time”把佔用資源最高的線程找出來，而且不能光打印當前的線程狀態，最好是把這些分析問題的信息全部輸出到文件，便於後續隨時查看當時出問題的現場）
-
馬上重啓支撐APP服務的業務系統，觀察重啓是否成功
-
重啓成功，我運行手機上的APP，並通知測試，確保正常之後，通知用戶，業務恢復正常。
【總結反思】
把線上業務恢復正常之後，回頭分析打算去分析這個問題。翻看dump出來的線程信息，發現裏面信息不全，少了很多前面的日誌，然後也沒有特別能看出問題的內容。
理了一下思路，我意識到我這裏做錯了兩步：
-
jstack dump出來的信息，不應該直接打印在終端，終端的容量有限，關閉之後就不能訪問了。應該存放在硬盤的文件裏面，那之後隨時都可以查看，而且可以發送給其他人查看。
-
重啓應用之前，應該要找出，具體是哪些線程佔用了過高的資源（這裏是CPU），這樣我就可以在線程信息繁多的dump文件裏面，找到對應的線程信息，和堆棧信息，這樣我就可以定位到具體的代碼了。
雖然這次沒能很好的找到具體的問題，但是我總結出了排查的思路，接下去我就要關注線上該服務的資源佔用情況了，能夠在下次重現該問題的時候，解決掉這個問題。
--------貓瑪尼分割線--------
公衆號：貓瑪尼
博客：https://blog.moremoney.ink/
CSDN：https://blog.csdn.net/luoyanjiewade
知乎：https://www.zhihu.com/people/luo-yan-jie-70/activities