技術的鍋太多，到底該不該你背？
一大早就被微信群炸醒，開發短信服務的猿妹子，在公司微信群裡說：
短信的生產環境服務器， CPU 佔用率過高，瘋狂報警，應該是你們昨天上線看門狗導致的（看門狗：守護短信服務的監控應用，後續有機會再進行分享）。
沒錯，昨天確實給短信服務裝上了看門狗。但是看門狗服務肯定不會有問題（作為程序猿們，潛意識都堅信自己寫的代碼永無 Bug），主要因為測試環境都沒有此現象。
難道是測試妹子沒測試到位？難道線上短信應用自身出現了問題？
生產無小事，小事更不能忽視。迅速打開電腦，打開 VPN ，遠程登上短信生產服務器，開始猿外的 2W1H 三板斧診斷之旅。
診斷的內容有點燒腦，請大家坐穩扶好。
1. 病號是誰（WHO）？
猿外拿出控制檯診斷儀器，輸入 top 命令一探究竟，我勒個去，不看不知道一看嚇一跳，PID 為 1878 的病號，CPU 佔用居然 200% 多。
PID 為 1878 的病號到底是誰，難道真是我昨天上線的看門狗 ？
雖然猿外久經職場，但是排查生產問題時，內心還是比較忐忑，畢竟生產無小事。說時遲，那時快，只見猿外一個命令輸入 ps -ef | grep 1878 ，定睛一看，原來是短信服務本尊在作祟，心裡一下子平緩了不少。鍋找到了屬主，其實這個時候可以明確告訴短信猿妹子：是你們的短信服務導致的，這個鍋，猿外不背。但是猿外最喜歡做的不是甩鍋，而是打破砂鍋刨到底。
2. 病號哪裡出了問題（WHERE）？
為什麼 1878 號病人佔用 CPU 會這麼高呢？
只見黑乎乎的控制檯診斷儀器上，猿外熟練的輸入 jstack -l 1878 >> 1878號病歷.log ，於是便得到一份 1878 號病人的病歷詳情單。
到底 1878 號病人的哪個部位出了問題呢？
話沒說完，只見猿外，又在控制檯診斷儀器上，輸入一個 top -Hp 1878 命令，白板黑字，把 1878 號病人的器官信息全部列了出來。
看到結果，甚是一驚，PID 代號為 8721 的器官佔用 CPU 100% 多。疑惑油然而生，這個 PID 代號 為 8721 的器官是啥，是頭、是眼睛、還是胳膊腿呢？這些器官展示的 PID 列都是暱稱，都這麼善於偽裝，如何揭露它的真面目呢？
還好猿外有高招，藉助照妖鏡算法，熟練的輸入 printf "%x\n" 8721 ，果真使得代號為 8721 的器官，現了真身，真實身份居然是 2211 的呼吸道，怪不得病號一直氣喘吁吁，上氣不接下氣。
到這一步還無法對症下藥啊，還需要進一步確診 2211 的呼吸道到底出了什麼么蛾子，導致 1878 號病人一直氣喘吁吁，上氣不接下氣？
只見黑乎乎的控制檯診斷儀器上，猿外再次飛一般的在輸入 grep 2211 -A20 1878號病歷.log，診斷結果隨之顯示在診斷儀器上。
曾經背了很多鍋的猿外，看到診斷結果心裡樂了一下，一眼就看出是高併發情況下用了 HashMap 的問題（請猿友們自行尋找谷哥、度娘，就不在此深入展開啦），終於撥開雲霧見青天。
3. 如何對症下藥（ HOW ）？
在猿外行雲流水沒有一絲一毫的拖泥帶水般的神操作下，1878 號病人的診斷也就結束了，這個鍋就徹底被打破了。術業有專攻，猿外就可以鄭重的告訴短信猿妹子具體原因，捉得病根，短信猿妹子也就可以對症下藥啦。
猿外打破砂鍋的方式你 get 到了沒？猿外自己簡單概括為 2W1H 三板斧：病號是誰、病號哪裡出了問題、對症下藥。
1、病號是誰？（WHO）
- 第一步：採用 top 命令，找出 CPU 佔用最高的病號 PID ；
- 第二步：通過 ps -ef | grep PID 查看病號對應的真實身份。
2、病號哪裡出了問題？（WHERE）
- 第一步：採用 jstack -l PID >> PID.log 獲取病號的各器官信息的病歷單；
- 第二步：採用 top -Hp PID 拿到佔用 CPU 最高的器官暱稱 PID ;
- 第三步：採用 printf "%x\n" PID 根據器官暱稱 PID 的拿到器官真實身份 TID ;
- 第四步：採用 grep TID -A20 pid.log 根據 TID 去病歷單中匹配，確定是哪出了問題。
3、捉得病根、便可拿出醫藥箱，對症下藥啦。（HOW）
作為程序猿，工作中難免會遇到不少類似這樣的問題，面對問題，你如果像無頭蒼蠅一樣亂撞，撞得頭破血流依然不知道緣由，在背鍋即將成為現實時，那就不妨試試猿外的 2W1H 三板斧的診斷方式，說不定會幫你快速定位、解決線上問題，畢竟快速的解決生產問題會把損失降到最低。
最後，猿外想說的是：作為程序猿，一定要有程序猿的態度。避免背鍋，拒絕甩鍋，打破砂鍋，從猿友們做起。
作者：四猿外
來源：
https://www.cnblogs.com/siyuanwai/
