一、前言

連接池的用途實(shí)際上有過開發(fā)經(jīng)驗(yàn)的朋友都已經(jīng)比較清楚了，當(dāng)資源對(duì)象的創(chuàng)建/銷毀比較耗時(shí)的場(chǎng)景下，可以通過"池化"技術(shù)，達(dá)到資源的復(fù)用，以此來減少系統(tǒng)的開銷、增大系統(tǒng)吞吐量，比如數(shù)據(jù)庫連接池、線程池、Redis 連接池等都是使用的該方式，而我們?cè)陂_發(fā)場(chǎng)景中使用較為廣泛的 Jedis 就是使用了 GenericObjectPool 作為它底層的連接池實(shí)現(xiàn)。

二、原理概述

圖示

圖片

• BorrowObject

業(yè)務(wù)模塊通過 BorrowObject 方法從空閑連接隊(duì)列中獲取空閑連接，最長(zhǎng)會(huì)等待 maxWaitMillis 毫秒，如果拿不到則走 Create。

• ReturnObject

• 把連接重新放回到 IdleObjects 隊(duì)列中。

類結(jié)構(gòu)

圖片

Jedis里如何使用的

圖片

而 RedisConnectionFactory 的其中一個(gè)實(shí)現(xiàn)就是 JedisConnectionFactory，其中就包含了 Pool。

圖片

而 Pool 本身內(nèi)部就能看到我們真正的主角。

圖片

捋一下其中的關(guān)系，我們常用的 Spring-Data-Redis 的 Jedis 實(shí)現(xiàn)最終是通過以下的層級(jí)結(jié)構(gòu)來使用 GenericObjectPool 的。

圖片

三、深入分析

參數(shù)說明

如上述類結(jié)構(gòu)所示，GenericObjectPool 都是在 GenericObjectPoolConfig 或 BaseObjectPoolConfig 中進(jìn)行配置相關(guān)參數(shù)的，其中核心參數(shù)以及默認(rèn)值如下：

圖片

上圖對(duì)這些參數(shù)按顏色進(jìn)行了一個(gè)歸類：

圖片

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

testWhileIdle=true

minEvictableIdleTimeMillis=60000

timeBetweenEvictinotallow=30000

numTestsPerEvictinotallow=-1

核心方法

本文只會(huì)針對(duì)方法的一些核心鏈路進(jìn)行說明，如想知道更多細(xì)節(jié)，針對(duì)源碼解析的可以在網(wǎng)上搜索其他相關(guān)文章或是到我的參考鏈接里進(jìn)行翻看。

BorrowObject

• 超時(shí)時(shí)間怎么用的？

該方法用于從連接池中獲取一個(gè)空閑對(duì)象，它有可能是從空閑池中直接獲取的，或是直接創(chuàng)建出來的，如果第一次從空閑對(duì)象中沒有獲取到，會(huì)走創(chuàng)建后重新獲取，此時(shí)如果對(duì)象池目前配置的 BlockWhenExhausted=true，那么就會(huì)受 maxWaitMillis 參數(shù)所配置的超時(shí)時(shí)間所控制，如果超過了超時(shí)時(shí)間，都沒拿到一個(gè)空閑的對(duì)象，則會(huì)直接拋出異常。

• testOnBorrow 和 testOnCreate 的使用場(chǎng)景

當(dāng)獲取到一個(gè)對(duì)象后，由于對(duì)象池中往往存放的是諸如數(shù)據(jù)庫連接、Redis 連接等創(chuàng)建時(shí)較為耗時(shí)的資源，但是因?yàn)檫B接本身是復(fù)用的，如果 MySQL/Redis Server 端如果因?yàn)槟承┰驍嚅_/釋放了該鏈接，那么此時(shí)拿到的對(duì)象就是個(gè)無效的對(duì)象，因此在 borrowObject 階段會(huì)判定，如果：

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

就會(huì)走到：

factory.validateObject

這里如何進(jìn)行 validateObject 的，是由上層使用對(duì)象池的場(chǎng)景所決定的，比如在 Jedis 場(chǎng)景中，會(huì)向 Redis Server 發(fā)送一個(gè) Ping 命令，如果 Server 返回了 Pong，則認(rèn)為該連接仍然有效，可以給業(yè)務(wù)層使用。

但是！！！！！！

線上環(huán)境千萬不要配置 testOnBorrow=true 或是 testOnCreate=true。

每個(gè)對(duì)象的獲取都需要先校驗(yàn)再拿，會(huì)大大增加單次請(qǐng)求的 RT。

ReturnObject

• testOnReturn 的使用場(chǎng)景

實(shí)際上 testOnReturn 的使用場(chǎng)景與上述 borrowObject 時(shí)的 testOnBorrow 是類似的，只是testOnReturn就是一個(gè)歸還對(duì)象的操作。同理，線上千萬不要配置 testOnReturn=true。

• 什么時(shí)候歸還，什么時(shí)候銷毀？

對(duì)象池中維護(hù)了一個(gè)結(jié)構(gòu)為 LinkedBlockingDeque，名為 IdleObjects 的對(duì)象用于維護(hù)空閑對(duì)象隊(duì)列，且是否歸或銷毀的判斷邏輯如下：

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

如果：

• 對(duì)象池已經(jīng)關(guān)閉(只要是程序在運(yùn)行，且正常使用，不會(huì)關(guān)閉）

或

• 配置了 maxIdle 且空閑對(duì)象列表數(shù)量 >=maxIdle

則對(duì)象會(huì)被銷毀，否則對(duì)象會(huì)重新回到 IdleObjects 中。

四、內(nèi)部機(jī)制

Evict(定期驅(qū)逐/保活機(jī)制)

• 周期怎么定？

當(dāng) timeBetweenEvictionRunsMillis 配置 >0 時(shí)，在 GenericObjectPool 所繼承的基類中，會(huì)啟一個(gè)周期性執(zhí)行的線程，它的執(zhí)行周期就是 timeBetweenEvictionRunsMillis 的值。

• 為什么要驅(qū)逐？

當(dāng)空閑對(duì)象過多，對(duì)于客戶端或服務(wù)端的 TCP 連接維護(hù)來講，本身就是一個(gè)開銷，因此，需要有一個(gè)規(guī)則，當(dāng)有一些對(duì)象實(shí)在太空閑了，就把它們踢掉。

• 哪些對(duì)象應(yīng)該被驅(qū)逐？

首先會(huì)從空閑對(duì)象列表中挑選出一部分對(duì)象，而這個(gè)挑選過程本身也有一個(gè)規(guī)則，它受 numTestsPerEvictionRun 參數(shù)控制。

當(dāng) numTestsPerEvictionRun>0，會(huì)挑選出 numTestsPerEvictionRun 數(shù)量的空閑連接進(jìn)行檢查。

當(dāng) numTestsPerEvictionRun<0 時(shí)，首先會(huì)對(duì) numTestsPerEvictionRun 取絕對(duì)值，再然后挑選出空閑數(shù)量 /numTestsPerEvictionRun 絕對(duì)值的數(shù)量進(jìn)行檢查，舉個(gè)例子，如果 numTestsPerEvictinotallow=-2，就會(huì)挑選出一半進(jìn)行檢查。

• 驅(qū)逐檢查怎么做？

本身驅(qū)逐檢查的實(shí)現(xiàn)方式是支持自定義的，也就是 evictionPolicy 參數(shù)，但是往往只會(huì)選擇用默認(rèn)的實(shí)現(xiàn)，也就是 DefaultEvictionPolicy，它的驅(qū)逐檢查策略如下：

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

underTest 為被檢查對(duì)象，當(dāng)存在以下場(chǎng)景時(shí)，滿足驅(qū)逐檢查規(guī)則，會(huì)觸發(fā)驅(qū)逐。

underTest 的空閑時(shí)間 > softMinEvictableIdleTimeMillis 且當(dāng)前空閑對(duì)象數(shù)量 > minIdle 或 underTest 的空閑時(shí)間 > minEvictableIdleTimeMillis。

Tips：有一些好奇的同學(xué)可能會(huì)問，對(duì)象的空閑時(shí)間是怎么算的？

池中的對(duì)象本身會(huì)維護(hù)一個(gè) lastReturnTime 的時(shí)間戳，它會(huì)隨著對(duì)象每一次 returnObject 時(shí)進(jìn)行更新，當(dāng)獲取對(duì)象空閑時(shí)間時(shí)，只要它還是在空閑對(duì)象中，那么用當(dāng)前時(shí)間戳 -lastReturnTime 就是認(rèn)為該對(duì)象的空閑時(shí)間。

• 驅(qū)逐與保活的關(guān)系是怎么樣的？

由于前面提到過，不能配置 testOnBorrow 和 testOnReturn，那么如果 Server 端的鏈接直接斷開了，怎么能保證池中對(duì)象的有效性呢？如果讓調(diào)用端調(diào)用時(shí)再觸發(fā)，會(huì)不會(huì)太晚了呢？這時(shí)候就有個(gè)參數(shù) testWhileIdle，當(dāng)此參數(shù)打開時(shí)，就代表會(huì)在對(duì)象空閑時(shí)進(jìn)行對(duì)象可用性檢查，具體代碼如下：

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

這里隱掉了一些相關(guān)的非核心邏輯，這里可以看到 testWhileIdle 的保活機(jī)制實(shí)際上和 evict 是配套使用的，如果被檢查對(duì)象需要被驅(qū)逐，也就是 evict=true，則會(huì)直接 destory 對(duì)象，否則它會(huì)判定 testWhileIdle 的狀態(tài)，此時(shí)如果 testWhileIdle=true，那么就會(huì)激活一下對(duì)象，具體激活的方式是由使用對(duì)象池的上層工廠所決定的。

Test(檢查機(jī)制)

testOnBorrow、testOnReturn、testOnCreate。

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

testWhileIdle。

該參數(shù)目的是為了對(duì)象在空閑期間可以進(jìn)行檢查，而它的觸發(fā)實(shí)際上是和 evict(定期驅(qū)逐機(jī)制)聯(lián)合起來進(jìn)行使用的。

Abandoned(拋棄機(jī)制)

五、排障方式

本身 GenericObjectPool 默認(rèn)會(huì)把自己的一些參數(shù)通過 JMX 的方式進(jìn)行注冊(cè)，那么我們可以通過 Jvisualvm 進(jìn)行查看，或是通過 Arthas，輸入如下命令：

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

可以獲取到對(duì)象池當(dāng)前的一些屬性，如下圖：

圖片

其中對(duì)于優(yōu)化比較有用的就是 CreatedCount（創(chuàng)建對(duì)象的數(shù)量）、DestoryedCount（對(duì)象銷毀的對(duì)象）、DestoryedByEvictorCount（因?yàn)轵?qū)逐機(jī)制而被銷毀的對(duì)象數(shù)量）。

六、總結(jié)

上述文章以 Jedis 為引，分析了 GenericObjectPool 連接池的底層原理以及 Jedis 是如何使用該連接池的，并且結(jié)合了 Arthas 分享了一個(gè)簡(jiǎn)單的排障方式，實(shí)際上如果知道了 GenericObjectPool 連接池的原理，其他連接池也是大同小異，本文希望拋磚引玉，帶大家對(duì)于連接池的底層實(shí)現(xiàn)有個(gè)基本概念，相信以后遇到此類問題也會(huì)有分析的思路，不再迷茫~