cpu狂飆第二招追蹤

前提：   客戶經理在整理月報時，需要上dashborad系統匯出本月門店資料，因為本月資料已經超過上百萬條，在匯出時一直緩慢，等待很久都沒下載好，過一段時間後，客戶經理不耐煩後直接關閉網頁，重新登入系統，發現系統都登入不上，也沒有暴露錯誤喔。

解決流程：
透過上篇文章（如果不知道的，請看【cpu真的飆到270%】文章】），下面是我們的解決思路：
1.透過top定位我們系統的程式已經到達370%啦，4核的系統cpu基本佔滿，運維經理已經拉響警報。
2.透過pid定位tid，確定幾個比較耗cpu的執行緒tid
3.stack 分析幾個tid的執行緒（發現兩個情況，1.存在等待某個鎖的現象2.存在gc反覆full的情況）
4.透過jstat -gcutil pid [time][num]  命令，發現 gc的新生代和老年代分別是100% 和90%，一直沒有下降的趨勢，斷定可定是某些大物件存在老年代又一致沒有釋放。
5. 透過map -dump:live,format=b,file=[filepath] pid  獲取dump檔案，因為檔案超過1G，所以先tar 壓縮一下，可以縮小7倍，然後ftp 或者rz 拉取到本地
6.使用jdk 只帶 的  jvisualvm.exe（bin 目錄下），分析返現hashmap物件佔用了40%。
能夠最終到哪個例項物件，再結合stack 分析的定位程式碼後分析
7.發現在匯出程式中，使用hashmap儲存了一些基本資料快取在記憶體中，輪詢遍歷獲取es中的資料並結合存在haspmap的基本資料組裝返回匯出成csv資料（這裡造成map中存在大物件又一致不釋放的現象，導致cpu記憶體佔滿後出現等待鎖等情況），所以我們已經明確出現的問題啦

解決方案：
1.將基礎資料都快取到redis中，每天同步一次資料庫，用redis來當快取這樣就避免了
大物件儲存在記憶體的問題，透過一週的修改和除錯後，基本上匯出功能已經不會導致到cpu狂飆啦。

因為這是現實中存在的實戰，所以沒有截圖只是把解決思路給分享出來了啊，希望大家能夠喜歡。

       無敵TG

作者：無敵TG
連結：