Java內存泄漏問題處理方法經驗總結
JVM問題,一般會有三種情況,目前遇到了兩種,線程溢出和JVM不夠用
1.線程溢出:unable to create new native thread
1.1問題描述:
系統(tǒng)在1月4號左右,突然發(fā)現會產生內存溢出問題,從日志上看,錯誤信息為:

導致系統(tǒng)不能使用,對外不能相應,但是觀察gc等又處于正常情況,free 系統(tǒng)內存也正常。開始重啟機器進行解決,真正的原因查找,過程比較坎坷,經歷也比較痛苦。
1.2 問題解決
- pstree查看線程數,發(fā)現系統(tǒng)線程數不斷增長,直到OOM。
命令:pstree -p pid (對該項已經加了監(jiān)控)
- 線程過多導致的內存溢出,但是那里的線程過多呢?!
我們實現了ThreadFactory,通過它,給線程的加一個前綴。來標記線程所屬。重現問題后,發(fā)現是task模塊的TaskScheduler的定時任務中,在方法內使用
ExecutorService taskExecutor = Executors.newFixedThreadPool(nThreads);
taskExecutor.invokeAll(tasks);
導致回收不及時,發(fā)生了問題。
2.內存溢出:老生代100%無法及時回收
2.1問題現象:
1月31號,中午中影突然所有的機器陸續(xù)出現不能工作的現象,日志中看不到OOM錯誤,但是不能訪問服務,或者訪問非常的慢,觀察jmap -heap發(fā)現老生代占用達到99%以上(不同版本JDK顯示可能不一樣。)

2.2 問題解決:
1、查看對內存使用情況,發(fā)現存在JVM堆內存不能釋放的問題
- 命令:jmap -heap pid 此命令有時候,會執(zhí)行卡頓,不建議加監(jiān)控
- 語法:jmap - heap pid
2、進一步查看gc回收情況,發(fā)現FGC頻率高,而且時間長,且回收不給力。
- 命令:jstat -gcutil pid
- 語法:jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]
3、查看JVM堆中具體有哪些對象。發(fā)現不正常,Byte數組占用過大。實例達到1億兩千萬,大小竟然有4g(3958M).同時,訂單、hibernate引擎、mysql結果集類實例都很多。
- 命令:jmap -histo
- 語法:jmap -histo[:live] pid
4、查看Mysql慢查詢,發(fā)現確實找達到問題原因。
命令1:mysql數據庫上查看,所有的。
命令2:查看當前慢查詢
SELECT * from information_schema.`PROCESSLIST` ;(簡化版:show PROCESSLIST)
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接
相關文章
淺談springboot多模塊(modules)開發(fā)
這篇文章主要介紹了淺談springboot多模塊(modules)開發(fā),詳細的介紹了springboot多模塊的實現,有興趣的可以了解一下2017-09-09
Java實現利用廣度優(yōu)先遍歷(BFS)計算最短路徑的方法
這篇文章主要介紹了Java實現利用廣度優(yōu)先遍歷(BFS)計算最短路徑的方法,實例分析了廣度優(yōu)先遍歷算法的原理與使用技巧,具有一定參考借鑒價值,需要的朋友可以參考下2015-04-04

