5月iOS設備性能榜：M1 M2依舊是榜單前五
和上個月一樣，沒有新品發布的iOS設備性能榜的上榜設備并沒有什么更替，僅僅只有跑分變化而產生的排名變動，剛剛開始的蘋果WWDC2023，推出的產品也依舊是新款Mac Pro、新款Mac Stu
連接池的用途實際上有過開發經驗的朋友都已經比較清楚了，當資源對象的創建/銷毀比較耗時的場景下，可以通過"池化"技術，達到資源的復用，以此來減少系統的開銷、增大系統吞吐量，比如數據庫連接池、線程池、Redis 連接池等都是使用的該方式，而我們在開發場景中使用較為廣泛的 Jedis 就是使用了 GenericObjectPool 作為它底層的連接池實現。
圖片
業務模塊通過 BorrowObject 方法從空閑連接隊列中獲取空閑連接，最長會等待 maxWaitMillis 毫秒，如果拿不到則走 Create。
把連接重新放回到 IdleObjects 隊列中。
圖片
圖片
而 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
timeBetweenEvictinotallow=30000
numTestsPerEvictinotallow=-1
本文只會針對方法的一些核心鏈路進行說明，如想知道更多細節，針對源碼解析的可以在網上搜索其他相關文章或是到我的參考鏈接里進行翻看。
該方法用于從連接池中獲取一個空閑對象，它有可能是從空閑池中直接獲取的，或是直接創建出來的，如果第一次從空閑對象中沒有獲取到，會走創建后重新獲取，此時如果對象池目前配置的 BlockWhenExhausted=true，那么就會受 maxWaitMillis 參數所配置的超時時間所控制，如果超過了超時時間，都沒拿到一個空閑的對象，則會直接拋出異常。
當獲取到一個對象后，由于對象池中往往存放的是諸如數據庫連接、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 的使用場景與上述 borrowObject 時的 testOnBorrow 是類似的，只是testOnReturn就是一個歸還對象的操作。同理，線上千萬不要配置 testOnReturn=true。
對象池中維護了一個結構為 LinkedBlockingDeque，名為 IdleObjects 的對象用于維護空閑對象隊列，且是否歸或銷毀的判斷邏輯如下：
final int maxIdleSave = getMaxIdle();if (isClosed() || maxIdleSave > -1 && maxIdleSave <= idleObjects.size()) { ...銷毀對象}else{ ...返還至idleObjects}如果：
或
則對象會被銷毀，否則對象會重新回到 IdleObjects 中。
當 timeBetweenEvictionRunsMillis 配置 >0 時，在 GenericObjectPool 所繼承的基類中，會啟一個周期性執行的線程，它的執行周期就是 timeBetweenEvictionRunsMillis 的值。
當空閑對象過多，對于客戶端或服務端的 TCP 連接維護來講，本身就是一個開銷，因此，需要有一個規則，當有一些對象實在太空閑了，就把它們踢掉。
首先會從空閑對象列表中挑選出一部分對象，而這個挑選過程本身也有一個規則，它受 numTestsPerEvictionRun 參數控制。
當 numTestsPerEvictionRun>0，會挑選出 numTestsPerEvictionRun 數量的空閑連接進行檢查。
當 numTestsPerEvictionRun<0 時，首先會對 numTestsPerEvictionRun 取絕對值，再然后挑選出空閑數量 /numTestsPerEvictionRun 絕對值的數量進行檢查，舉個例子，如果 numTestsPerEvictinotallow=-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，那么就會激活一下對象，具體激活的方式是由使用對象池的上層工廠所決定的。
testOnBorrow、testOnReturn、testOnCreate。這幾個基本看名字就知道是什么意思了，在前面講 borrowObject 和 returnObject 的時候也有提到，還有一個相對比較特別的是：
testWhileIdle。
該參數目的是為了對象在空閑期間可以進行檢查，而它的觸發實際上是和 evict(定期驅逐機制)聯合起來進行使用的。
本身 GenericObjectPool 默認會把自己的一些參數通過 JMX 的方式進行注冊，那么我們可以通過 Jvisualvm 進行查看，或是通過 Arthas，輸入如下命令：
mbean org.apache.commons.pool2:type=GenericObjectPool,name=pool-redisConnectionFactory可以獲取到對象池當前的一些屬性，如下圖：
圖片
其中對于優化比較有用的就是 CreatedCount（創建對象的數量）、DestoryedCount（對象銷毀的對象）、DestoryedByEvictorCount（因為驅逐機制而被銷毀的對象數量）。
上述文章以 Jedis 為引，分析了 GenericObjectPool 連接池的底層原理以及 Jedis 是如何使用該連接池的，并且結合了 Arthas 分享了一個簡單的排障方式，實際上如果知道了 GenericObjectPool 連接池的原理，其他連接池也是大同小異，本文希望拋磚引玉，帶大家對于連接池的底層實現有個基本概念，相信以后遇到此類問題也會有分析的思路，不再迷茫~
本文鏈接：http://www.tebozhan.com/showinfo-26-54175-0.htmlJedis連接池究竟是何物
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號