SpringBoot?HikariCP連接池詳解
背景
在我們平常的編碼中，通常會將一些對象保存起來，這主要考慮的是對象的創(chuàng)建成本。
比如像線程資源、數(shù)據(jù)庫連接資源或者 TCP 連接等，這類對象的初始化通常要花費比較長的時間，如果頻繁地申請和銷毀，就會耗費大量的系統(tǒng)資源，造成不必要的性能損失。
并且這些對象都有一個顯著的特征，就是通過輕量級的重置工作，可以循環(huán)、重復地使用。
這個時候，我們就可以使用一個虛擬的池子，將這些資源保存起來，當使用的時候，我們就從池子里快速獲取一個即可。
在 Java 中，池化技術應用非常廣泛，常見的就有數(shù)據(jù)庫連接池、線程池等，本文主講連接池，線程池我們將在后續(xù)的博客中進行介紹。
公用池化包 Commons Pool 2
我們首先來看一下 Java 中公用的池化包 Commons Pool 2，來了解一下對象池的一般結構。
根據(jù)我們的業(yè)務需求，使用這套 API 能夠很容易實現(xiàn)對象的池化管理。
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
<version>2.11.1</version>
</dependency>GenericObjectPool 是對象池的核心類，通過傳入一個對象池的配置和一個對象的工廠，即可快速創(chuàng)建對象池。
public GenericObjectPool(
final PooledObjectFactory<T> factory,
final GenericObjectPoolConfig<T> config)案例
Redis 的常用客戶端 Jedis，就是使用 Commons Pool 管理連接池的，可以說是一個最佳實踐。下圖是 Jedis 使用工廠創(chuàng)建對象的主要代碼塊。
對象工廠類最主要的方法就是makeObject，它的返回值是 PooledObject 類型，可以將對象使用 new DefaultPooledObject<>(obj) 進行簡單包裝返回。
redis.clients.jedis.JedisFactory，使用工廠創(chuàng)建對象。
@Override
public PooledObject<Jedis> makeObject() throws Exception {
Jedis jedis = null;
try {
jedis = new Jedis(jedisSocketFactory, clientConfig);
//主要的耗時操作
jedis.connect();
//返回包裝對象
return new DefaultPooledObject<>(jedis);
} catch (JedisException je) {
if (jedis != null) {
try {
jedis.quit();
} catch (RuntimeException e) {
logger.warn("Error while QUIT", e);
}
try {
jedis.close();
} catch (RuntimeException e) {
logger.warn("Error while close", e);
}
}
throw je;
}
}我們再來介紹一下對象的生成過程，如下圖，對象在進行獲取時，將首先嘗試從對象池里拿出一個，如果對象池中沒有空閑的對象，就使用工廠類提供的方法，生成一個新的。
public T borrowObject(final Duration borrowMaxWaitDuration) throws Exception {
//此處省略若干行
while (p == null) {
create = false;
//首先嘗試從池子中獲取。
p = idleObjects.pollFirst();
// 池子里獲取不到，才調用工廠內生成新實例
if (p == null) {
p = create();
if (p != null) {
create = true;
}
}
//此處省略若干行
}
//此處省略若干行
}那對象是存在什么地方的呢？這個存儲的職責，就是由一個叫作LinkedBlockingDeque 的結構來承擔的，它是一個雙向的隊列。
接下來看一下 GenericObjectPoolConfig 的主要屬性：
// GenericObjectPoolConfig本身的屬性 private int maxTotal = DEFAULT_MAX_TOTAL; private int maxIdle = DEFAULT_MAX_IDLE; private int minIdle = DEFAULT_MIN_IDLE; // 其父類BaseObjectPoolConfig的屬性 private boolean lifo = DEFAULT_LIFO; private boolean fairness = DEFAULT_FAIRNESS; private long maxWaitMillis = DEFAULT_MAX_WAIT_MILLIS; private long minEvictableIdleTimeMillis = DEFAULT_MIN_EVICTABLE_IDLE_TIME_MILLIS; private long evictorShutdownTimeoutMillis = DEFAULT_EVICTOR_SHUTDOWN_TIMEOUT_MILLIS; private long softMinEvictableIdleTimeMillis = DEFAULT_SOFT_MIN_EVICTABLE_IDLE_TIME_MILLIS; private int numTestsPerEvictionRun = DEFAULT_NUM_TESTS_PER_EVICTION_RUN; private EvictionPolicy<T> evictionPolicy = null; // Only 2.6.0 applications set this private String evictionPolicyClassName = DEFAULT_EVICTION_POLICY_CLASS_NAME; private boolean testOnCreate = DEFAULT_TEST_ON_CREATE; private boolean testOnBorrow = DEFAULT_TEST_ON_BORROW; private boolean testOnReturn = DEFAULT_TEST_ON_RETURN; private boolean testWhileIdle = DEFAULT_TEST_WHILE_IDLE; private long timeBetweenEvictionRunsMillis = DEFAULT_TIME_BETWEEN_EVICTION_RUNS_MILLIS; private boolean blockWhenExhausted = DEFAULT_BLOCK_WHEN_EXHAUSTED;
參數(shù)很多，要想了解參數(shù)的意義，我們首先來看一下一個池化對象在整個池子中的生命周期。
如下圖所示，池子的操作主要有兩個：一個是業(yè)務線程，一個是檢測線程。
對象池在進行初始化時，要指定三個主要的參數(shù)：
- maxTotal 對象池中管理的對象上限
- maxIdle 最大空閑數(shù)
- minIdle 最小空閑數(shù)
其中 maxTotal 和業(yè)務線程有關，當業(yè)務線程想要獲取對象時，會首先檢測是否有空閑的對象。
如果有，則返回一個；否則進入創(chuàng)建邏輯。此時，如果池中個數(shù)已經(jīng)達到了最大值，就會創(chuàng)建失敗，返回空對象。
對象在獲取的時候，有一個非常重要的參數(shù)，那就是最大等待時間（maxWaitMillis），這個參數(shù)對應用方的性能影響是比較大的。該參數(shù)默認為 -1，表示永不超時，直到有對象空閑。
如下圖，如果對象創(chuàng)建非常緩慢或者使用非常繁忙，業(yè)務線程會持續(xù)阻塞 （blockWhenExhausted 默認為 true），進而導致正常服務也不能運行。
面試題
一般面試官會問：你會把超時參數(shù)設置成多大呢？我一般都會把最大等待時間，設置成接口可以忍受的最大延遲。
比如，一個正常服務響應時間 10ms 左右，達到 1 秒鐘就會感覺到卡頓，那么這個參數(shù)設置成 500~1000ms 都是可以的。
超時之后，會拋出 NoSuchElementException 異常，請求會快速失敗，不會影響其他業(yè)務線程，這種 Fail Fast 的思想，在互聯(lián)網(wǎng)應用非常廣泛。
帶有 evcit 字樣的參數(shù)，主要是處理對象逐出的。池化對象除了初始化和銷毀的時候比較昂貴，在運行時也會占用系統(tǒng)資源。
比如，連接池會占用多條連接，線程池會增加調度開銷等。業(yè)務在突發(fā)流量下，會申請到超出正常情況的對象資源，放在池子中。等這些對象不再被使用，我們就需要把它清理掉。
超出 minEvictableIdleTimeMillis 參數(shù)指定值的對象，就會被強制回收掉，這個值默認是 30 分鐘；softMinEvictableIdleTimeMillis 參數(shù)類似，但它只有在當前對象數(shù)量大于 minIdle 的時候才會執(zhí)行移除，所以前者的動作要更暴力一些。
還有 4 個 test 參數(shù)：testOnCreate、testOnBorrow、testOnReturn、testWhileIdle，分別指定了在創(chuàng)建、獲取、歸還、空閑檢測的時候，是否對池化對象進行有效性檢測。
開啟這些檢測，能保證資源的有效性，但它會耗費性能，所以默認為 false。
生產(chǎn)環(huán)境上，建議只將 testWhileIdle 設置為 true，并通過調整空閑檢測時間間隔（timeBetweenEvictionRunsMillis），比如 1 分鐘，來保證資源的可用性，同時也保證效率。
JMH 測試
使用連接池和不使用連接池，它們之間的性能差距到底有多大呢？
下面是一個簡單的 JMH 測試例子（見倉庫），進行一個簡單的 set 操作，為 redis 的 key 設置一個隨機值。
@Fork(2)
@State(Scope.Benchmark)
@Warmup(iterations = 5, time = 1)
@Measurement(iterations = 5, time = 1)
@BenchmarkMode(Mode.Throughput)
public class JedisPoolVSJedisBenchmark {
JedisPool pool = new JedisPool("localhost", 6379); @Benchmarkpublicvoid testPool() {
Jedis jedis = pool.getResource(); jedis.set("a", UUID.randomUUID().toString());
jedis.close();
}
@Benchmarkpublicvoid testJedis() {
Jedis jedis = new Jedis("localhost",6379);
jedis.set("a", UUID.randomUUID().toString());
jedis.close();
}//此處省略若干行}將測試結果使用 meta-chart 作圖，展示結果如下圖所示，可以看到使用了連接池的方式，它的吞吐量是未使用連接池方式的 5 倍！
數(shù)據(jù)庫連接池 HikariCP
HikariCP 源于日語“光る”，光的意思，寓意軟件工作速度和光速一樣快，它是 SpringBoot 中默認的數(shù)據(jù)庫連接池。
數(shù)據(jù)庫是我們工作中經(jīng)常使用到的組件，針對數(shù)據(jù)庫設計的客戶端連接池是非常多的，它的設計原理與我們在本文開頭提到的基本一致，可以有效地減少數(shù)據(jù)庫連接創(chuàng)建、銷毀的資源消耗。
同是連接池，它們的性能也是有差別的，下圖是 HikariCP 官方的一張測試圖，可以看到它優(yōu)異的性能，官方的 JMH 測試代碼見 Github。
一般面試題是這么問的：HikariCP 為什么快呢？
主要有三個方面：
- 它使用 FastList 替代 ArrayList，通過初始化的默認值，減少了越界檢查的操作
- 優(yōu)化并精簡了字節(jié)碼，通過使用 Javassist，減少了動態(tài)代理的性能損耗，比如使用 invokestatic 指令代替 invokevirtual 指令
- 實現(xiàn)了無鎖的 ConcurrentBag，減少了并發(fā)場景下的鎖競爭
HikariCP 對性能的一些優(yōu)化操作，是非常值得我們借鑒的，在之后的博客中，我們將詳細分析幾個優(yōu)化場景。
數(shù)據(jù)庫連接池同樣面臨一個最大值（maximumPoolSize）和最小值（minimumIdle）的問題。這里同樣有一個非常高頻的面試題：你平常會把連接池設置成多大呢？
很多同學認為，連接池的大小設置得越大越好，有的同學甚至把這個值設置成 1000 以上，這是一種誤解。
根據(jù)經(jīng)驗，數(shù)據(jù)庫連接，只需要 20~50 個就夠用了。具體的大小，要根據(jù)業(yè)務屬性進行調整，但大得離譜肯定是不合適的。
HikariCP 官方是不推薦設置 minimumIdle 這個值的，它將被默認設置成和 maximumPoolSize 一樣的大小。如果你的數(shù)據(jù)庫Server端連接資源空閑較大，不妨也可以去掉連接池的動態(tài)調整功能。
另外，根據(jù)數(shù)據(jù)庫查詢和事務類型，一個應用中是可以配置多個數(shù)據(jù)庫連接池的，這個優(yōu)化技巧很少有人知道，在此簡要描述一下。
業(yè)務類型通常有兩種：一種需要快速的響應時間，把數(shù)據(jù)盡快返回給用戶；另外一種是可以在后臺慢慢執(zhí)行，耗時比較長，對時效性要求不高。
如果這兩種業(yè)務類型，共用一個數(shù)據(jù)庫連接池，就容易發(fā)生資源爭搶，進而影響接口響應速度。
雖然微服務能夠解決這種情況，但大多數(shù)服務是沒有這種條件的，這時就可以對連接池進行拆分。
如圖，在同一個業(yè)務中，根據(jù)業(yè)務的屬性，我們分了兩個連接池，就是來處理這種情況的。
HikariCP 還提到了另外一個知識點，在 JDBC4 的協(xié)議中，通過 Connection.isValid() 就可以檢測連接的有效性。
這樣，我們就不用設置一大堆的 test 參數(shù)了，HikariCP 也沒有提供這樣的參數(shù)。
結果緩存池
到了這里你可能會發(fā)現(xiàn)池（Pool）與緩存（Cache）有許多相似之處。
它們之間的一個共同點，就是將對象加工后，存儲在相對高速的區(qū)域。我習慣性將緩存看作是數(shù)據(jù)對象，而把池中的對象看作是執(zhí)行對象。緩存中的數(shù)據(jù)有一個命中率問題，而池中的對象一般都是對等的。
考慮下面一個場景，jsp 提供了網(wǎng)頁的動態(tài)功能，它可以在執(zhí)行后，編譯成 class 文件，加快執(zhí)行速度；再或者，一些媒體平臺，會將熱門文章，定時轉化成靜態(tài)的 html 頁面，僅靠 nginx 的負載均衡即可應對高并發(fā)請求（動靜分離）。
這些時候，你很難說清楚，這是針對緩存的優(yōu)化，還是針對對象進行了池化，它們在本質上只是保存了某個執(zhí)行步驟的結果，使得下次訪問時不需要從頭再來。
我通常把這種技術叫作結果緩存池（Result Cache Pool），屬于多種優(yōu)化手段的綜合。
小結
下面我來簡單總結一下本文的內容重點：我們從 Java 中最通用的公用池化包 Commons Pool 2 說起，介紹了它的一些實現(xiàn)細節(jié)，并對一些重要參數(shù)的應用做了講解。
Jedis 就是在 Commons Pool 2 的基礎上封裝的，通過 JMH 測試，我們發(fā)現(xiàn)對象池化之后，有了接近 5 倍的性能提升。
接下來介紹了數(shù)據(jù)庫連接池中速度很快的 HikariCP ，它在池化技術之上，又通過編碼技巧進行了進一步的性能提升，HikariCP 是我重點研究的類庫之一，我也建議你加入自己的任務清單中。
總體來說，當你遇到下面的場景，就可以考慮使用池化來增加系統(tǒng)性能：
- 對象的創(chuàng)建或者銷毀，需要耗費較多的系統(tǒng)資源
- 對象的創(chuàng)建或者銷毀，耗時長，需要繁雜的操作和較長時間的等待
- 對象創(chuàng)建后，通過一些狀態(tài)重置，可被反復使用
將對象池化之后，只是開啟了第一步優(yōu)化。要想達到最優(yōu)性能，就不得不調整池的一些關鍵參數(shù)，合理的池大小加上合理的超時時間，就可以讓池發(fā)揮更大的價值。和緩存的命中率類似，對池的監(jiān)控也是非常重要的。
如下圖，可以看到數(shù)據(jù)庫連接池連接數(shù)長時間保持在高位不釋放，同時等待的線程數(shù)急劇增加，這就能幫我們快速定位到數(shù)據(jù)庫的事務問題。
平常的編碼中，有很多類似的場景。比如 Http 連接池，Okhttp 和 Httpclient 就都提供了連接池的概念，你可以類比著去分析一下，關注點也是在連接大小和超時時間上。
在底層的中間件，比如 RPC，也通常使用連接池技術加速資源獲取，比如 Dubbo 連接池、 Feign 切換成 httppclient 的實現(xiàn)等技術。
你會發(fā)現(xiàn)，在不同資源層面的池化設計也是類似的。比如線程池，通過隊列對任務進行了二層緩沖，提供了多樣的拒絕策略等，線程池我們將在后續(xù)的文章中進行介紹。
線程池的這些特性，你同樣可以借鑒到連接池技術中，用來緩解請求溢出，創(chuàng)建一些溢出策略。
現(xiàn)實情況中，我們也會這么做。那么具體怎么做？有哪些做法？這部分內容就留給大家思考了。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.12.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.ykq</groupId>
<artifactId>qy151-springboot-vue</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>qy151-springboot-vue</name>
<description>Demo project for Spring Boot</description>
<properties>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-generator</artifactId>
<version>3.5.2</version>
</dependency>
<dependency>
<groupId>org.freemarker</groupId>
<artifactId>freemarker</artifactId>
<version>2.3.31</version>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.2</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid-spring-boot-starter</artifactId>
<version>1.2.8</version>
</dependency>
<dependency>
<groupId>com.github.xiaoymin</groupId>
<artifactId>swagger-bootstrap-ui</artifactId>
<version>1.9.6</version>
</dependency>
<dependency>
<groupId>com.spring4all</groupId>
<artifactId>swagger-spring-boot-starter</artifactId>
<version>1.9.1.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>2.2.2</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</project>到此這篇關于SpringBoot HikariCP連接池詳解的文章就介紹到這了,更多相關SpringBoot HikariCP內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
Spring Quartz 是一個任務調度框架,它允許我們定期執(zhí)行特定的任務,在 Spring 中,我們可以通過多種方式來配置 Quartz,包括使用 ??@Scheduled?? 注解、XML 配置和 Java 配置,本文將介紹如何在 Spring 中使用這三種方式來配置 Quartz,需要的朋友可以參考下2025-01-01
SpringMVC使用ResponseEntity實現(xiàn)文件上傳下載
這篇文章主要為大家介紹了SpringMVC使用ResponseEntity實現(xiàn)文件上傳下載，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-05-05
java鏈式創(chuàng)建json對象的實現(xiàn)
本文主要介紹了java中如何通過最簡單的方式實現(xiàn)鏈式創(chuàng)建json對象，解決創(chuàng)建json代碼臃腫的問題，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-02-02
這篇文章主要介紹了Java實現(xiàn)的RSA加密解密算法,結合實例形式分析了java RAS加密解密算法的相關實現(xiàn)技巧,需要的朋友可以參考下2018-01-01
這篇文章主要介紹了Spring?Security的內置過濾器是如何維護的,本文給我們分析一下HttpSecurity維護過濾器的幾個方法，需要的朋友可以參考下2022-02-02
今天小編就為大家分享一篇關于基于Java語言實現(xiàn)Socket通信的實例，小編覺得內容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧2019-01-01
這篇文章主要給大家介紹了關于JAVA實現(xiàn)深拷貝的幾種方式,在Java中深拷貝和淺拷貝是用來復制對象的兩種不同方式,深拷貝會對所有數(shù)據(jù)類型進行拷貝,包括對象所包含的內部對象,需要的朋友可以參考下2023-09-09
這篇文章主要給大家深入的介紹了關于Spring Boot屬性配置文件的相關資料，文中介紹的很詳細，相信對大家具有一定的參考借鑒價值，需要的朋友們下面來一起看看吧。2017-02-02
這篇文章主要介紹了java 自定義注解的實例詳解的相關資料,需要的朋友可以參考下2017-09-09
布隆過濾器是可以用于判斷一個元素是不是在一個集合里,并且相比于其它的數(shù)據(jù)結構,布隆過濾器在空間和時間方面都有巨大的優(yōu)勢。下面這篇文章主要給大家介紹了關于Java實現(xiàn)布隆過濾器的相關資料，需要的朋友可以參考下2018-11-11