內存泄漏學習案例-1-ArrayList

解決

---

內存泄漏

因而趕快登錄探測服務器，首先是 top free df 三連，結果還真發現了些異常。

咱們的探測進程 CPU 佔用率特別高，達到了 900%。

咱們的 Java 進程，並不作大量 CPU 運算，正常狀況下，CPU 應該在 100~200% 之間，出現這種 CPU 飆升的狀況，要麼走到了死循環，要麼就是在作大量的 GC。

使用 jstat -gc pid [interval] 命令查看了 java 進程的 GC 狀態，果真，FULL GC 達到了每秒一次。

 

這麼多的 FULL GC，應該是內存泄漏沒跑了，因而 使用 jstack pid > jstack.log 保存了線程棧的現場，

使用 jmap -dump:format=b,file=heap.log pid 保存了堆現場，而後重啓服務，報警郵件終於中止了。

jstat

jstat 是一個很是強大的 JVM 監控工具，通常用法是： jstat [-options] pid interval

它支持的查看項有：

• -class 查看類加載信息
• -compile 編譯統計信息
• -gc 垃圾回收信息
• -gcXXX 各區域 GC 的詳細信息 如 -gcold

使用它，對定位 JVM 的內存問題頗有幫助。

 

排查

分析棧

棧的分析很簡單，看一下線程數是否是過多，多數棧都在幹嗎。

> grep 'java.lang.Thread.State' jstack.log | wc -l > 464 

才四百多線程，並沒有異常。

> grep -A 1 'java.lang.Thread.State' jstack.log | grep -v 'java.lang.Thread.State' | sort | uniq -c |sort -n 10 at java.lang.Class.forName0(Native Method) 10 at java.lang.Object.wait(Native Method) 16 at java.lang.ClassLoader.loadClass(ClassLoader.java:404) 44 at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) 344 at sun.misc.Unsafe.park(Native Method) 

線程狀態好像也無異常，接下來分析堆文件。

下載堆 dump 文件。

堆文件都是一些二進制數據，在命令行查看很是麻煩，Java 爲咱們提供的工具都是可視化的，Linux 服務器上又無法查看，那麼首先要把文件下載到本地。

因爲咱們設置的堆內存爲 4G，因此 dump 出來的堆文件也很大，下載它確實很是費事，不過咱們能夠先對它進行一次壓縮。

gzip 是個功能很強大的壓縮命令，特別是咱們能夠設置 -1 ~ -9 來指定它的壓縮級別，數據越大壓縮比率越大，耗時也就越長，推薦使用 -6~7， -9 實在是太慢了，且收益不大，有這個壓縮的時間，多出來的文件也下載好了。

使用 MAT 分析 jvm heap

MAT 是分析 Java 堆內存的利器，使用它打開咱們的堆文件（將文件後綴改成 .hprof）, 它會提示咱們要分析的種類，對於此次分析，果斷選擇 memory leak suspect。

 

從上面的餅圖中能夠看出，絕大多數堆內存都被同一個內存佔用了，再查看堆內存詳情，向上層追溯，很快就發現了罪魁禍首。

 

分析代碼

找到內存泄漏的對象了，在項目裏全局搜索對象名，它是一個 Bean 對象，而後定位到它的一個類型爲 Map 的屬性。

這個 Map 根據類型用 ArrayList 存儲了每次探測接口響應的結果，每次探測完都塞到 ArrayList 裏去分析，因爲 Bean 對象不會被回收，這個屬性又沒有清除邏輯，因此在服務十來天沒有上線重啓的狀況下，這個 Map 愈來愈大，直至將內存佔滿。

內存滿了以後，沒法再給 HTTP 響應結果分配內存了，因此一直卡在 readLine 那。而咱們那個大量 I/O 的接口報警次數特別多，估計跟響應太大須要更多內存有關。

給代碼 owner 提了 PR，問題圓滿解決。

 

出處：https://www.cnblogs.com/zhenbianshu/p/10305428.html