線上FullGC頻繁的排查

問題

前段時間發(fā)現線上的一個dubbo服務Full GC比較頻繁，大約每兩天就會執(zhí)行一次Full GC。

成都創(chuàng)新互聯(lián)公司專注于企業(yè)成都營銷網站建設、網站重做改版、和平網站定制設計、自適應品牌網站建設、html5、商城網站定制開發(fā)、集團公司官網建設、外貿營銷網站建設、高端網站制作、響應式網頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為和平等各大城市提供網站開發(fā)制作服務。

Full GC的原因

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

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

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

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

對于我們的情況，可以初步排除1，2兩種情況，最有可能是4和5這兩種情況。為了進一步排查原因，我們在線上開啟了 -XX:+HeapDumpBeforeFullGC。

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

JVM參數的設置：

線上這個dubbo服務是分布式部署，在其中一臺機子上開啟了 -XX:HeapDumpBeforeFullGC，總體JVM參數如下：

-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ā)現用char[]類型的數據占用了41%內存，同時另外一個com.alibaba.druid.stat.JdbcSqlStat類型的數據占用了35%的內存，也就是說整個堆中幾乎全是這兩類數據。如下圖：

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

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

找到了JdbcSqlStat類，在代碼中查看這個類的代碼，關鍵代碼如下：

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

查看這個函數的調用情況，找到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();
    }
}

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

其實到這里也就知道什么原因造成了這個問題，因為我們使用的數據源是阿里巴巴的druid，這個druid提供了一個sql語句監(jiān)控功能，同時我們也開啟了這個功能。只需要在配置文件中把這個功能關掉應該就能消除這個問題，事實也的確如此，關掉這個功能后到目前為止線上沒再觸發(fā)FullGC

其他

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

歡迎關注訂閱號：

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前名稱：線上FullGC頻繁的排查-創(chuàng)新互聯(lián)
網址分享：http://jinyejixie.com/article8/ccssip.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供Google、面包屑導航、外貿網站建設、做網站、網站改版、移動網站建設

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)