今天收到測試小姐姐提的bug，在進行壓測的時，記憶體和cpu都飆高，要我分析一下。
使用jdk自帶的 jvisualvm.exe 功能（在jdk的bin目錄下）
● 如果是記憶體洩漏，堆記憶體會一直往上飆，然後會出現瘋狂gc的情況。
● 我這裡沒有出現瘋狂gc的情況，而是有規律的gc，但每次gc的時候cpu都會飆到70%以上。
ps：截圖是問題處理完之後的截圖，當時cpu使用情況已經飆到70% ~ 100%，堆記憶體占用1.3g的時候就會gc一次。
登陸伺服器，檢視具體是哪個程序中的哪些執行緒造成cpu飆高。
1. 使用top命令檢視占用cpu資源高的程序
這裡可以看到pid為27737的程序占用cpu資源較高，接下來去檢視這個程序是什麼。
2. 使用ps aux | grep pid 命令檢視具體程序資訊
當然我這裡肯定是乙個tomcat
3. 定位執行緒
使用top -h -p pid命令檢視執行緒情況
主要觀察cpu達到80%以上的執行緒，並記錄其pid。
ps：截圖為問題處理後的，當時有幾個執行緒的cpu達到85%以上。
4. 使用jstack命令檢視問題執行緒資訊
首先將記錄的執行緒pid轉換成16進製制（用命令printf "%x\n" tid），方便使用jstack命令檢視執行緒資訊
然後在使用 jstack 27683 | grep "694c"命令檢視執行緒資訊
這裡可以看到執行緒名稱，我當時的執行緒名稱中包含了log4j，因此定位到出現問題的原因是日誌。隨後檢視日誌發現日誌檔案在瘋狂列印。
通過以上步驟定位後，疑似是日誌問題，隨檢視tomcat日誌，一查嚇一跳，每毫秒列印n行日誌，這誰受得了。
然後將日誌級別改為error，問題解決。
問題排查之JVM記憶體洩漏
問題排查之jvm記憶體洩漏 1.問題描述，部署在客戶伺服器上的資料閘道器專案，客戶開發反應，出現伺服器記憶體占用很高的問題，懷疑是否為我們部署的專案導致？開始排查 一 endif 登入到客戶伺服器，首先確認是否是我們應用占用的記憶體 endif 檢視記憶體占用排行 ps aux sort k4,4n...
jvm記憶體增長問題排查簡例
排查個jvm 記憶體占用持續增加的問題，紀錄一下，引以為戒。運維發現應用jvm記憶體占用在發布後回落，然後持續增高，dump後分析一下 佔記憶體的大部分是這種名字相似的bean，會產生這麼多相同類產生的bean呢？應用使用了動態語言groovy，請求走邏輯時，動態拿到指令碼執行。其中核心 就是gro...
一次jvm記憶體溢位問題排查
首先看下問題原因 上圖的意思是獲取直接記憶體失敗，然後jvm建議減少堆的大小，或者減小每個執行緒的大小，或者增加系統記憶體 觀察下執行緒的狀態 目前總共產生了十三萬個執行緒池 編寫存在問題，一般情況下不會有這麼多執行緒池 且統計了一下，存在十三萬的執行緒都處於阻塞狀態 開始使用jstack l pi...