因為測試人員報告說，最近訂單系統總是超時，要重啟才能恢復正常，但是第二次復現的時間不固定。
然後先是檢視下應用狀態是否正常，沒有問題。
然後檢視日誌，發現有很多交易報超時。
仔細檢視超時的日誌，發現什麼型別的交易都有，而且超時的地方也不固定，更像是系統或者架構層面的錯誤。
趕緊看下（ps ux）linux系統的狀態。發現訂單應用的cpu已經100%，但是記憶體還有剩餘，記憶體占用 大概30%+，下面是已經恢復後的截圖。
發現有多個執行緒的cpu特別高，趕緊把堆疊資訊列印出來，jstack pid >>pid.stack
用執行緒的pid轉16進製制後去裡面找，發現是下面這個東西占用高。
這個是jvm的gc執行緒，至此超時的原因找到了，但是引發這個gc執行緒占用cpu過高的根本原因還沒有頭緒。
因為這套系統是給外部聯調使用，一向很穩定，最近的**提交日誌也沒發現啥很特別的地方。檢視了下jvm的配置資訊，又問了運維人員最近有沒有動這套環境，沒人動。記憶體又沒溢位，應該不是資源未關閉或者接連未釋放。
最後來是來看看堆疊的日誌吧。說真的堆疊日誌中線程那麼多，而且各種執行緒的堆疊都有，實在不好找。沒辦法只硬著頭皮看看咯。
看了網上堆疊的分析步驟，因為是當時系統還在異常中，可以先從runnable（當前正在執行）狀態的執行緒找。從最後乙個開始看，主要是統計哪類執行緒列印的資訊多，發現執行定時任務的執行緒還比較頻繁，趕緊去看定時任務的日誌。
發現大量日誌報資源繁忙，趕緊停掉定時任務後重啟。在此期間密切監視系統資源情況，發現問題還在，cpu的使用率還是在慢慢公升高。
沒辦法，關掉外部接入，不在接受請求了，系統還是沒恢復，應該正在執行的某個任務的問題。
還是去看堆疊資訊，一步步排查，過了好久。。。。有個特別長的資訊引起了我的注意：
因為這段**是業務**部分的，而且這塊**已經在生產跑了很久沒有問題，但是我決定還是看看。重點關注：io，資源接連，外調請求，各種迴圈操作。然後有個重大發現。
//每筆最低申購額度不為空時，可申購額度應大於
//拆分金額
fundlimitallotlist fundlimitallotinfo = sysutil.getinstance(fundlimitallotlist.class);
fundlimitallotinfo.setfundcode(fundcode);
fundlimitallotinfo.setfundname(fundname);
fundlimitallotinfo.setfundtype(null);
fundlimitallotinfo.setyield(fundinfo.getyield());
fundlimitallotinfo.setsuborderamt(suborderamt);//申購金額
fundlimitallotlist.add(fundlimitallotinfo);
leftamount = leftamount.subtract(suborderamt);//剩餘待交易金額
}
這個問題很解決主要還是通過看堆疊資訊，這塊自己不是很熟悉，所以接下來可能要重點充電了。
ps：cpu過高，記憶體溢位，請第一時間懷疑**，先不要嘗試通過排查系統引數，jvm配置來解決。
一次java系統執行緒占用CPU過高問題的解決
開啟doc命令列，執行命令 jstack l 9520 d jstack.txt 開啟d盤下的jstack.txt檔案，搜尋16進製制的執行緒編號4c90，找到後就可定位到有問題的 1，使用top 命令動態的展示占用前幾的程序pid，cpu消耗，time，res 等資訊，然後找到cpu占用最高的pi...
如何定位占用cpu過高的執行緒
如何定位占用cpu過高的執行緒 近來發現平台應用響應越來越慢，通過top命令發現，cpu佔用率越來越高 1.首先根據top命令，發現占用cpu最高的程序pid 3075.通過ps aux grep pid命令，進一步檢視當前程序的具體資訊。2.顯示當前程序下的所有執行緒列表 找到耗時最高的執行緒ti...
記一次mongo資料庫CPU佔用率過高的問題
早上收到了一封預警郵件 檢視監控，cpu使用率過高，這種情況百分之95都是 問題。例項規格公升級是不用公升級的。db.currentop 查詢正在執行的命令 查詢secs running 執行時間長的語句。發現有乙個skip limit 10 的語句在執行。問詢得知是新上的跑批功能，在資料量比較大的...