數據庫連接池內存泄漏問題的分析和解決方案

一、問題描述

上周五晚上主營出現部分設備掉線，經過查看日誌發現是由於緩存系統出現長時間gc導致的。這裡的gc日誌的特點是：

  • 1．gc時間都在2s以上，部分節點甚至出現12s超長時間gc。
  • 2．同一個節點距離上次gc時間間隔為普遍為13～15天。


然後緊急把剩餘未gc的一個節點內存dump下來，使用mat工具打開發現，com.mysql.jdbc.NonRegisteringDriver 對象佔了堆內存的大部分空間。


查看對象數量，發現com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference 這個對象堆積了10140 個。

初步判斷長時間gc的問題應該是由於 com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference 這個對象大量堆積引起的。

二、問題分析

目前正式環境使用數據庫相關依賴如下：

依賴 版本
mysql 5.1.47
hikari 2.7.9
Sharding-jdbc 3.1.0

根據以上描述，提出以下問題：

  • 1、com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference 到底是個什麼對象呢？
  • 2、這種對象為什麼會大量堆積，JVM回收不過來了？

NonRegisteringDriver$ConnectionPhantomReference 到底是個什麼對象呢？

簡單來說，NonRegisteringDriver類有個虛引用集合connectionPhantomRefs用於存儲所有的數據庫連接，NonRegisteringDriver.trackConnection方法負責把新創建的連接放入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.	}

我們追蹤創建數據庫連接的過程源碼，發現其中會調到com.mysql.jdbc.ConnectionImpl的構造函數，該方法會調用createNewIO方法創建一個新的數據庫連接MysqlIO對象，然後調用我們上面提到的NonRegisteringDriver.trackConnection方法，把該對象放入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 是一個虛引用集合，何為虛引用？為什麼設計為虛引用隊列

  • 虛引用隊列也稱為「幽靈引用」，它是最弱的一種引用關係。
  • 如果一個對象僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被垃 圾回收器回收。
  • 為一個對象設置虛
    引用關聯的唯一目的只是為了能在這個對象被收集器回收時收到一個系統通知。
  • 當垃圾回收器準備回收一個對象時，如果發現它還有虛引用，就會在垃圾回收後，將這個虛引用加入引用隊列，在其關聯的虛引用出隊前，不會徹底銷毀該對象。所以可以通過檢查引用隊列中是否有相應的虛引用來判斷對象是否已經被回收了。

connectionPhantomRefs 這種對象為什麼會大量堆積，JVM回收不過來了？

這裡結合項目中hikaricp數據配置和官方文檔結合說明~

我們先查閱hikaricp數據池的官網地址，看看部分屬性介紹如下：

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控制最大連接數，默認為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控制最小連接數，默認等同於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)

連接空閑時間超過idleTimeout（默認10分鐘）後，連接會被拋棄

⌚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)

連接生存時間超過 maxLifetime（默認30分鐘）後，連接會被拋棄.

我們再回頭看看項目的hikari配置：

  • 配置了minimumIdle = 10，maximumPoolSize = 50，沒有配置idleTimeout和maxLifetime。所以這兩項會使用默認值 idleTimeout = 10分鐘，maxLifetime = 30分鐘。
  • 也就是說假如數據庫連接池已滿，有50個連接，假如系統空閑，40個連接會在10分鐘後（超過idleTimeout）被廢棄；假如系統一直繁忙，50個連接會在30分鐘後（超過maxLifetime）後被廢棄。

猜測問題產生的根源：

每次新建一個數據庫連接，都會把該連接放入connectionPhantomRefs集合中。數據連接在空閑時間超過idleTimeout或生存時間超過maxLifetime後會被廢棄，在connectionPhantomRefs集合中等待回收。因為連接資源一般存活時間比較久，經過多次Young GC,一般都能存活到老年代。如果這個數據庫連接對象本身在老年代，connectionPhantomRefs中的元素就會一直堆積，直到下次 full gc。如果等到full gc 的時候connectionPhantomRefs集合的元素非常多，該次full gc就會非常耗時。

那麼怎麼解決呢？可以考慮優化minimumIdle、maximumPoolSize、idleTimeout、maxLifetime這些參數，下一小節我們分析一波

三、問題驗證

線上模擬環境

為了驗證問題，我們需要模擬線上環境，調整maxLifetime等參數~壓測思路如下：

  • 1.緩存系統模擬線上的配置，使用壓測系統一段時間內持續壓緩存系統，使緩存系統短時間創建/廢棄大量數據庫連接，觀察 NonRegisteringDriver 對象是否如期大量堆積，再手動調用 System.gc() 觀察 NonRegisteringDriver 對象是否被清理。
  • 2.調整maxLifetime 參數，觀察相同的壓測時間內 NonRegisteringDriver 對象是否還發生堆積。

這裡有以下注意點：

  • 1、 要滿足 （gc 間隔時間 * 新生代進入老年代前的存活次數 < maxLifetime）這個條件，NonRegisteringDriver 對象才滿足進入老年代的條件。
  • 2、 minimumIdle = 10，maximumPoolSize = 50（minimumIdle和maximumPoolSize和線上配置一致)，idleTimeout設置10s，maxLifetime設 100s（gc時間約20s，所以要大於 20 * 3 = 60s）。這樣預計在持續壓測下每30s就會產生10個新連接（就算設置了maximumPoolSize = 50，這種程序的壓測10個連接足以應付）
  • 3、 項目內存分配小一點，以及把新生代進入老年代前的存活次數調小一點，方便新生代的NonRegisteringDriver對象在較短時間能進入老年代，方便在較短時間觀察到明顯的對象增長。
  • 4、 要監測緩存系統數據連接池的連接存活情況，以及系統 gc情況。

最終環境配置如下：

模擬實驗結果

  • 啟用jvisualvm工具對緩存系統進行實時觀察
  • 打開hikari相關debug日誌觀察連接池情況

設置 maxLifetime = 100s，啟動緩存系統

確認hikari和jvm配置生效


觀察jvisualvm，發現產生20個NonRegisteringDriver 對象


觀察 hikari日誌，確認有20個連接對象生成，以及產生總連接10個，空閑連接10個。


初步判斷一個數據庫連接會生成兩個 NonRegisteringDriver 對象。

啟動壓測程序，壓測1000s

期間觀察gc日誌，gc時間間隔約20s，100s後發生5次 gc


觀察 hikari日誌，確認有20個連接對象生成


觀察jvisualvm變成 40個 NonRegisteringDriver 對象，符合預期。

持續觀察，1000s後理論上會產生220個對象（20 + 20 * 1000s / 100s），查看 jvisualvm 如下


產生了240個對象，基本和預期符合。

實驗結果分析

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

至此問題根源已經得到完全確認！！！

四、問題解決方案

由上面分析可知，問題產生的廢棄的數據庫連接對象堆積，最終導致 full gc 時間過長。所以我們可以從以下方面思考解決方案：

  • 1、減少廢棄的數據連接對象的產生和堆積。
  • 2、優化full gc時間.

【調整hikari參數】

我們可以考慮設置 maxLifetime 為一個較大的值，用於延長連接的生命周期，減少產生被廢棄的數據庫連接的頻率，等到下次 full gc 的時候需要清理的數據庫連接對象會大大減少。

Hikari 推薦 maxLifetime 設置為比數據庫的 wait_timeout 時間少 30s 到 1min。如果你使用的是 mysql 數據庫，可以使用 show global variables like ‘%timeout%’; 查看 wait_timeout，默認為 8 小時。

下面開始驗證，設置maxLifetime = 1小時，其他條件不變。壓測啟動前觀察jvisualvm，NonRegisteringDriver 對象數量為20


1000s，觀察 NonRegisteringDriver 對象仍然為20


NonRegisteringDriver 對象沒有發生堆積，問題得到解決。

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

【使用G1回收器】

G1回收器是目前java垃圾回收器的最新成果，是一款低延遲高吞吐的優秀回收器，用戶可以自定義最大暫停時間目標，G1會儘可能在達到高吞吐量同時滿足垃圾收集暫停時間目標。

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

使用java 8默認的Parallel GC回收器組合，部分jvm參數-Xms3G -Xmx3G


以上圖中四個內容，從左到右分別為

  • 1、堆內存，分為已使用和空閑內存。
  • 2、方法區內存，這個不需要關注
  • 3、young gc和full gc時間
  • 4、程序啟動以後young gc和full gc次數

我們可以看到使用Parallel GC回收器組合的服務消耗的內存速度較快，發生了6996次young gc且發生了一次full gc，full gc時間長達5s。另外一組使用G1回收器的服務消耗內存速度較為平穩，只發生3827次young gc且沒有發生full gc。由此可以看到G1回收器確實可以用來解決我們的數據庫連接對象堆積問題。

【建立巡查系統】

這個我們目前還沒有經過實踐，但是根據上面分析結果判斷，定期觸發full gc可以達到每次清理少量堆積的數據庫連接的作用，避免過多數據庫連接一直堆積。採用該方法需要對業務的內容和高低峰周期非常熟悉。實現思路參考如下：

  • 1、創建java程序，使用定時任務定期調用System.gc()。該方法的缺點是即使手動調用了System.gc()，jvm不一定會立刻開始回收工作，有可能會根據它本身的算法，自行選擇最優時間才開始進行回收工作。
  • 2、創建shell腳本調用jmap -dump:live,file=dump_001.bin PID，使用linux的crontab任務保證定時執行，執行完後再把dump_001.bin刪掉即可。該方法能保證一定發生full gc，缺點是功能過於單一零散，不好集中管理。

五、總結

我們這次問題產生的根源是數據庫連接對象堆積，導致full gc時間過長。解決思路可以從以下三點入手：

  • 1、調整hikari配置參數。例如把maxLifetime設置為較大的值（比數據庫的wait_timeout少30s），minimumIdle和maximumPoolSize值不能設置太大，或者直接採用默認值即可。
  • 2、採用G1垃圾回收器。
  • 3、建立巡查系統，在業務低峰期主動觸發full gc。

個人公眾號

  • 如果你是個愛學習的好孩子，可以關注我公眾號，一起學習討論。
  • 如果你覺得本文有哪些不正確的地方，可以評論，也可以關注我公眾號，私聊我，大家一起學習進步哈。

VirMach 便宜 VPS

QNews

QNews