作者：未完成交響曲

發(fā)現(xiàn)異常

首先通過我們內(nèi)部搭建的日志平臺發(fā)現(xiàn)我們線上環(huán)境一個java應(yīng)用有大量的http接口請求超時，登錄linux服務(wù)器查看網(wǎng)絡(luò)環(huán)境沒有問題，判斷是應(yīng)用自身運行異常，重啟應(yīng)用后發(fā)現(xiàn)異常還在，開始查找問題。

初步查找問題

通過指令：jstat -gcutil 查看jvm內(nèi)存占用和gc情況：

發(fā)現(xiàn)老年代內(nèi)存占用比例過高，并且每次fullGC后并沒有有效回收。老年代內(nèi)存占用百分比變化趨勢大致如下：

初步判斷大量請求超時和服務(wù)癱瘓的直接原因：

每次fullGC后的內(nèi)存占用越來越高

內(nèi)存占用增長速度越來越快

fullGC的頻率越來越高

最終占用達到100%，服務(wù)完全癱瘓

分析處理

使用指令：jmap -histo:live *** | more 查看堆內(nèi)存中的對象數(shù)量和大小

發(fā)現(xiàn)Log4jLogEvent這個對象實例很多，占用內(nèi)存也異常的大，初步分析是異步日志傳輸速度跟不上，導(dǎo)致日志對象堆積在內(nèi)存中。

嘗試使用調(diào)整Flume傳輸日志參數(shù)：提高flume單次傳輸量，減少最大延遲時間

重啟應(yīng)用并監(jiān)控接口調(diào)用情況發(fā)現(xiàn)應(yīng)用暫時恢復(fù)正常了。

后續(xù)分析

在前一步分析內(nèi)存的同時，使用指令：jmap -dump:format=b,file=heapDump.hprof將實時內(nèi)存信息導(dǎo)出(dump過程比較慢，所以在問題暫時處理完后進行后續(xù)分析)，使用mat分析內(nèi)存結(jié)構(gòu)：

可以看到主要占據(jù)堆內(nèi)存的對象信息，果然是Flume異步傳輸日志堵塞的問題。

總結(jié)

對jvm內(nèi)存泄露這類問題的解決，主要是要善于利用jvm提供的類似jstat、jmap等工具來分析查找問題。這次問題雖然解決，但是后續(xù)還是存在出現(xiàn)此類問題的風險。所以除了加強jvm問題排查能力的同時，我們也將建立應(yīng)用監(jiān)控平臺的計劃提上日程，希望能對jvm內(nèi)存、線程等應(yīng)用實時運行指標進行監(jiān)控，便于盡早發(fā)現(xiàn)問題。

歡迎大家一起交流，喜歡文章記得關(guān)注我點贊轉(zhuǎn)發(fā)喲，感謝支持！

總結(jié)

以上是生活随笔為你收集整理的videocapture.read()解决内存泄露_只需4个步骤，分析解决在生产环境下JVM内存泄露问题...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。