作者：未完成交響曲

發現異常

首先通過我們內部搭建的日志平臺發現我們線上環境一個java應用有大量的http接口請求超時，登錄linux服務器查看網絡環境沒有問題，判斷是應用自身運行異常，重啟應用后發現異常還在，開始查找問題。

初步查找問題

通過指令：jstat -gcutil 查看jvm內存占用和gc情況：

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

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

每次fullGC后的內存占用越來越高

內存占用增長速度越來越快

fullGC的頻率越來越高

最終占用達到100%，服務完全癱瘓

分析處理

使用指令：jmap -histo:live *** | more 查看堆內存中的對象數量和大小

發現Log4jLogEvent這個對象實例很多，占用內存也異常的大，初步分析是異步日志傳輸速度跟不上，導致日志對象堆積在內存中。

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

重啟應用并監控接口調用情況發現應用暫時恢復正常了。

后續分析

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

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

總結

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

歡迎大家一起交流，喜歡文章記得關注我點贊轉發喲，感謝支持！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。