前言你可能對這個業務僅僅是聽說過，而不怎麼真正了解；
你可能沒有這個故障的詳細資訊，比如可能僅僅是有使用方反饋服務中斷了10分鐘；
你對**細節還沒有仔細研究過。
這個時候該怎麼解決問題呢？根據以前的經驗，工程師們常常傾向於直接登上伺服器檢查**，試圖立刻修改問題。或者是把某些可能是問題的配置做修改，但並不是100%確認這就是問題的根本原因。但結果往往是在解決問題的同時引入了新的問題，或者是沒有找到問題的根本原因，導致使用者的再次投訴。
正文處理和排除故障分為4個必須的步驟：
(1) 緊急處理
(2) 新增監控
(3) 使用jdk效能監控工具
(4) 分析源**。從治標不治本，到治標又治本。
緊急處理
緊急處理，顧名思義，是檢查和評度當前故障的影響範圍，並盡快使服務先恢復起來。其中檢查和評估當前故障的影響範圍是非常重要的。
以微博系統舉例，一般使用者的投訴率為千分之1，如果有超過10起使用者投訴，就可能是大面積故障。如果只是負責線上跟蹤的qa人員反饋的問題，而沒有使用者投訴，則可以有較多的時間去處理。
對於緊急的大面積故障，首先想到的不應該是檢查問題。而是需要立刻追查最近線上系統是否有更改，我們的經驗是95%的故障都是在新**上線後的12小時內發生的。此時應該立刻回滾新更改。另外5%的故障大部分是由於業務擴充套件導致的。網際網路業有乙個規律，線上系統每半年需要重構一次，否則無法對應業務量的增長。對於這種業務量增長造成的故障，通常可以通過重啟服務來緊急處理。
因此，緊急處理的首選是立刻回滾新更改。
新增監控
緊急處理之後，服務已經恢復了，但是問題並沒有找到。如果是新**上線造成的故障，回滾之後，工程師會有各種手段，在測試環境追查問題。而針對系統容量不足造成的故障，需要特別新增監控作為追查問題的重要手段。
使用jdk效能監控工具
剛剛新增的監控開始報警了。登上伺服器，該做些什麼呢？一般需要做如下動作，
首先要檢視日誌，看看有沒有exception。另外日誌中常常有對介面呼叫，快取使用的監控告警資訊。
看看目前gc的狀況如何，使用jdk自帶的工具就可以。
jmap -histo pid > jmap.log，該命令會打出所有物件，包括占用的byte數和例項個數。分享乙個線上jmap例項。
檢查目前cpu占用情況，top -h，然後按「1」，會看到當前程序中每個執行緒所佔cpu的比例。注意觀察前幾名，然後jstack -l pid > jstack.log打出執行緒堆疊，看看是什麼執行緒占用了cpu。這裡需要注意的是，top -h顯示的執行緒id是十進位制，而jstack打出的執行緒堆疊是16進製制。看看那些最忙的thread是不是那些真正應該忙的thread，如果是一些「黑馬」執行緒，則要考慮是否是**有死迴圈或者是意外的問題。
分析源**
分析源**是最有技術含量的事情，也是比較耗時而且不見得有效果的事情。所以我把原始碼分析放到解決線上問題的最後一步，因為必須要做到「有的放矢」。帶著問題去分析**，會比較容易。通過20%**的修改，就可以解決80%的效能問題。比如上面這個線上問題，肯定是執行緒處理慢造成的問題。需要針對執行緒的呼叫，同步非同步等進行分析。
擴充套件閱讀
如何避免問渣問題？
快取在高併發場景下的常見問題
基於 spring boot 和 spring cloud 實現微服務架構
掃碼關注免費獲取更多資源
線上故障排查（2019 12 02）
背景介紹 一 背景介紹 二 排查過程 服務列表 服務名稱 介紹ms crf 主應用ms base org 使用者服務 ms hrpaccoint 賬號服務 主應用ms crf專案新增使用者報錯，經過查詢服務日誌是呼叫ms base org使用者服務時候報 系統錯誤 查詢ms base org服務日誌...
線上服務異常排查
相關指令 tail cat less grep wc sed split 常用日誌查詢 滾動載入日誌 tail f log less log 檢視日誌 配套使用過濾關鍵字排查問題 cat n log grep 關鍵字 a b c 行數 日誌分割擷取便於定位問題 使用sed 指令碼操作檔案 按照時間點...
一次線上tomcat OOM故障排查
公司的一組tomcat集群最近隔段時間出現oom故障的問題，間隔時間以及發生故障的tomcat也是隨機的，一時定位不到問題 發生oom時 使用 jmap dump file 檔名.dump pid 一直無法dump出堆記憶體，於是給所有tomcat啟動指令碼配置引數，發生oom時匯出堆記憶體快照。x...