您好,登錄后才能下訂單哦!
前段時間發現線上的一個dubbo服務Full GC比較頻繁,大約每兩天就會執行一次Full GC。
我們知道Full GC的觸發條件大致情況有以下幾種情況:
執行Minor GC的時候,JVM會檢查老年代中最大連續可用空間是否大于了當前新生代所有對象的總大小。
如果大于,則直接執行Minor GC(這個時候執行是沒有風險的)。
如果小于了,JVM會檢查是否開啟了空間分配擔保機制,如果沒有開啟則直接改為執行Full GC。
如果開啟了,則JVM會檢查老年代中最大連續可用空間是否大于了歷次晉升到老年代中的平均大小,如果小于則執行改為執行Full GC。
如果大于則會執行Minor GC,如果Minor GC執行失敗則會執行Full GC
對于我們的情況,可以初步排除1,2兩種情況,最有可能是4和5這兩種情況。為了進一步排查原因,我們在線上開啟了 -XX:+HeapDumpBeforeFullGC。
注意:
JVM在執行dump操作的時候是會發生stop the word事件的,也就是說此時所有的用戶線程都會暫停運行。
為了在此期間也能對外正常提供服務,建議采用分布式部署,并采用合適的負載均衡算法
線上這個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下來的文件大約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。
歡迎關注訂閱號:
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。