[[407612]]

P0事故安排上了

原來以為內(nèi)存溢出這種事情只會發(fā)生在書本上，沒想到在我們生產(chǎn)環(huán)境發(fā)生了，而且是618，P0事故安排上了。先回顧一下內(nèi)存溢出排查的基本思路，然后再來復(fù)盤一下內(nèi)存溢出發(fā)生的原因

內(nèi)存溢出排查

我們先來了解一下Java堆的組成機(jī)構(gòu)。對于大多數(shù)應(yīng)用來說，Java堆(Java Heap)是Java虛擬機(jī)鎖管理的內(nèi)存中最大的一塊。Java堆是所有線程共享的一塊內(nèi)存區(qū)域，在虛擬機(jī)啟動時創(chuàng)建。此內(nèi)存區(qū)域的唯一目的就是存放對象實(shí)例，幾乎所有的對象實(shí)例都在這里分配內(nèi)存

「堆的結(jié)構(gòu)如下」

「新生代老年代的具體劃分比例如下」

「分代的主要作用就是為了更高效的管理內(nèi)存」

內(nèi)存泄漏和內(nèi)存溢出是2個不同的概念

內(nèi)存泄漏：對象已經(jīng)不使用了，但是還占用著內(nèi)存空間，沒有被釋放 內(nèi)存溢出：堆空間不夠用了，通常表現(xiàn)為OutOfMemoryError，內(nèi)存泄漏通常會導(dǎo)致內(nèi)存溢出

使用Java VisualVM分析排查

「我們可以通過jdk自帶的jvisualvm命令來分析堆的使用情況」

我們寫一個程序，來演示內(nèi)存不斷增加的場景

public class OomDemo { 
 
    private static final int NUM = 1024; 
 
    public static void main(String[] args) throws InterruptedException { 
        List<byte[]> list = Lists.newArrayList(); 
        for (int i = 0; i < NUM; i++) { 
            TimeUnit.SECONDS.sleep(1); 
            list.add(new byte[NUM * NUM]); 
        } 
    } 
} 

「命令行中執(zhí)行jvisualvm即可彈出圖形界面，我們可以連接到本機(jī)上的程序，也可以連接到遠(yuǎn)程機(jī)器，還可以分析生成快照文件等」。

可以清晰的看到堆空間在不斷上漲，用抽樣器分析一下內(nèi)存不斷上漲的源頭在哪里?

「好家伙，byte數(shù)組居然占用了這么多內(nèi)存」

如果此時你還看不出程序哪里有問題，到監(jiān)視這個Tab點(diǎn)擊堆Dump這個按鈕，會生成一個堆的快照，然后分析這個dump文件即可

byte數(shù)組實(shí)例很少，但是占用內(nèi)存很多，再看一下具體的引用

可以看到在ArrayList中。

最后推薦一個插件Visual GC，可以清晰的看到堆的使用情況以垃圾收集信息。

點(diǎn)擊工具選中插件即可

當(dāng)然你可以通過jmap命令生成heapdump文件，然后用其他工具分析

jmap -dump:file=文件名字 進(jìn)程id 

使用Eclipse Memory Analyzer分析

Java VisualVM只提供了一些基本的功能，堆中各種對象的大小和實(shí)例數(shù)。以上面的例子為例，你只能排查到ArrayList占用了大量的內(nèi)存，這個ArrayList在哪，你也不知道

所以我們一般不使用Java VisualVM來分析，而是使用Eclipse Memory Analyzer來分析

Eclipse Memory Analyzer下載地址：https://www.eclipse.org/mat/downloads.php

還是上面的程序，我們啟動時設(shè)置如下參數(shù)，讓程序內(nèi)存溢出時自動生成Dump文件

-Xmx30m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/peng 

-Xmx30m：最大堆內(nèi)存為30m -XX:+HeapDumpOnOutOfMemoryError：當(dāng)JVM發(fā)生OOM時，自動生成DUMP文件。-XX:HeapDumpPath：指定文件路徑，例如：-XX:HeapDumpPath=${目錄}/java_heapdump.hprof。如果不指定文件名，默認(rèn)為：java_pid .hprof

生產(chǎn)環(huán)境一般都會配置堆溢出時自動生成DUMP文件圖片當(dāng)內(nèi)存溢出的時候自動生成了一個文件，java_pid28598.hprof

「用Eclipse Memory Analyzer打開這個文件，可以很清晰的看到總共使用的內(nèi)存，以及各個對象占用的內(nèi)存」，如下圖

總共使用的內(nèi)存為26.8M Thread對象占用了26M ZoneInfoFile對象占用了157.8KB 其他對象占用了696.7KB

點(diǎn)擊Leak Suspects按鈕查看具體的內(nèi)存泄露報(bào)告

分析出來有問題的部分只有一處(例子太簡單的緣故，很多時候會分析出來多處)

「main線程占用了97.21%的內(nèi)存空間」

「點(diǎn)擊標(biāo)紅按鈕，查看引用關(guān)系，可以很清晰的看到是由于main線程中ArrayList中放了26個byte數(shù)組造成的」

「另外可以很清晰的看到內(nèi)存溢出時代碼的執(zhí)行位置，排查問題非常方便」

事故復(fù)盤

先來看一下事故發(fā)生前和事故發(fā)生后JVM的情況，我們新生代用的是ParNew垃圾收集器，老年代用的是CMS垃圾收集器

13:00-13:10這段時間的情況，系統(tǒng)正常運(yùn)行

每分鐘GC暫停時間(綠色部分是CMS，黃色部分是ParNew)

每分鐘GC次數(shù)和GC平均耗時(綠色部分是CMS，黃色部分是ParNew)

新生代和老年代的占用情況

「可以看到問題發(fā)生之前老年代已經(jīng)設(shè)置的不合理了，偏小了」。

14:00-14:10這段時間的情況，14:06系統(tǒng)內(nèi)存溢出

14:00活動開始，14:05之后每分鐘垃圾回收暫停的時間過長，都達(dá)到30s了

老年代垃圾回收的時間飆升

實(shí)在沒有可回收的了，最終老年代被占滿，內(nèi)存溢出

分析dump文件

運(yùn)維配置了上面說的2個參數(shù)，內(nèi)存溢出時生成了dump文件，用Eclipse Memory Analyzer打開分析一波

總共1.9G，ThreadPoolExecutor占用了918.8MB，我們來看看ThreadPoolExecutor這個線程池里面到底放了些啥

分析報(bào)告指出的第一個問題就是ThreadPoolExecutor里面的東西太大了，占了總內(nèi)存的47.45%了，點(diǎn)擊如下按鈕，查看引用鏈路

好家伙，線程池占用了900多m空間，里面用LinkedBlockingDeque存放待執(zhí)行的任務(wù)

「隊(duì)列的能存放的最大數(shù)量是10000，目前放了883個任務(wù)，這個隊(duì)列的長度設(shè)置的也忒大了把!」

繼續(xù)點(diǎn)下去，就能看到隊(duì)列中存的具體對象，是個DTO。看包名就猜到是中間件團(tuán)隊(duì)將這個DTO放到線程池中

大概邏輯如上圖，中間件團(tuán)隊(duì)會通過一個agent攔截應(yīng)用中方法的執(zhí)行，并將入?yún)⒑头祷刂荡蛴≡谌罩局校琭lume收集日志后給鏈路平臺，監(jiān)控平臺提供數(shù)據(jù)。

方法每執(zhí)行一次打印一次日志，但是日志的打印是異步化的，將參數(shù)和返回值封裝成任務(wù)，放到線程池中執(zhí)行。由于618方法被高頻調(diào)用，而其中一類DTO對象很大(一個對象6，7m)，任務(wù)一旦堆積，很快就是OOM。「因?yàn)殛?duì)列的最大值被設(shè)置為10000，但是當(dāng)放了883個任務(wù)的時候已經(jīng)OOM了」

本文轉(zhuǎn)載自微信公眾號「Java識堂」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Java識堂公眾號。