事件背景
公司對接了新系統，代碼變動很大，項目也很急，於是在上線之后 Zabbix 不時就告警，提示 CPU 使用過載，告警消息類似如下：
一開始以為是系統停機升級，所有人都等着使用系統，導致系統處理壓力增加的緣故，所以並沒有太關注，但后來發現一直都在出這個問題，就覺得不對了。於是開始着手對問題開始處理。
排查問題
1. 由於是 CPU 使用率問題導致，所以可以先定位，到底是哪個服務導致，於是使用 top 命令查看：
top
結果如下：（使用 shift + m 可以對通過內存使用排序，方便我們找到問題進程）
當然，我這里已經是正常狀態了，故障的時候沒有來得及截圖！當時 %CPU 我記得是 398。
可以大致猜想到，肯定是代碼中某個函數問題，導致阻塞在那里了。
2. 查看該進程的開啟的線程信息使用 ps 命令：
ps -mp 6506 -o THREAD,tid,time
當然，6506 是這個有問題進程的 PID 注意改成你自己的。tid 是線程 ID，time 則是該線程運行的時間，附帶一張故障當時的截圖：
可以看到 1816 和 1817 這兩個線程 CPU 使用 94% 以上，並且運行了 7 分鍾了。
3. 由於 jstack 中線程 ID 是 16 進制的，所以我們需要轉成 16 進制來協助我們查詢問題：
printf "%x\n" 1816 printf "%x\n" 1817
結果如下：
4. 通過 JDK 自帶的 jstack 工具獲取運行時候的信息：
jstack 6506 > /tmp/1.txt
注意 6506 換成自己之前 Java 進程的 PID。我們把它重定向到 /tmp 目錄下面的 1.txt 文件，方便我們查詢。
5. 查詢異常：
此時我們可以 vim 剛剛的 1.txt 文件，搜索我們轉換成 16 進制的 tid：
我們可以將這個內容丟給對應的開發，讓他們取查看指定的代碼就行了，作為運維，我們所能做的差不多就這些。
項目最終在開發對代碼進行調整以后恢復，原因為請求第三方接口，然后等待在那里，出了問題。
最后，由於個人不是開發，又不是大牛，可能文中有些地方寫的不對，希望大家能夠在評論中補充出來。我好及時調整以免誤導看到的朋友。