一、問題描述

上周三晚上主營(yíng)出現(xiàn)部分設(shè)備掉線了，查看了日志之后發(fā)現(xiàn)是由于緩存system出現(xiàn)長(zhǎng)時(shí)間gc導(dǎo)致的。這里的gc日志的特征是：

1．gc時(shí)間都在2秒以上，一部分節(jié)點(diǎn)甚至出現(xiàn)13s超長(zhǎng)時(shí)間gc。

2．同一個(gè)節(jié)點(diǎn)距離上次gc時(shí)間間隔為普遍為12～15天。

隨后緊急把剩余未gc的一個(gè)節(jié)點(diǎn)內(nèi)存dump下來，使用mat工具打開后發(fā)現(xiàn)，com.mysql.jdbc.NonRegisteringDriver 對(duì)象占了堆內(nèi)存的大部分空間。

經(jīng)過查看對(duì)象數(shù)量，發(fā)現(xiàn)com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference這個(gè)對(duì)象堆積了10140個(gè)啦。

經(jīng)過判斷長(zhǎng)時(shí)間gc的問題是由于 com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference 這個(gè)對(duì)象大量堆積造成的。

二、問題分析

current正式環(huán)境使用數(shù)據(jù)庫(kù)依賴如下面：

依賴版本

mysql5.1.47

hikari2.7.9

Sharding-jdbc3.1.0

根據(jù)以上描述，提出以下問題：

1、com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference 到底是個(gè)啥對(duì)象呢？

2、這種對(duì)象為什么會(huì)造成大量堆積，JVM回收不過來了呢？

NonRegisteringDriver$ConnectionPhantomReference 到底是個(gè)什么對(duì)象呀？

簡(jiǎn)單來說，NonRegisteringDriver類有個(gè)虛引用集合connectionPhantomRefs用于存儲(chǔ)所有的數(shù)據(jù)庫(kù)連接啊，NonRegisteringDriver.trackConnection方法負(fù)責(zé)把新創(chuàng)建的連接放入connectionPhantomRefs集合。源碼如下：

1.public class NonRegisteringDriver implements java.sql.Driver {?

2. ? protected static final ConcurrentHashMap<ConnectionPhantomReference, ConnectionPhantomReference> connectionPhantomRefs = new ConcurrentHashMap<ConnectionPhantomReference, ConnectionPhantomReference>();?

3. ? protected static final ReferenceQueue<ConnectionImpl> refQueue = new ReferenceQueue<ConnectionImpl>();

4. ?

5. ? ? ....?

6. ?

7. ? protected static void trackConnection(Connection newConn) {?

8. ?

9. ? ? ? ConnectionPhantomReference phantomRef = new ConnectionPhantomReference((ConnectionImpl) newConn, refQueue);?

10. ? ? ? ? connectionPhantomRefs.put(phantomRef, phantomRef);?

11. ? }?

12. ? ? ....?

13. }?

我們追蹤創(chuàng)建數(shù)據(jù)庫(kù)連接的中間源碼，發(fā)現(xiàn)其中會(huì)調(diào)到com.mysql.jdbc.ConnectionImpl構(gòu)造函數(shù)，該方法會(huì)調(diào)用createNewIO方法創(chuàng)建一個(gè)新的數(shù)據(jù)庫(kù)連接MysqlIO對(duì)象之后，然后調(diào)用我們上面提到的NonRegisteringDriver.trackConnection方法，把該對(duì)象放入NonRegisteringDriver.connectionPhantomRefs集合中。源碼如下面：

1.public class ConnectionImpl extends ConnectionPropertiesImpl implements MySQLConnection {?

2. ?

3. ? public ConnectionImpl(String hostToConnectTo, int portToConnectTo, Properties info, String databaseToConnectTo, String url) throws SQLException {?

4. ? ? ? ? ...?

5. ? ? ? createNewIO(false);?

6. ? ? ? ? ...?

7. ? ? ? NonRegisteringDriver.trackConnection(this);?

8. ? ? ? ? ...?

9. ? }?

10.}

connectionPhantomRefs 是一個(gè)虛引用集合，什么是虛引用？為什么設(shè)計(jì)為虛引用隊(duì)列呢

虛引用隊(duì)列也稱為“幽靈引用”，它是最弱的一種引用關(guān)系。

如果一個(gè)對(duì)象僅持有虛引用，那么它就和沒有任何引用一樣，在任何時(shí)候都可能被垃 圾回收器回收。

為一個(gè)對(duì)象設(shè)置虛 引用關(guān)聯(lián)的唯一目的只是為了能在這個(gè)對(duì)象被收集器回收時(shí)收到一個(gè)系統(tǒng)通知。

當(dāng)垃圾回收器準(zhǔn)備回收一個(gè)對(duì)象時(shí)，如果發(fā)現(xiàn)它還有虛引用，就會(huì)在垃圾回收后，將這個(gè)虛引用加入引用隊(duì)列，在其關(guān)聯(lián)的虛引用出隊(duì)前，不會(huì)徹底銷毀該對(duì)象。所以可以通過檢查引用隊(duì)列中是否有相應(yīng)的虛引用來判斷對(duì)象是否已經(jīng)被回收了。

connectionPhantomRefs 這種對(duì)象為啥會(huì)大量堆積，JVM回收不過來了么？

我們先查閱hikaricp數(shù)據(jù)池的官網(wǎng)鏈接地址，看看部分屬性介紹如下所示：

maximumPoolSize

This property controls the maximum size that the pool is allowed to reach, including both idle and in-use connections. Basically this value will determine the maximum number of actual connections to the database backend. A reasonable value for this is best determined by your execution environment. When the pool reaches this size, and no idle connections are available, calls to getConnection() will block for up to connectionTimeout milliseconds before timing out. Please read about pool sizing. Default: 10

maximumPoolSize控制最大連接數(shù)，默認(rèn)為10

minimumIdle

This property controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and total connections in the pool are less than maximumPoolSize, HikariCP will make a best effort to add additional connections quickly and efficiently. However, for maximum performance and responsiveness to spike demands, we recommend not setting this value and instead allowing HikariCP to act as a fixed size connection pool. Default: same as maximumPoolSize

minimumIdle控制最小連接數(shù)，默認(rèn)等同于maximumPoolSize，10。

?idleTimeout

This property controls the maximum amount of time that a connection is allowed to sit idle in the pool. This setting only applies when minimumIdle is defined to be less than maximumPoolSize. Idle connections will not be retired once the pool reaches minimumIdle connections. Whether a connection is retired as idle or not is subject to a maximum variation of +30 seconds, and average variation of +15 seconds. A connection will never be retired as idle before this timeout. A value of 0 means that idle connections are never removed from the pool. The minimum allowed value is 10000ms (10 seconds). Default: 600000 (10 minutes)

連接空閑時(shí)間超過idleTimeout（默認(rèn)10分鐘）后，連接會(huì)被拋棄

?maxLifetime

This property controls the maximum lifetime of a connection in the pool. An in-use connection will never be retired, only when it is closed will it then be removed. On a connection-by-connection basis, minor negative attenuation is applied to avoid mass-extinction in the pool. We strongly recommend setting this value, and it should be several seconds shorter than any database or infrastructure imposed connection time limit. A value of 0 indicates no maximum lifetime (infinite lifetime), subject of course to the idleTimeout setting. Default: 1800000 (30 minutes)

連接生存時(shí)間超過 maxLifetime（默認(rèn)30分鐘）后，連接會(huì)被拋棄.

我們?cè)倩仡^看看項(xiàng)目的hikari配置：

配置了minimumIdle = 10，maximumPoolSize = 50，沒有配置idleTimeout和maxLifetime。所以這兩項(xiàng)會(huì)使用默認(rèn)值 idleTimeout = 10分鐘，maxLifetime = 30分鐘。

也就是說假如數(shù)據(jù)庫(kù)連接池已滿，有50個(gè)連接，假如系統(tǒng)空閑，40個(gè)連接會(huì)在10分鐘后（超過idleTimeout）被廢棄；假如系統(tǒng)一直繁忙，50個(gè)連接會(huì)在30分鐘后（超過maxLifetime）后被廢棄。

猜測(cè)問題產(chǎn)生的根源：

每次新建一個(gè)數(shù)據(jù)庫(kù)連接，都會(huì)把該連接放入connectionPhantomRefs集合中。數(shù)據(jù)連接在空閑時(shí)間超過idleTimeout或生存時(shí)間超過maxLifetime后會(huì)被廢棄，在connectionPhantomRefs集合中等待回收。因?yàn)檫B接資源一般存活時(shí)間比較久，經(jīng)過多次Young GC,一般都能存活到老年代。如果這個(gè)數(shù)據(jù)庫(kù)連接對(duì)象本身在老年代，connectionPhantomRefs中的元素就會(huì)一直堆積，直到下次 full gc。如果等到full gc 的時(shí)候connectionPhantomRefs集合的元素非常多，該次full gc就會(huì)非常耗時(shí)。

那么怎么解決呢？可以考慮優(yōu)化minimumIdle、maximumPoolSize、idleTimeout、maxLifetime這些參數(shù)，下一小節(jié)我們分析一波

三、問題驗(yàn)證

線上模擬環(huán)境

為了驗(yàn)證問題，我們需要模擬線上環(huán)境，調(diào)整maxLifetime等參數(shù)~壓測(cè)思路如下：

1.緩存系統(tǒng)模擬線上的配置，使用壓測(cè)系統(tǒng)一段時(shí)間內(nèi)持續(xù)壓緩存系統(tǒng)，使緩存系統(tǒng)短時(shí)間創(chuàng)建/廢棄大量數(shù)據(jù)庫(kù)連接，觀察 NonRegisteringDriver 對(duì)象是否如期大量堆積，再手動(dòng)調(diào)用 System.gc() 觀察 NonRegisteringDriver 對(duì)象是否被清理。

2.調(diào)整maxLifetime 參數(shù)，觀察相同的壓測(cè)時(shí)間內(nèi) NonRegisteringDriver 對(duì)象是否還發(fā)生堆積。

這里有以下注意點(diǎn)：

1、 要滿足 （gc 間隔時(shí)間 * 新生代進(jìn)入老年代前的存活次數(shù) < maxLifetime）這個(gè)條件，NonRegisteringDriver 對(duì)象才滿足進(jìn)入老年代的條件。

2、 minimumIdle = 10，maximumPoolSize = 50（minimumIdle和maximumPoolSize和線上配置一致)，idleTimeout設(shè)置10s，maxLifetime設(shè) 100s（gc時(shí)間約20s，所以要大于 20 * 3 = 60s）。這樣預(yù)計(jì)在持續(xù)壓測(cè)下每30s就會(huì)產(chǎn)生10個(gè)新連接（就算設(shè)置了maximumPoolSize = 50，這種程序的壓測(cè)10個(gè)連接足以應(yīng)付）

3、 項(xiàng)目?jī)?nèi)存分配小一點(diǎn)，以及把新生代進(jìn)入老年代前的存活次數(shù)調(diào)小一點(diǎn)，方便新生代的NonRegisteringDriver對(duì)象在較短時(shí)間能進(jìn)入老年代，方便在較短時(shí)間觀察到明顯的對(duì)象增長(zhǎng)。

4、 要監(jiān)測(cè)緩存系統(tǒng)數(shù)據(jù)連接池的連接存活情況，以及系統(tǒng) gc情況。

最終環(huán)境配置如下：

模擬實(shí)驗(yàn)結(jié)果

啟用jvisualvm工具對(duì)緩存系統(tǒng)進(jìn)行實(shí)時(shí)觀察

打開hikari相關(guān)debug日志觀察連接池情況

設(shè)置 maxLifetime = 100s，啟動(dòng)緩存系統(tǒng)

確認(rèn)hikari和jvm配置生效

觀察jvisualvm，發(fā)現(xiàn)產(chǎn)生20個(gè)NonRegisteringDriver 對(duì)象

觀察 hikari日志，確認(rèn)有20個(gè)連接對(duì)象生成，以及產(chǎn)生總連接10個(gè)，空閑連接10個(gè)。

?初步判斷一個(gè)數(shù)據(jù)庫(kù)連接會(huì)生成兩個(gè) NonRegisteringDriver 對(duì)象。

啟動(dòng)壓測(cè)程序，壓測(cè)1000s

期間觀察gc日志，gc時(shí)間間隔約20s，100s后發(fā)生5次 gc

觀察 hikari日志，確認(rèn)有20個(gè)連接對(duì)象生成

觀察jvisualvm變成 40個(gè) NonRegisteringDriver 對(duì)象，符合預(yù)期。

持續(xù)觀察，1000s后理論上會(huì)產(chǎn)生220個(gè)對(duì)象（20 + 20 * 1000s / 100s），查看 jvisualvm 如下

產(chǎn)生了240個(gè)對(duì)象，基本和預(yù)期符合。

實(shí)驗(yàn)結(jié)果分析

再結(jié)合我們生產(chǎn)的問題，假設(shè)我們每天14個(gè)小時(shí)高峰期(12:00 ～ 凌晨2:00)，期間連接數(shù)20，10個(gè)小時(shí)低峰期，期間連接數(shù)10，每次 full gc 間隔14天，等到下次 full gc 堆積的 NonRegisteringDriver 對(duì)象為 (20 * 14 + 10 * 10) * 2 * 14 = 10640，與問題dump里面NonRegisteringDriver對(duì)象的數(shù)量10140 個(gè)基本吻合。

至此問題根源已經(jīng)得到完全確認(rèn)?。?！

四、問題解決方案

由上面分析可知，問題產(chǎn)生的廢棄的數(shù)據(jù)庫(kù)連接對(duì)象堆積，最終導(dǎo)致 full gc 時(shí)間過長(zhǎng)。所以我們可以從以下方面思考解決方案：

1、減少?gòu)U棄的數(shù)據(jù)連接對(duì)象的產(chǎn)生和堆積。

2、優(yōu)化full gc時(shí)間.

【調(diào)整hikari參數(shù)】

我們可以考慮設(shè)置 maxLifetime 為一個(gè)較大的值，用于延長(zhǎng)連接的生命周期，減少產(chǎn)生被廢棄的數(shù)據(jù)庫(kù)連接的頻率，等到下次 full gc 的時(shí)候需要清理的數(shù)據(jù)庫(kù)連接對(duì)象會(huì)大大減少。

Hikari 推薦 maxLifetime 設(shè)置為比數(shù)據(jù)庫(kù)的 wait_timeout 時(shí)間少 30s 到 1min。如果你使用的是 mysql 數(shù)據(jù)庫(kù)，可以使用 show global variables like '%timeout%'; 查看 wait_timeout，默認(rèn)為 8 小時(shí)。

下面開始驗(yàn)證，設(shè)置maxLifetime = 1小時(shí)，其他條件不變。壓測(cè)啟動(dòng)前觀察jvisualvm，NonRegisteringDriver 對(duì)象數(shù)量為20

?1000s，觀察 NonRegisteringDriver 對(duì)象仍然為20

?NonRegisteringDriver 對(duì)象沒有發(fā)生堆積，問題得到解決。

同時(shí)另外注意：minimumIdle和maximumPoolSize不要設(shè)置得太大，一般來說配置minimumIdle=10，maximumPoolSize=10～20即可。

【使用G1回收器】

G1回收器是目前java垃圾回收器的最新成果，是一款低延遲高吞吐的優(yōu)秀回收器，用戶可以自定義最大暫停時(shí)間目標(biāo)，G1會(huì)盡可能在達(dá)到高吞吐量同時(shí)滿足垃圾收集暫停時(shí)間目標(biāo)。

下面開始驗(yàn)證G1回收器的實(shí)用性，該驗(yàn)證過程需要一段較長(zhǎng)時(shí)間的觀察，同時(shí)借助鏈路追蹤工具skywalking。最終觀察了10天，結(jié)果圖如下： 使用G1回收器，部分jvm參數(shù)-Xms3G -Xmx3G -XX:+UseG1GC

使用java 8默認(rèn)的Parallel GC回收器組合，部分jvm參數(shù)-Xms3G -Xmx3G

以上圖中四個(gè)內(nèi)容，從左到右分別為

1、堆內(nèi)存，分為已使用和空閑內(nèi)存。

2、方法區(qū)內(nèi)存，這個(gè)不需要關(guān)注

3、young gc和full gc時(shí)間

4、程序啟動(dòng)以后young gc和full gc次數(shù)

我們可以看到使用Parallel GC回收器組合的服務(wù)消耗的內(nèi)存速度較快，發(fā)生了6996次young gc且發(fā)生了一次full gc，full gc時(shí)間長(zhǎng)達(dá)5s。另外一組使用G1回收器的服務(wù)消耗內(nèi)存速度較為平穩(wěn)，只發(fā)生3827次young gc且沒有發(fā)生full gc。由此可以看到G1回收器確實(shí)可以用來解決我們的數(shù)據(jù)庫(kù)連接對(duì)象堆積問題。

【建立巡查系統(tǒng)】

這個(gè)我們目前還沒有經(jīng)過實(shí)踐，但是根據(jù)上面分析結(jié)果判斷，定期觸發(fā)full gc可以達(dá)到每次清理少量堆積的數(shù)據(jù)庫(kù)連接的作用，避免過多數(shù)據(jù)庫(kù)連接一直堆積。采用該方法需要對(duì)業(yè)務(wù)的內(nèi)容和高低峰周期非常熟悉。實(shí)現(xiàn)思路參考如下：

1、創(chuàng)建java程序，使用定時(shí)任務(wù)定期調(diào)用System.gc()。該方法的缺點(diǎn)是即使手動(dòng)調(diào)用了System.gc()，jvm不一定會(huì)立刻開始回收工作，有可能會(huì)根據(jù)它本身的算法，自行選擇最優(yōu)時(shí)間才開始進(jìn)行回收工作。

2、創(chuàng)建shell腳本調(diào)用jmap -dump:live,file=dump_001.bin PID，使用linux的crontab任務(wù)保證定時(shí)執(zhí)行，執(zhí)行完后再把dump_001.bin刪掉即可。該方法能保證一定發(fā)生full gc，缺點(diǎn)是功能過于單一零散，不好集中管理。

五、總結(jié)

我們這次問題產(chǎn)生的根源是數(shù)據(jù)庫(kù)連接對(duì)象堆積，導(dǎo)致full gc時(shí)間過長(zhǎng)。解決思路可以從以下三點(diǎn)入手：

1、調(diào)整hikari配置參數(shù)。例如把maxLifetime設(shè)置為較大的值（比數(shù)據(jù)庫(kù)的wait_timeout少30s），minimumIdle和maximumPoolSize值不能設(shè)置太大，或者直接采用默認(rèn)值即可。

2、采用G1垃圾回收器。

3、建立巡查系統(tǒng)，在業(yè)務(wù)低峰期主動(dòng)觸發(fā)full gc。

個(gè)人公眾號(hào)