某天早上發現服務無法正常訪問，於是展開問題排查。
1。首先檢視日誌，發現有oom日誌存在。
這時候看到oom，犯了想當然的錯誤，認為是記憶體不足，堆記憶體空間已經用完。於是檢視**發現某個模組中有如下**：
誰寫的，站出來，我保證不打你。當時盲目的認為就是使用這個執行緒池的問題(關於此執行緒池的弊端不再贅述)，於是心滿意足的修改完這行之後重新執行了。
2。沒想到過了一段時間，服務又無法正常訪問了，這讓筆者十分疑惑，查日誌時又發現了相同的日誌：
到了這裡，筆者已經意識到，這應該是機器原因導致的，因為如果是執行緒池的原因，那麼兩次觸發oom的時間應該大致相等，但是這次oom的發生卻快了很多，幾乎一開始執行就發生了oom。
3。於是開始debug之旅
首先，先根據服務名，找到程序id，1902
然後根據程序id，查出這個程序建立的執行緒數
可以看到這個服務的執行緒數是正常的，排除了這個服務的問題。
使用top命令，發現乙個可疑的執行緒如下：
問題已經基本確定，此服務程序居然用了3000多個執行緒，這明顯是有問題的。
找到了有問題的服務，那麼為什麼會報一開始的錯誤呢？我們檢視檔案/etc/security/limits.d/20-nproc.conf
可以看出，除了root使用者，其他使用者可以建立的執行緒數最多是8192。如果要迅速解決oom的問題，可以把這個值改為unlimited。
但是最好的方式，肯定是優化出問題的程式，減少建立的執行緒數。
至此，問題的來龍去脈已經明了。
反思：當發現眼熟的錯誤時切忌想當然，要多思考，先從環境角度排查。另外，模組中使用newcachedthreadpool確實是有隱患，只是這次不是newcachedthreadpool的問題，也需要解決。
一次線上FullGC問題記錄
標題採自 英雄聯盟 瑞文 斷劍重鑄之日，騎士歸來之時！前兩天早上在擠地鐵的時候看到小組群裡，主管發了好多訊息，開啟來一看，說是xx專案自從22號發版後，每天晚上就瘋狂full gc，讓我們查一下什麼原因，嘻嘻嘻，一開始聽到，心裡竊喜，為什麼呢。因為自己以前對jvm也有些了解，不過都只是紙上談兵罷了。...
記一次線上OOM問題
首先是 jmap dump format b,file file.hprof 匯入mat工具 定位的問題是 standardmanager和standardsession檢視原始碼發現concurrenthashmap node就是standardmanager的session屬性 protecte...
記一次線上OOM和效能優化
某次周五，發布前一周的伺服器小動盪?上周五，通過grafana監控，線上環境突然出現cpu和記憶體飆公升的情況 既然伺服器在某個時間點出現了高負荷，於是就先去找一開始出現問題的伺服器，去找耗時的服務，例如我當時去找資料庫耗時的服務，由於上週的日誌已經被刷掉，於是我大致描述一下 admin yyyy ...