一、前言

連接池的用途實際上有過開發經驗的朋友都已經比較清楚了，當資源對象的創建/銷毀比較耗時的場景下，可以通過"池化"技術，達到資源的復用，以此來減少系統的開銷、增大系統吞吐量，比如數據庫連接池、線程池、Redis 連接池等都是使用的該方式，而我們在開發場景中使用較為廣泛的 Jedis 就是使用了 GenericObjectPool 作為它底層的連接池實現。

二、原理概述

圖示

BorrowObject

業務模塊通過 BorrowObject 方法從空閑連接隊列中獲取空閑連接，最長會等待 maxWaitMillis 毫秒，如果拿不到則走 Create。

ReturnObject

把連接重新放回到 IdleObjects 隊列中。

類結構

Jedis裡如何使用的

一般情況下我們在 Spring Boot 應用中會通過 Spring-Data-Redis 來使用 Redis，而在業務層會通過 RedisTemplate 來進行 Redis 的操作，但是 RedisTemplate 是怎麼來的呢？可以看到當我們引入 Spring-Data-Redis 時，就會引入 RedisAutoConfiguration，這個 AutoConfiguration 定義了，當我們存在 Jedis 的配置時且不存在 RedisTempalte 的 Bean 實例時會自動創建 Bean，核心代碼如下圖。

而 RedisConnectionFactory 的其中一個實現就是 JedisConnectionFactory，其中就包含了 Pool。

而 Pool 本身內部就能看到我們真正的主角。

捋一下其中的關系，我們常用的 Spring-Data-Redis 的 Jedis 實現最終是通過以下的層級結構來使用 GenericObjectPool 的。

三、深入分析

參數說明

如上述類結構所示，GenericObjectPool 都是在 GenericObjectPoolConfig 或 BaseObjectPoolConfig 中進行配置相關參數的，其中核心參數以及默認值如下：

上圖對這些參數按顏色進行了一個歸類：

這裡需要註意的是，雖然 GenericObjectPool 支持我們配的參數較多，但是 Spring-Data-Redis 將這部分參數收斂了，具體可供我們修改的隻有表格上面的這部分內容，其他參數，有一部分在 JedisPoolConfig 類中，繼承了 GenericObjectPoolConfig 進行了修改，比如 Spring-Data-Redis 就修改了以下參數的默認值。

testWhileIdle=true minEvictableIdleTimeMillis=60000 timeBetweenEvictionRunsMillis=30000 numTestsPerEvictionRun=-1

核心方法

本文隻會針對方法的一些核心鏈路進行說明，如想知道更多細節，針對源碼解析的可以在網上搜索其他相關文章或是到我的參考鏈接裡進行翻看。

BorrowObject

超時時間怎麼用的？

該方法用於從連接池中獲取一個空閑對象，它有可能是從空閑池中直接獲取的，或是直接創建出來的，如果第一次從空閑對象中沒有獲取到，會走創建後重新獲取，此時如果對象池目前配置的 BlockWhenExhausted=true，那麼就會受 maxWaitMillis 參數所配置的超時時間所控制，如果超過了超時時間，都沒拿到一個空閑的對象，則會直接拋出異常。

testOnBorrow 和 testOnCreate 的使用場景

當獲取到一個對象後，由於對象池中往往存放的是諸如數據庫連接、Redis 連接等創建時較為耗時的資源，但是因為連接本身是復用的，如果 MySQL/Redis Server 端如果因為某些原因斷開/釋放了該鏈接，那麼此時拿到的對象就是個無效的對象，因此在 borrowObject 階段會判定，如果：

testOnBorrow=true || (create && testOnCreate=true)

就會走到：

factory.validateObject

這裡如何進行 validateObject 的，是由上層使用對象池的場景所決定的，比如在 Jedis 場景中，會向 Redis Server 發送一個 Ping 命令，如果 Server 返回了 Pong，則認為該連接仍然有效，可以給業務層使用。

但是！！！！！！

線上環境千萬不要配置 testOnBorrow=true 或是 testOnCreate=true。

每個對象的獲取都需要先校驗再拿，會大大增加單次請求的 RT。

ReturnObject

testOnReturn 的使用場景

實際上 testOnReturn 的使用場景與上述 borrowObject 時的 testOnBorrow 是類似的，隻是testOnReturn就是一個歸還對象的操作。同理，線上千萬不要配置 testOnReturn=true。

什麼時候歸還，什麼時候銷毀？

對象池中維護了一個結構為 LinkedBlockingDeque，名為 IdleObjects 的對象用於維護空閑對象隊列，且是否歸或銷毀的判斷邏輯如下：

final int maxIdleSave = getMaxIdle();
if (isClosed() || maxIdleSave > -1 && maxIdleSave <= idleObjects.size()) {
  ...銷毀對象
}else{
  ...返還至idleObjects
}

如果：

對象池已經關閉(隻要是程序在運行，且正常使用，不會關閉）

或

配置了 maxIdle 且空閑對象列表數量 >=maxIdle

則對象會被銷毀，否則對象會重新回到 IdleObjects 中。

四、內部機制

Evict(定期驅逐/保活機制)

周期怎麼定？

當
timeBetweenEvictionRunsMillis 配置 >0 時，在 GenericObjectPool 所繼承的基類中，會啟一個周期性執行的線程，它的執行周期就是
timeBetweenEvictionRunsMillis 的值。

為什麼要驅逐？

當空閑對象過多，對於客戶端或服務端的 TCP 連接維護來講，本身就是一個開銷，因此，需要有一個規則，當有一些對象實在太空閑了，就把它們踢掉。

哪些對象應該被驅逐？

首先會從空閑對象列表中挑選出一部分對象，而這個挑選過程本身也有一個規則，它受 numTestsPerEvictionRun 參數控制。

當 numTestsPerEvictionRun>0，會挑選出 numTestsPerEvictionRun 數量的空閑連接進行檢查。當 numTestsPerEvictionRun<0 時，首先會對 numTestsPerEvictionRun 取絕對值，再然後挑選出空閑數量 /numTestsPerEvictionRun 絕對值的數量進行檢查，舉個例子，如果 numTestsPerEvictionRun=-2，就會挑選出一半進行檢查。

驅逐檢查怎麼做？

本身驅逐檢查的實現方式是支持自定義的，也就是 evictionPolicy 參數，但是往往隻會選擇用默認的實現，也就是 DefaultEvictionPolicy，它的驅逐檢查策略如下：

if ((config.getIdleSoftEvictTime() < underTest.getIdleTimeMillis() &&
        config.getMinIdle() < idleCount) ||
        config.getIdleEvictTime() < underTest.getIdleTimeMillis()) {
    return true;
}
return false;

underTest 為被檢查對象，當存在以下場景時，滿足驅逐檢查規則，會觸發驅逐。

underTest 的空閑時間 >
softMinEvictableIdleTimeMillis 且當前空閑對象數量 > minIdle 或 underTest 的空閑時間 >
minEvictableIdleTimeMillis。

Tips：有一些好奇的同學可能會問，對象的空閑時間是怎麼算的？池中的對象本身會維護一個 lastReturnTime 的時間戳，它會隨著對象每一次 returnObject 時進行更新，當獲取對象空閑時間時，隻要它還是在空閑對象中，那麼用當前時間戳 -lastReturnTime 就是認為該對象的空閑時間。

驅逐與保活的關系是怎麼樣的？

由於前面提到過，不能配置 testOnBorrow 和 testOnReturn，那麼如果 Server 端的鏈接直接斷開了，怎麼能保證池中對象的有效性呢？如果讓調用端調用時再觸發，會不會太晚了呢？這時候就有個參數 testWhileIdle，當此參數打開時，就代表會在對象空閑時進行對象可用性檢查，具體代碼如下：

if (evict) {
    destroy(underTest);
    destroyedByEvictorCount.incrementAndGet();
} else {
    if (testWhileIdle) {
        try {
            factory.activateObject(underTest);
        } catch (final Exception e) {
            destroy(underTest);
            destroyedByEvictorCount.incrementAndGet();
        }
    }
}

這裡隱掉了一些相關的非核心邏輯，這裡可以看到 testWhileIdle 的保活機制實際上和 evict 是配套使用的，如果被檢查對象需要被驅逐，也就是 evict=true，則會直接 destory 對象，否則它會判定 testWhileIdle 的狀態，此時如果 testWhileIdle=true，那麼就會激活一下對象，具體激活的方式是由使用對象池的上層工廠所決定的。

Test(檢查機制)

本身 GenericObjectPool 為了保證在池子中的對象有效性，會允許上層分別在幾個節點進行對象的有效性檢查，分別是：

testOnBorrow、testOnReturn、testOnCreate。

這幾個基本看名字就知道是什麼意思了，在前面講 borrowObject 和 returnObject 的時候也有提到，還有一個相對比較特別的是：

testWhileIdle。

該參數目的是為了對象在空閑期間可以進行檢查，而它的觸發實際上是和 evict(定期驅逐機制)聯合起來進行使用的。

Abandoned(拋棄機制)

實際上在提到配置參數、BorrowObject 時，還有一個機制，稱之為 Abandoned，由於本文的契機是因為 Jedis 的問題分析所寫，而 Jedis 連接池並不支持配置 Abandoned，所以本文暫不做解析，或者感興趣的可以自己到上面講的源碼路徑去看一下，本身這個機制的理解也不是特別復雜。

五、排障方式

本身 GenericObjectPool 默認會把自己的一些參數通過 JMX 的方式進行註冊，那麼我們可以通過 Jvisualvm 進行查看，或是通過 Arthas，輸入如下命令：

mbean org.apache.commons.pool2:type=GenericObjectPool,name=pool-redisConnectionFactory

可以獲取到對象池當前的一些屬性，如下圖：

其中對於優化比較有用的就是 CreatedCount（創建對象的數量）、DestoryedCount（對象銷毀的對象）、DestoryedByEvictorCount（因為驅逐機制而被銷毀的對象數量）。

六、總結

上述文章以 Jedis 為引，分析了 GenericObjectPool 連接池的底層原理以及 Jedis 是如何使用該連接池的，並且結合了 Arthas 分享了一個簡單的排障方式，實際上如果知道了 GenericObjectPool 連接池的原理，其他連接池也是大同小異，本文希望拋磚引玉，帶大傢對於連接池的底層實現有個基本概念，相信以後遇到此類問題也會有分析的思路，不再迷茫~

*文/will

本文屬得物技術原創，更多精彩文章請看：得物技術

未經得物技術許可嚴禁轉載，否則依法追究法律責任！

Jedis連接池究竟是何物？