線上FullGC頻繁的排查

線上FullGC頻繁的排查

問題

前段時(shí)間發(fā)現(xiàn)線上的一個(gè)dubbo服務(wù)Full GC比較頻繁，大約每兩天就會(huì)執(zhí)行一次Full GC。

Full GC的原因

我們知道Full GC的觸發(fā)條件大致情況有以下幾種情況：

1. 程序執(zhí)行了System.gc() //建議jvm執(zhí)行fullgc，并不一定會(huì)執(zhí)行
2. 執(zhí)行了jmap -histo:live pid命令 //這個(gè)會(huì)立即觸發(fā)fullgc
3. 在執(zhí)行minor gc的時(shí)候進(jìn)行的一系列檢查

   執(zhí)行Minor GC的時(shí)候，JVM會(huì)檢查老年代中最大連續(xù)可用空間是否大于了當(dāng)前新生代所有對(duì)象的總大小。
   如果大于，則直接執(zhí)行Minor GC（這個(gè)時(shí)候執(zhí)行是沒有風(fēng)險(xiǎn)的）。
   如果小于了，JVM會(huì)檢查是否開啟了空間分配擔(dān)保機(jī)制，如果沒有開啟則直接改為執(zhí)行Full GC。
   如果開啟了，則JVM會(huì)檢查老年代中最大連續(xù)可用空間是否大于了歷次晉升到老年代中的平均大小，如果小于則執(zhí)行改為執(zhí)行Full GC。
   如果大于則會(huì)執(zhí)行Minor GC，如果Minor GC執(zhí)行失敗則會(huì)執(zhí)行Full GC

4. 使用了大對(duì)象 //大對(duì)象會(huì)直接進(jìn)入老年代
5. 在程序中長期持有了對(duì)象的引用 //對(duì)象年齡達(dá)到指定閾值也會(huì)進(jìn)入老年代

對(duì)于我們的情況，可以初步排除1，2兩種情況，最有可能是4和5這兩種情況。為了進(jìn)一步排查原因，我們?cè)诰€上開啟了 -XX:+HeapDumpBeforeFullGC。

    注意：
    JVM在執(zhí)行dump操作的時(shí)候是會(huì)發(fā)生stop the word事件的，也就是說此時(shí)所有的用戶線程都會(huì)暫停運(yùn)行。
    為了在此期間也能對(duì)外正常提供服務(wù)，建議采用分布式部署，并采用合適的負(fù)載均衡算法

JVM參數(shù)的設(shè)置：

線上這個(gè)dubbo服務(wù)是分布式部署，在其中一臺(tái)機(jī)子上開啟了 -XX:HeapDumpBeforeFullGC，總體JVM參數(shù)如下：

-Xmx2g 
-XX:+HeapDumpBeforeFullGC 
-XX:HeapDumpPath=. 
-Xloggc:gc.log 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=10 
-XX:GCLogFileSize=100m 
-XX:HeapDumpOnOutOfMemoryError 

Dump文件分析

dump下來的文件大約1.8g，用jvisualvm查看，發(fā)現(xiàn)用char[]類型的數(shù)據(jù)占用了41%內(nèi)存，同時(shí)另外一個(gè)com.alibaba.druid.stat.JdbcSqlStat類型的數(shù)據(jù)占用了35%的內(nèi)存，也就是說整個(gè)堆中幾乎全是這兩類數(shù)據(jù)。如下圖：

查看char[]類型數(shù)據(jù)，發(fā)現(xiàn)幾乎全是sql語句。

接下來查看char[]的引用情況：

找到了JdbcSqlStat類，在代碼中查看這個(gè)類的代碼，關(guān)鍵代碼如下：

構(gòu)造函數(shù)只有這一個(gè)
public JdbcSqlStat(String sql){
    this.sql = sql;
    this.id = DruidDriver.createSqlStatId();
}

查看這個(gè)函數(shù)的調(diào)用情況，找到com.alibaba.druid.stat.JdbcDataSourceStat#createSqlStat方法：

public JdbcSqlStat createSqlStat(String sql) {
    lock.writeLock().lock();
    try {
        JdbcSqlStat sqlStat = sqlStatMap.get(sql);
        if (sqlStat == null) {
            sqlStat = new JdbcSqlStat(sql);
            sqlStat.setDbType(this.dbType);
            sqlStat.setName(this.name);
            sqlStatMap.put(sql, sqlStat);
        }

        return sqlStat;
    } finally {
        lock.writeLock().unlock();
    }
}

這里用了一個(gè)map來存放所有的sql語句。

其實(shí)到這里也就知道什么原因造成了這個(gè)問題，因?yàn)槲覀兪褂玫臄?shù)據(jù)源是阿里巴巴的druid，這個(gè)druid提供了一個(gè)sql語句監(jiān)控功能，同時(shí)我們也開啟了這個(gè)功能。只需要在配置文件中把這個(gè)功能關(guān)掉應(yīng)該就能消除這個(gè)問題，事實(shí)也的確如此，關(guān)掉這個(gè)功能后到目前為止線上沒再觸發(fā)FullGC

其他

如果用mat工具查看，建議把 "Keep unreachable objects" 勾上，否則mat會(huì)把堆中不可達(dá)的對(duì)象去除掉，這樣我們的分析也許會(huì)變得沒有意義。如下圖：Window-->References 。另外jvisualvm對(duì)ool的支持不是很好，如果需要oql建議使用mat。

歡迎關(guān)注訂閱號(hào)：