Java內(nèi)存泄漏問題處理方法經(jīng)驗(yàn)總結(jié)

JVM問題，一般會(huì)有三種情況，目前遇到了兩種，線程溢出和JVM不夠用

1.線程溢出：unable to create new native thread

1.1問題描述：

系統(tǒng)在1月4號(hào)左右，突然發(fā)現(xiàn)會(huì)產(chǎn)生內(nèi)存溢出問題，從日志上看，錯(cuò)誤信息為：

導(dǎo)致系統(tǒng)不能使用，對(duì)外不能相應(yīng)，但是觀察gc等又處于正常情況，free 系統(tǒng)內(nèi)存也正常。開始重啟機(jī)器進(jìn)行解決，真正的原因查找，過程比較坎坷，經(jīng)歷也比較痛苦。

1.2 問題解決

• pstree查看線程數(shù)，發(fā)現(xiàn)系統(tǒng)線程數(shù)不斷增長(zhǎng)，直到OOM。

命令：pstree  -p pid (對(duì)該項(xiàng)已經(jīng)加了監(jiān)控)

• 線程過多導(dǎo)致的內(nèi)存溢出，但是那里的線程過多呢？！

我們實(shí)現(xiàn)了ThreadFactory，通過它，給線程的加一個(gè)前綴。來標(biāo)記線程所屬。重現(xiàn)問題后，發(fā)現(xiàn)是task模塊的TaskScheduler的定時(shí)任務(wù)中，在方法內(nèi)使用

ExecutorService taskExecutor = Executors.newFixedThreadPool(nThreads);

taskExecutor.invokeAll(tasks);

導(dǎo)致回收不及時(shí)，發(fā)生了問題。

2.內(nèi)存溢出：老生代100%無法及時(shí)回收

2.1問題現(xiàn)象：

1月31號(hào)，中午中影突然所有的機(jī)器陸續(xù)出現(xiàn)不能工作的現(xiàn)象，日志中看不到OOM錯(cuò)誤，但是不能訪問服務(wù)，或者訪問非常的慢，觀察jmap -heap發(fā)現(xiàn)老生代占用達(dá)到99%以上（不同版本JDK顯示可能不一樣。）

2.2 問題解決：

1、查看對(duì)內(nèi)存使用情況，發(fā)現(xiàn)存在JVM堆內(nèi)存不能釋放的問題

•    命令：jmap -heap pid   此命令有時(shí)候，會(huì)執(zhí)行卡頓，不建議加監(jiān)控
•    語法：jmap - heap pid

2、進(jìn)一步查看gc回收情況，發(fā)現(xiàn)FGC頻率高，而且時(shí)間長(zhǎng)，且回收不給力。

• 命令：jstat -gcutil pid
• 語法：jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

3、查看JVM堆中具體有哪些對(duì)象。發(fā)現(xiàn)不正常，Byte數(shù)組占用過大。實(shí)例達(dá)到1億兩千萬，大小竟然有4g(3958M).同時(shí)，訂單、hibernate引擎、mysql結(jié)果集類實(shí)例都很多。

• 命令：jmap -histo
• 語法：jmap -histo[:live] pid

4、查看Mysql慢查詢，發(fā)現(xiàn)確實(shí)找達(dá)到問題原因。

命令1:mysql數(shù)據(jù)庫上查看，所有的。

命令2：查看當(dāng)前慢查詢

SELECT * from information_schema.`PROCESSLIST` ;(簡(jiǎn)化版：show PROCESSLIST)

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)億速云的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接