記一次內(nèi)存泄漏排查
背景
最近某項目的服務(wù)突然告警，cpu超85%，隨后就是服務(wù)宕機(jī)。交付重啟服務(wù)后恢復(fù)正常但是隨后不久又開始告警，特別是白天，嚴(yán)重影響客戶業(yè)務(wù)進(jìn)行。
問題排查
1、分析日志
查看日志的過程中發(fā)現(xiàn)存在內(nèi)存溢出（OOM），思考要么存在內(nèi)存泄漏要么業(yè)務(wù)上觸發(fā)了某個接口存在大對象，結(jié)合業(yè)務(wù)情況，應(yīng)該是前一種情況大一些。
2、查看CPU占用高的線程
按步驟
- top 找到cpu高的進(jìn)程
- top -Hp pid 找到進(jìn)程中cpu占的比較高的線程
- printf ‘%x’ 線程id 打印出線程16進(jìn)制id
- jstack pid >xxx.txt 將線程信息輸出到某個文件方便查詢
- 將cpu高的那個在步驟4中的xxx.txt中搜索出來
排查出線程都是： gc task thread parallelgc 這類線程（忘記截圖了）占用CPU高。那么這里其實可以大致得出結(jié)論了。
3、用arthas dashboard 查看應(yīng)用運行情況
老年代占比98%，隨后CPU飆升（很多公司生產(chǎn)可能都不允許使用arthas，上面步驟2其實基本可以得出結(jié)論了）
4、結(jié)論
代碼存在內(nèi)存泄漏，老年代占用率過高，導(dǎo)致系統(tǒng)頻繁full gc ，從而系統(tǒng)CPU飆升直至宕機(jī)。
問題處理
1、給啟動參數(shù)加上 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目錄} （這塊疏忽，之前沒加）
2、使用 MAT 分析 hprof文件
這里有個插曲，hprof文件太大，導(dǎo)致MAT打開報OOM。如果你是eclipse中安裝的MAT 插件，可以在 setting（perferences）-> java -> Installed JREs -> jre -> edit -> variables 設(shè)置 內(nèi)存大小 ：
server -Xms4096m -Xmx4096m -XX:PermSize=512m -XX:MaxPermSize=512m
3、找到內(nèi)存泄漏代碼
有MAT幫忙，找到對應(yīng)泄漏代碼其實就簡單多了。找到內(nèi)存占用最大得結(jié)果線程進(jìn)行查看就能看到對應(yīng)的代碼。
4、修改代碼
看了下，是代碼查詢的時候，一次查詢list過大導(dǎo)致的。后續(xù)和相關(guān)開發(fā)溝通后，優(yōu)化了sql，重新發(fā)包部署。
5、觀察
一段時間后服務(wù)器cpu恢復(fù)平穩(wěn)~~~~~
文章來源：http://www.zghlxwxcb.cn/news/detail-415134.html
至此，本次排查結(jié)束，服務(wù)CPU恢復(fù)正常狀態(tài)。后面又了解，為啥之前服務(wù)運行的好好的，最近這么頻繁宕機(jī)，一個是內(nèi)存泄漏，還有就是業(yè)務(wù)方系統(tǒng)全面鋪開，業(yè)務(wù)壓力驟增，從原來的日均五萬的量增加到了十萬，后續(xù)可能還會增加，借此機(jī)會和業(yè)務(wù)方溝通，又升級了服務(wù)硬件配置，嘻~~~~文章來源地址http://www.zghlxwxcb.cn/news/detail-415134.html
到了這里，關(guān)于記一次內(nèi)存泄漏排查的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
![[JAVA]websocket引起的內(nèi)存泄漏問題排查](https://imgs.yssmx.com/Uploads/2024/02/544204-1.png)
