有乙個專案執行一段時間後就會出現oom，下面梳理下尋找問題根源的方法某一天，乙個好久沒動過的服務崩掉了，top檢視程序占用cpu高達700%+ ? 按照top，jstack一條龍查詢導致異常的執行緒
這裡沒看到什麼異常，把堆檔案dump到本地進行分析：
? 看到hashmap將近佔了記憶體大小的50%。開始尋找專案裡**用到hashmap
專案裡沒有找到使用hashmap的地方，轉而思考是否是引用的第三方工具包使用不當導致oom
看到有很多set方法和map方法，最後想到這部分應該是orika中實體轉化過程中反射部分用到的。大體確定是orika導致的問題，於是檢視專案中使用到orika的地方
發現每次使用orika轉化物件時，都會去register一次。。。實際上可以只針對欄位有差異的物件進行對映並註冊一次，其他相同欄位的物件可以選擇預設對映。
至此問題解決。
?♂ 小插曲: 在查詢問題過程中看到hashmap可能會導致記憶體洩漏的原因，這邊也總結下，主要是因為hashmap的key可能是乙個自定義物件，而這個物件的hashcode和equals方法可能是有問題的。因為hashmap在put乙個新物件時，會通過key的hashcode方法和equals方法來確定是否發生hash衝突，進而新增或替換舊值，如果equals方法或hashcode方法是根據變數做計算並返回結果的話，可能會因為自定義物件的變數變化而導致hashcode方法或equals方法返回的值與原來的不一樣，反反覆覆，就會有多個相同的value插入，但是卻無法引用到。最終導致oom參考：記一次線上OOM問題
首先是 jmap dump format b,file file.hprof 匯入mat工具 定位的問題是 standardmanager和standardsession檢視原始碼發現concurrenthashmap node就是standardmanager的session屬性 protecte...
記一次 OOM 查詢過程
監控系統發現服務掛掉,登上機器ps ef grep 發現程序還在，因為監控系統是通過心跳檢測來監控服務的存活狀態的，服務假死 1 df free top 三連 磁碟空間正常 記憶體使用率正常 某個程序的cpu佔用率達300 多 2 top h p pid 檢視占用cpu最高的程序對應執行緒，得到執行...
記一次線上OOM和效能優化
某次周五，發布前一周的伺服器小動盪?上周五，通過grafana監控，線上環境突然出現cpu和記憶體飆公升的情況 既然伺服器在某個時間點出現了高負荷，於是就先去找一開始出現問題的伺服器，去找耗時的服務，例如我當時去找資料庫耗時的服務，由於上週的日誌已經被刷掉，於是我大致描述一下 admin yyyy ...