7月安卓手機(jī)好評榜：三星S23Ultra好評率第一
性能榜和性價(jià)比榜之后，我們來看最后的安卓手機(jī)好評榜，數(shù)據(jù)來源安兔兔評測，收集時(shí)間2023年7月1日至7月31日，僅限國內(nèi)市場。第一名：三星Galaxy S23 Ultra好評率：95.71%在即將迎來新
連接池的用途實(shí)際上有過開發(fā)經(jīng)驗(yàn)的朋友都已經(jīng)比較清楚了，當(dāng)資源對象的創(chuàng)建/銷毀比較耗時(shí)的場景下，可以通過"池化"技術(shù)，達(dá)到資源的復(fù)用，以此來減少系統(tǒng)的開銷、增大系統(tǒng)吞吐量，比如數(shù)據(jù)庫連接池、線程池、Redis 連接池等都是使用的該方式，而我們在開發(fā)場景中使用較為廣泛的 Jedis 就是使用了 GenericObjectPool 作為它底層的連接池實(shí)現(xiàn)。
圖片
業(yè)務(wù)模塊通過 BorrowObject 方法從空閑連接隊(duì)列中獲取空閑連接，最長會(huì)等待 maxWaitMillis 毫秒，如果拿不到則走 Create。
把連接重新放回到 IdleObjects 隊(duì)列中。
圖片
圖片
而 RedisConnectionFactory 的其中一個(gè)實(shí)現(xiàn)就是 JedisConnectionFactory，其中就包含了 Pool。
圖片
而 Pool 本身內(nèi)部就能看到我們真正的主角。
圖片
捋一下其中的關(guān)系，我們常用的 Spring-Data-Redis 的 Jedis 實(shí)現(xiàn)最終是通過以下的層級結(jié)構(gòu)來使用 GenericObjectPool 的。
圖片
如上述類結(jié)構(gòu)所示，GenericObjectPool 都是在 GenericObjectPoolConfig 或 BaseObjectPoolConfig 中進(jìn)行配置相關(guān)參數(shù)的，其中核心參數(shù)以及默認(rèn)值如下：
圖片
上圖對這些參數(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ì)針對方法的一些核心鏈路進(jìn)行說明，如想知道更多細(xì)節(jié)，針對源碼解析的可以在網(wǎng)上搜索其他相關(guān)文章或是到我的參考鏈接里進(jìn)行翻看。
該方法用于從連接池中獲取一個(gè)空閑對象，它有可能是從空閑池中直接獲取的，或是直接創(chuàng)建出來的，如果第一次從空閑對象中沒有獲取到，會(huì)走創(chuàng)建后重新獲取，此時(shí)如果對象池目前配置的 BlockWhenExhausted=true，那么就會(huì)受 maxWaitMillis 參數(shù)所配置的超時(shí)時(shí)間所控制，如果超過了超時(shí)時(shí)間，都沒拿到一個(gè)空閑的對象，則會(huì)直接拋出異常。
當(dāng)獲取到一個(gè)對象后，由于對象池中往往存放的是諸如數(shù)據(jù)庫連接、Redis 連接等創(chuàng)建時(shí)較為耗時(shí)的資源，但是因?yàn)檫B接本身是復(fù)用的，如果 MySQL/Redis Server 端如果因?yàn)槟承┰驍嚅_/釋放了該鏈接，那么此時(shí)拿到的對象就是個(gè)無效的對象，因此在 borrowObject 階段會(huì)判定，如果：
testOnBorrow=true || (create && testOnCreate=true)就會(huì)走到：
factory.validateObject這里如何進(jìn)行 validateObject 的，是由上層使用對象池的場景所決定的，比如在 Jedis 場景中，會(huì)向 Redis Server 發(fā)送一個(gè) Ping 命令，如果 Server 返回了 Pong，則認(rèn)為該連接仍然有效，可以給業(yè)務(wù)層使用。
但是！！！！！！
線上環(huán)境千萬不要配置 testOnBorrow=true 或是 testOnCreate=true。
每個(gè)對象的獲取都需要先校驗(yàn)再拿，會(huì)大大增加單次請求的 RT。
ReturnObject
實(shí)際上 testOnReturn 的使用場景與上述 borrowObject 時(shí)的 testOnBorrow 是類似的，只是testOnReturn就是一個(gè)歸還對象的操作。同理，線上千萬不要配置 testOnReturn=true。
對象池中維護(hù)了一個(gè)結(jié)構(gòu)為 LinkedBlockingDeque，名為 IdleObjects 的對象用于維護(hù)空閑對象隊(duì)列，且是否歸或銷毀的判斷邏輯如下：
final int maxIdleSave = getMaxIdle();if (isClosed() || maxIdleSave > -1 && maxIdleSave <= idleObjects.size()) { ...銷毀對象}else{ ...返還至idleObjects}如果：
或
則對象會(huì)被銷毀，否則對象會(huì)重新回到 IdleObjects 中。
當(dāng) timeBetweenEvictionRunsMillis 配置 >0 時(shí)，在 GenericObjectPool 所繼承的基類中，會(huì)啟一個(gè)周期性執(zhí)行的線程，它的執(zhí)行周期就是 timeBetweenEvictionRunsMillis 的值。
當(dāng)空閑對象過多，對于客戶端或服務(wù)端的 TCP 連接維護(hù)來講，本身就是一個(gè)開銷，因此，需要有一個(gè)規(guī)則，當(dāng)有一些對象實(shí)在太空閑了，就把它們踢掉。
首先會(huì)從空閑對象列表中挑選出一部分對象，而這個(gè)挑選過程本身也有一個(gè)規(guī)則，它受 numTestsPerEvictionRun 參數(shù)控制。
當(dāng) numTestsPerEvictionRun>0，會(huì)挑選出 numTestsPerEvictionRun 數(shù)量的空閑連接進(jìn)行檢查。
當(dāng) numTestsPerEvictionRun<0 時(shí)，首先會(huì)對 numTestsPerEvictionRun 取絕對值，再然后挑選出空閑數(shù)量 /numTestsPerEvictionRun 絕對值的數(shù)量進(jìn)行檢查，舉個(gè)例子，如果 numTestsPerEvictinotallow=-2，就會(huì)挑選出一半進(jìn)行檢查。
本身驅(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 為被檢查對象，當(dāng)存在以下場景時(shí)，滿足驅(qū)逐檢查規(guī)則，會(huì)觸發(fā)驅(qū)逐。
underTest 的空閑時(shí)間 > softMinEvictableIdleTimeMillis 且當(dāng)前空閑對象數(shù)量 > minIdle 或 underTest 的空閑時(shí)間 > minEvictableIdleTimeMillis。
Tips：有一些好奇的同學(xué)可能會(huì)問，對象的空閑時(shí)間是怎么算的？
池中的對象本身會(huì)維護(hù)一個(gè) lastReturnTime 的時(shí)間戳，它會(huì)隨著對象每一次 returnObject 時(shí)進(jìn)行更新，當(dāng)獲取對象空閑時(shí)間時(shí)，只要它還是在空閑對象中，那么用當(dāng)前時(shí)間戳 -lastReturnTime 就是認(rèn)為該對象的空閑時(shí)間。
由于前面提到過，不能配置 testOnBorrow 和 testOnReturn，那么如果 Server 端的鏈接直接斷開了，怎么能保證池中對象的有效性呢？如果讓調(diào)用端調(diào)用時(shí)再觸發(fā)，會(huì)不會(huì)太晚了呢？這時(shí)候就有個(gè)參數(shù) testWhileIdle，當(dāng)此參數(shù)打開時(shí)，就代表會(huì)在對象空閑時(shí)進(jìn)行對象可用性檢查，具體代碼如下：
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 是配套使用的，如果被檢查對象需要被驅(qū)逐，也就是 evict=true，則會(huì)直接 destory 對象，否則它會(huì)判定 testWhileIdle 的狀態(tài)，此時(shí)如果 testWhileIdle=true，那么就會(huì)激活一下對象，具體激活的方式是由使用對象池的上層工廠所決定的。
testOnBorrow、testOnReturn、testOnCreate。這幾個(gè)基本看名字就知道是什么意思了，在前面講 borrowObject 和 returnObject 的時(shí)候也有提到，還有一個(gè)相對比較特別的是：
testWhileIdle。
該參數(shù)目的是為了對象在空閑期間可以進(jìn)行檢查，而它的觸發(fā)實(shí)際上是和 evict(定期驅(qū)逐機(jī)制)聯(lián)合起來進(jìn)行使用的。
本身 GenericObjectPool 默認(rèn)會(huì)把自己的一些參數(shù)通過 JMX 的方式進(jìn)行注冊，那么我們可以通過 Jvisualvm 進(jìn)行查看，或是通過 Arthas，輸入如下命令：
mbean org.apache.commons.pool2:type=GenericObjectPool,name=pool-redisConnectionFactory可以獲取到對象池當(dāng)前的一些屬性，如下圖：
圖片
其中對于優(yōu)化比較有用的就是 CreatedCount（創(chuàng)建對象的數(shù)量）、DestoryedCount（對象銷毀的對象）、DestoryedByEvictorCount（因?yàn)轵?qū)逐機(jī)制而被銷毀的對象數(shù)量）。
上述文章以 Jedis 為引，分析了 GenericObjectPool 連接池的底層原理以及 Jedis 是如何使用該連接池的，并且結(jié)合了 Arthas 分享了一個(gè)簡單的排障方式，實(shí)際上如果知道了 GenericObjectPool 連接池的原理，其他連接池也是大同小異，本文希望拋磚引玉，帶大家對于連接池的底層實(shí)現(xiàn)有個(gè)基本概念，相信以后遇到此類問題也會(huì)有分析的思路，不再迷茫~
本文鏈接：http://www.www897cc.com/showinfo-26-54175-0.htmlJedis連接池究竟是何物
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號