線上FullGC頻繁的排查

問題

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

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

Full GC的原因

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

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

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

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

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

注意：
    JVM在執行dump操作的時候是會發生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查看，發現用char[]類型的數據占用了41%內存，同時另外一個com.alibaba.druid.stat.JdbcSqlStat類型的數據占用了35%的內存，也就是說整個堆中幾乎全是這兩類數據。如下圖：

查看char[]類型數據，發現幾乎全是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語句監控功能，同時我們也開啟了這個功能。只需要在配置文件中把這個功能關掉應該就能消除這個問題，事實也的確如此，關掉這個功能后到目前為止線上沒再觸發FullGC

其他

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

歡迎關注訂閱號：

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

當前名稱：線上FullGC頻繁的排查-創新互聯
網址分享：http://vcdvsql.cn/article8/ccssip.html

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

廣告

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