公開2025.05.01更新2026.10.15 43 人が閲覧（直近 30 日） Java

HikariCPとは？既定値一覧とSpring Bootでの設定・タイムアウト対処【7.1.0】

Q: HikariCPのデフォルト値は？

主な値は、 maximumPoolSize 10、 minimumIdle は maximumPoolSize と同じ、 connectionTimeout 30秒、 idleTimeout 10分、 maxLifetime 30分、 keepaliveTime 2分、 validationTimeout 5秒、 leakDetectionThreshold 0（無効）です。7.1.0で読み出した一覧と下限は上の表のとおりです。

Q: HikariDataSourceとは何ですか？

HikariCPが提供する javax.sql.DataSource の実装クラスです。アプリはこのクラスの getConnection() でプールから接続を借ります。

Q: spring.datasource.hikari.maximum-pool-sizeの既定値はいくつですか？

10です。 minimum-idle を指定しなければ同じ10本の維持を目指す固定サイズのプールになります。ただし、起動直後や接続の交換中、DB障害時には不足する場合があります。

HikariCPとは？既定値一覧とSpring Bootでの設定・タイムアウト対処【7.1.0】

HikariCP（ヒカリCP）は、Javaアプリケーションとデータベースの間でJDBC接続を使い回すためのコネクションプールです。Spring Bootで spring-boot-starter-jdbc や spring-boot-starter-data-jpa を使っていれば、設定しなくてもHikariCPが動いています。この記事では最新の7.1.0を実際に起動して確かめた既定値と下限、spring.datasource.hikari.* の書き方、本番で出やすい「Connection is not available」の読み方までを順に説明します。

まとめ：HikariCPで押さえる要点

HikariCPはBrett Wooldridge氏が開発するApache License 2.0のJDBCコネクションプールで、座標は com.zaxxer:HikariCP。最新は7.1.0（2026年6月14日公開、Java 11以上）。
Spring Bootの接続プール自動選択では、別の型や独自DataSourceを指定していなければHikariCPが優先される。Boot 4.1.1が管理する版は7.0.2で、7.1.0ではない。
既定はプール最大10本の固定サイズ。connectionTimeout 30秒、maxLifetime 30分、keepaliveTime 2分、リーク検出は無効。
maxLifetime はDBやロードバランサーが接続を切る時間より数秒短くする。0以外で30秒未満を指定すると既定の30分へ戻される。0は最大寿命による回収を無効にする。
「Connection is not available」が出たら、プール増量の前に接続の返し忘れ、長時間の借用、DBへの接続失敗を調べる。total=0 で原因例外（cause）が付いていればDB側に接続できていない。total が正で active と同じなら既存接続がすべて使用中で、leakDetectionThreshold のスタックトレースで握っている箇所を特定する。

以下、仕組み、版、設定値、Spring Boot、サイズ設計、障害対応、監視の順に説明します。

HikariCPの仕組みとSpring Bootが既定で採用する理由

DBへの接続を毎回開くと、TCP接続、認証、セッション初期化の処理が発生し、その所要時間はネットワークやDBの構成によって変わります。コネクションプールはあらかじめ開いた接続を保持しておき、アプリが getConnection() を呼ぶと空いている接続を貸し出し、close() で実際には切断せずプールへ戻します。HikariCPのjarは約170KBと小さく、名前は日本語の「光」に由来します。

Spring Bootの公式リファレンス（SQL Databases）は接続プールの選択順を「HikariCP、Tomcat JDBC、Commons DBCP2、Oracle UCP」と定めており、HikariCPについて「If HikariCP is available, we always choose it.」と書いています。既定のプールがTomcat JDBCからHikariCPへ切り替わったのはSpring Boot 2.0で、starterが依存に含めるため、Spring BootアプリのDataSourceは特に指定しない限りHikariCPです。別のプールを使いたいときは spring.datasource.type で明示します。

HikariConfig・HikariDataSource・HikariPoolの役割分担

検索で名前が出てくる3つのクラスは役割が異なります。

HikariConfig：JDBC URLやプールサイズなどの設定を保持するクラス。
HikariDataSource：アプリが実際に使う javax.sql.DataSource の実装。HikariConfig を継承しており、Spring Bootが作るDataSource Beanの型はこれ。
HikariPool：接続の貸し出し、補充、寿命管理を担う内部クラス。ログの「HikariPool-1」はこのプールの名前で、poolName を付けなければ HikariPool-1 から連番になる（「Start completed.」の行自体を出力するのは HikariDataSource）。

ログから複数のプールを見分けるには、poolName（Spring Bootでは spring.datasource.hikari.pool-name）を付けておくと原因調査が速くなります。

HikariCPが速い理由：ConcurrentBagによる接続の貸し出し

速さの中心は、接続の出し入れを担う com.zaxxer.hikari.util.ConcurrentBag です。7.1.0のソースでは、borrow() が次の順で空き接続を探します。

そのスレッドが最近返した接続のリスト（スレッドローカル・最大16件）を後ろから見る。
全接続を持つ共有リスト（CopyOnWriteArrayList）を先頭から走査し、空いている接続の状態をCAS（比較して交換）で「使用中」に切り替える。
空きがなければ接続の追加を依頼し、SynchronousQueue で他スレッドからの手渡しを connectionTimeout まで待つ。

接続を返すスレッドは、状態を未使用に戻し、待機スレッドへの手渡しを試みます。借用中も接続のエントリは共有リストに残っています。ロックで全体を守る方式と違い、通常の貸し出しはCAS1回で終わります。7.1.0で変わったのはこの手渡しの待ち方で、仮想スレッドでは Thread.yield() の代わりに10マイクロ秒の parkNanos で待つようになりました。

周辺の処理も削っています。接続ごとに開いたStatementを記録する FastList は範囲チェックを省き、削除時は末尾から探します（直近に開いたStatementから閉じることが多いため）。Connection や PreparedStatement を包むプロキシは、ビルド時にJavassistで生成された HikariProxyConnection などのクラスとしてjarに同梱されています。

HikariCPのバージョンとJava要件

Maven Centralで2026年10月時点に確認した主な版は次のとおりです。

版	公開日	Java	主な採用先
7.1.0	2026-06-14	11以上	最新。Spring Boot 4.2.0-M1・M2（マイルストーン）の管理版
7.0.2	2025-08-19	11以上	Spring Boot 4.1.1の管理版
6.3.3	2025-09-12	11以上	Spring Boot 3.5.16の管理版
4.0.3	–	8	Java 8向け最終（非推奨）
2.4.13	–	7	artifactIdは HikariCP-java7（非推奨）

7.1.0の変更点は1件で、仮想スレッドが接続を返すときに Thread.yield() で空回りしていた処理を短い待機に置き換えたものです。修正したプルリクエスト（#2402）の計測は、JDK 25.0.3で仮想スレッド2,000本がConcurrentBagの50個のエントリを借用・返却するDB処理を含まない負荷試験で、借用回数が7.0.2の毎秒約666万回から約1,163万回へ増えています。Spring Bootで spring.threads.virtual.enabled=true を使い、接続の奪い合いが起きている環境なら、負荷試験と互換性確認を行ったうえで7.1.0への更新を検討できます。Mavenでspring-boot-starter-parentを継承していれば hikaricp.version で上書きでき、BOMのimportだけの場合は依存管理で明示的に上書きします。Spring Boot本体の版とサポート期限はSpring Bootのバージョン一覧で確認できます。

<dependency>
  <groupId>com.zaxxer</groupId>
  <artifactId>HikariCP</artifactId>
  <version>7.1.0</version>
</dependency>

素のJavaでHikariCPを使う最小構成

以下はメソッド内に置くJavaコード断片です。HikariCPに加えてPostgreSQL JDBCドライバを依存に追加し、com.zaxxer.hikariとjava.sqlの使用クラスをimportします。接続先とDB_PASSWORDを用意し、HikariConfig に接続情報を入れて HikariDataSource を作ります。プールはアプリ終了時に close() し、借りた接続はtry-with-resourcesで必ず返します。

HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:postgresql://db.example.local:5432/app");
config.setUsername("app");
config.setPassword(System.getenv("DB_PASSWORD"));
config.setPoolName("app-pool");
config.setMaximumPoolSize(10);

try (HikariDataSource ds = new HikariDataSource(config);
     Connection conn = ds.getConnection();
     PreparedStatement ps = conn.prepareStatement("select 1");
     ResultSet rs = ps.executeQuery()) {
  rs.next();
}

new HikariDataSource(config) の時点で最初の1本の接続が作られ、残りはバックグラウンドのスレッドが minimumIdle まで補充します。DEBUGログでは「Added connection conn0」の直後に「p3:connection-adder」スレッドが2本目を追加する様子が確認できます。

主要パラメータの既定値と下限（7.1.0で実測）

HikariCP 7.1.0をJDK 25で起動し、HikariConfig の既定値を読み出した結果と、READMEの設定項目一覧に記載された下限を並べます。Spring Bootでは左から2列目のキー名で指定します。表の下限には0の特別値を含めていません。

プロパティ	Spring Bootのキー	既定値	下限
maximumPoolSize	maximum-pool-size	10	1
minimumIdle	minimum-idle	maximumPoolSizeと同じ	0
connectionTimeout	connection-timeout	30000ms	250ms
idleTimeout	idle-timeout	600000ms	10000ms
maxLifetime	max-lifetime	1800000ms	30000ms
keepaliveTime	keepalive-time	120000ms	30000ms
validationTimeout	validation-timeout	5000ms	250ms
leakDetectionThreshold	leak-detection-threshold	0（無効）	2000ms
initializationFailTimeout	initialization-fail-timeout	1	–
autoCommit	auto-commit	true	–

下限を下回る値の扱いは項目ごとに違います。connectionTimeout は0を除く250ms未満、validationTimeout は250ms未満、maximumPoolSize は1未満、minimumIdle は負の値で IllegalArgumentException になり起動しません（例：「connectionTimeout cannot be less than 250ms」）。idleTimeout も負の値は例外です。一方で maxLifetime は0以外で30秒未満なら、警告を出して既定値へ戻ります。idleTimeout の10秒未満を既定値へ戻す補正は可変サイズのプール（minimumIdle が maximumPoolSize 未満）に限られ、その前に maxLifetime に近すぎないかが判定されて、近ければ無効化されます。keepaliveTime は30秒未満か maxLifetime 以上、leakDetectionThreshold は正の値で2000ms未満か、0以外の maxLifetime を超える場合に無効化されます。0は特別な値で、connectionTimeout は待ち時間が2,147,483,647ミリ秒（約24.9日）に設定され、maxLifetime は寿命制限なし、idleTimeout はアイドル回収なしを意味します。警告で補正される項目は例外にならないので、設定したつもりの値が効いていないことに気づきにくい点に注意してください。

WARN HikariConfig - p2 - maxLifetime is less than 30000ms, setting to default 1800000ms.
WARN HikariConfig - p2 - keepaliveTime is less than 30000ms, disabling it.
WARN HikariConfig - p2 - idleTimeout is less than 10000ms, setting to default 600000ms.

maximumPoolSizeとminimumIdle：既定は固定サイズのプール

minimumIdle は「最小アイドル接続数」で、初期接続数ではありません。未指定なら maximumPoolSize と同じ値になり、プールは上限の本数を維持する固定サイズとして動きますが、起動直後や接続の交換中、DB障害時には一時的に不足します。READMEも急な負荷への応答性のために minimumIdle を設定しないことを推奨しています。idleTimeout は minimumIdle が maximumPoolSize より小さいときだけ効くため、固定サイズのまま idle-timeout を調整しても何も変わりません。

maxLifetimeとkeepaliveTime：接続寿命とアイドル切断への対策

maxLifetime は接続の最大寿命で、READMEはDBやネットワーク機器が課す接続時間の上限より「several seconds shorter」に設定するよう強く推奨しています。たとえばMySQLの wait_timeout や、クラウドのロードバランサーのアイドル切断が短く設定されている環境では、既定の30分より先に接続が切られることがあります。HikariCPは貸出時の生存確認で切断を検知した接続を破棄するため、寿命設定だけで切断済み接続の貸出が決まるわけではありません。

寿命には接続ごとに少しずつ短いゆらぎが加えられます。maxLifetime を30秒にして2本のプールを観察すると、1本目は約24秒、2本目は約29秒で「connection has passed maxLifetime」として閉じられ、すぐに新しい接続が補充されました。全接続が同時に切れて再接続が集中するのを避ける仕組みです。なお使用中の接続は寿命を過ぎても回収されず、返却された時点で閉じられます。

keepaliveTime はアイドル接続を定期的に検証してDBやファイアウォールに切られないようにする設定で、maxLifetime が0以外なら、その値未満でなければなりません。maxLifetime を有効範囲の30秒以上2分以下に設定すると、既定の keepaliveTime（2分）が「keepaliveTime is greater than or equal to maxLifetime, disabling it.」の警告とともに無効化されます。READMEは、プールが0本になって回復しない稀な状態を避けるために、PostgreSQLドライバの tcpKeepAlive=true やOS設定でTCP keepaliveを有効にすることも求めています。

initializationFailTimeout：起動時にDBへつながらないときの挙動

既定値は1ミリ秒で、起動時に最初の接続を取れなければ例外で起動を止めます。存在しないポートへ向けて起動すると、HikariPool$PoolInitializationException: Failed to initialize pool が発生しました。

正の値：その時間だけ最初の接続の取得を試みる。この待ち時間は connectionTimeout の後に加算される。
0：接続の取得と検証を試みる。取得できなかった場合はプールを起動し、取得できたのに検証に失敗した場合は例外にする。
負の値：最初の接続を試みずに起動し、接続はバックグラウンドで取得する。実測でも -1 では例外が出ず、接続数0のまま起動した。

DBより先にアプリが立ち上がるコンテナ環境で -1 にすると起動は通りますが、リクエストの接続待ち期限までにDB接続を確保できなければタイムアウトするため、ヘルスチェックでDB接続を確認する運用とセットで使います。

connectionTestQuery：JDBC4対応ドライバでの設定省略

READMEは「If your driver supports JDBC4 we strongly recommend not setting this property.」と明記しています。現行のPostgreSQL、MySQL Connector/J、Oracle、SQL Serverのドライバは Connection.isValid() を実装しているため、SELECT 1 を毎回流す必要はありません。古い資料から connection-test-query を写したまま残っているなら削除して構いません。

Spring Bootでの設定（spring.datasource.hikari.*）

接続先は spring.datasource.*、HikariCP固有の調整は spring.datasource.hikari.* に書きます。キーはケバブケースで、maximumPoolSize は maximum-pool-size になります。

spring:
  datasource:
    url: jdbc:postgresql://db.example.local:5432/app
    username: app
    password: ${DB_PASSWORD}
    hikari:
      pool-name: app-pool
      maximum-pool-size: 20
      connection-timeout: 5000
      validation-timeout: 1000
      max-lifetime: 1740000
      leak-detection-threshold: 30000

この例では、接続待ちを30秒から5秒に縮めて障害時にスレッドが長く詰まらないようにしています。validation-timeout は connection-timeout より短くする決まりがあり、既定の5秒のままでは同値になるため1秒にしました。max-lifetime は、DB側の上限を30分と仮定してその1分前の29分にしています。leak-detection-threshold は、最も長い正常なトランザクションより長い値を選びます。短すぎると正常な処理まで警告されます。Spring Boot全体の構成はSpring Bootの概要と4.1系の変更点で扱っています。

独自DataSource Beanへの直接バインドとjdbc-urlの指定

複数DBに接続するために @ConfigurationProperties("app.datasource") で HikariDataSource を自前で組み立てると、app.datasource.url は反映されません。Spring Bootのhow-toガイドも「Hikari has no url property. Instead, it has a jdbc-url property」と説明しています。HikariDataSourceへ直接プロパティをバインドする場合は、jdbc-url と書くか、DataSourceProperties を経由して url を変換させます。

PreparedStatementキャッシュのドライバ側での設定

DBCP2やc3p0にはPreparedStatementをプールでキャッシュする設定がありますが、HikariCPにはありません。READMEのStatement Cacheの節は、プール層のキャッシュは接続ごとにしか持てない（よく使うクエリ250本×20接続なら5,000の実行計画になる）ため「anti-pattern」だと説明し、PostgreSQL、Oracle、MySQLなどドライバ側のキャッシュを使うよう勧めています。MySQL Connector/Jはキャッシュが既定で無効なので、wiki「MySQL Configuration」の推奨値をドライバのプロパティとして渡します。

spring:
  datasource:
    hikari:
      data-source-properties:
        cachePrepStmts: true
        prepStmtCacheSize: 250
        prepStmtCacheSqlLimit: 2048
        useServerPrepStmts: true

DBCP2から移行して poolPreparedStatements を使っていた場合も、HikariCP側に同じ設定を探さず、この形でドライバへ移します。

プールサイズの決め方と接続数の上限

HikariCPのwiki「About Pool Sizing」は、出発点として次の式を示しています。

connections = ((core_count * 2) + effective_spindle_count)

core_count はDBサーバーの物理コア数（ハイパースレッドは数えない）、effective_spindle_count は作業データが全てメモリに載っていれば0です。4物理コアなら、実効スピンドル数0で8本、1で9本が計算上の出発点です。I/O待ちがあればコア数を超える同時実行が有効な場合もありますが、接続を増やしすぎるとDB側で競合やコンテキスト切り替えの負担が増えます。アプリのスレッド数に合わせて100本や200本に決めず、この値から始めて想定負荷で接続数を変えて比較します。

もう1つの制約は、プールの上限がアプリのインスタンスごとに掛かる点です。maximum-pool-size: 20 のアプリを6台に増やすと、DBへは最大120本の接続が向かいます。PostgreSQLの max_connections は通常の既定値が100で、その設定のままなら、この構成ではオートスケール時に接続拒否が起きます。最大インスタンス数とプールサイズの積に、他アプリ・管理用接続・更新時の一時増加分も加え、予約接続枠を除いたDBの利用可能枠に収まるか確認してください。DB側の接続上限やプール構成を含めた見直しは、一想のデータベース設計・移行支援でも相談を受け付けています。

「Connection is not available」エラーの原因と対処

プールの全接続が貸し出し中のまま connectionTimeout を過ぎると、SQLTransientConnectionException が発生します。最大2本のプールで接続を返さずに3本目を要求すると、次の例外になりました。

java.sql.SQLTransientConnectionException: demo-pool - Connection is not available,
  request timed out after 1149ms (total=2, active=2, idle=0, waiting=0)

括弧内の数字が切り分けの材料です。total が正で active と等しく、idle=0 なら既存接続がすべて使用中、waiting は同時に待っている他のスレッド数です。Spring Bootでは同じ状況で「Could not open JDBC Connection for transaction」に包まれて出ることもあります。

全接続が使用中になる原因は、次の順に疑うのが効率的です。

接続の返し忘れ：close() されない接続はプールへ戻らない。下のリーク検出で特定する。
接続を握ったままの遅い処理：トランザクション内で外部APIを呼ぶ、巨大な結果セットを読み続けるなど。トランザクションの範囲と分離レベルを見直し、外部呼び出しをトランザクションの外へ出す。
画面描画中の遅延ロード：Spring Bootの既定ではspring.jpa.open-in-view（OSIV）が有効で、トランザクション外の遅延ロードでも接続を使用する。接続の取得・返却単位はHibernateの版と接続解放設定に依存し、セッション終了まで保持する場合もある。hikaricp.connections.acquire の回数や usage の時間が想定より多ければ false にして、必要なデータをサービス層で読み切る。
プールが本当に小さい：上の3つを潰したうえで、待ちが恒常的なら前章の式とDB上限の範囲で増やす。

原因を調べずに maximum-pool-size だけを上げるのは避けてください。返し忘れがあれば接続は増えた分だけ漏れ続け、同じ例外が遅れて出るうえに、DB側の max_connections にも先に到達します。

DBが停止しているときの例外：total=0と原因例外

同じ「Connection is not available」でも、DBに接続できない場合は数字の出方が変わります。H2のTCPサーバーに2本の接続を張ったプール（connectionTimeout 3秒）を用意し、サーバーを止めてから getConnection() を呼ぶと、次の結果になりました。

java.sql.SQLTransientConnectionException: down-pool - Connection is not available,
  request timed out after 3142ms (total=0, active=0, idle=0, waiting=0)
Caused by: org.h2.jdbc.JdbcSQLNonTransientConnectionException: Connection is broken:
  "java.net.ConnectException: Connection refused (connect failed): localhost:9123"

DEBUGログでは、getConnection() が貸し出し前の生存確認で切れた2本を「connection is dead」として閉じ、新しい接続の作成も失敗したため、total=0 のまま connectionTimeout いっぱい待って例外になりました。原因例外（cause）にはドライバのエラーが入るので、ここを見ればDBの停止、認証失敗、ネットワーク断を区別できます。貸し出し切りの場合とは対処が逆で、プールを増やしても解決しません。サーバーを再起動すると、アプリを再起動しなくても次の getConnection() は76ミリ秒で成功しました。障害時に利用者を長く待たせないためにも、connection-timeout は既定の30秒より短くしておくことを検討します。

leakDetectionThresholdによる接続借用箇所の特定

leakDetectionThreshold を設定すると、その時間を超えて返却されない接続について、借りた時点のスタックトレースがWARNで出力されます。最大2本のプールで2本を借り、3本目の取得タイムアウト後も2.5秒待ってから返却すると、次のログが出ました（接続URLなどを省略）。

WARN ProxyLeakTask - Connection leak detection triggered for conn0 on thread main, stack trace follows
java.lang.Exception: Apparent connection leak detected
    at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:99)
    at Demo.main(Demo.java:16)
INFO ProxyLeakTask - Previously reported leaked connection conn0 on thread main was returned to the pool (unleaked)

at 行のうちHikariCPより下にある自社コードの行が、接続を借りた場所です。後から「was returned to the pool (unleaked)」が出た接続は漏れではなく、閾値より長く使われていただけです。その場合は処理時間の短縮か閾値の見直しで対応します。maxLifetime は使用中の接続を回収しないため、リーク対策にはなりません。

Failed to validate connectionの警告とmaxLifetime

「Failed to validate connection … Possibly consider using a shorter maxLifetime value.」は、接続の生存確認処理中に例外が発生したときのWARNです。DB側の切断のほか、通信障害や検証処理の失敗でも発生します。HikariCPはその接続を破棄して別の接続を試しますが、1回でも接続取得の遅延やタイムアウトにつながる可能性があります。繰り返し出る場合は例外の詳細とDB・ネットワークのログを照合します。接続時間制限が原因で、maxLifetime がその制限より長い場合は、前述のとおり数秒短くします。

HikariCPメトリクスによる接続待ちとタイムアウトの監視

Spring Boot ActuatorとMicrometerがあれば、HikariCPのメトリクスは自動で登録されます。7.1.0のjarに含まれるメトリクス名は次の10種類で、いずれも pool タグでプールを区別します。

接続数：hikaricp.connections（合計）、.active、.idle、.pending、.max、.min
所要時間：hikaricp.connections.acquire（取得）、.creation（新規作成）、.usage（貸出から返却まで）
失敗数：hikaricp.connections.timeout

アラートに向くのは pending が0より大きい状態が数分続くことと、timeout の増加です。usage の最大値が伸びていれば、返却済み接続の借用時間が長くなっています。返却されない接続はこの値だけでは検知できないため、active・pendingとリーク検出ログも併せて確認します。Actuatorのエンドポイント公開はSpring Boot Actuatorの設定、収集とアラート設定はPrometheusで監視を構築する手順を参照してください。ログで確認したいときは com.zaxxer.hikari をDEBUGにすると、約30秒ごとに「Pool stats (total=2/2, idle=2/2, active=0, waiting=0)」が出力されます。

ほかのコネクションプールを選ぶ場面

Spring Bootの新規開発でHikariCPから替える理由はほとんどありません。替えるのは、HikariCPにない機能が必要な場合に限られます。Oracle RACの高速接続フェイルオーバーなどOracle固有の機能を使うならOracle UCP、アプリケーションサーバーがJNDIで提供するプールを運用上の決まりで使うならそちらを採用します。旧来のTomcat JDBCやDBCP2から移行する場合、validationQuery や testOnBorrow に相当する設定はHikariCPでは不要です。上限はTomcat JDBCの maxActive、DBCP2の maxTotal がHikariCPの maximumPoolSize に対応します。検証、待機時間、放置接続の回収は実装ごとに挙動が違うため、移行前後で負荷をかけて比べます。なおQuarkusのデータソース設定ガイドのとおり、QuarkusではJDBC接続プールをAgroalが担うため、Quarkusのアプリでは quarkus.datasource.jdbc.* で設定し、HikariCPの設定キーは使いません。

よくある質問

HikariCPとは何ですか？

Java向けのJDBCコネクションプールです。DB接続をあらかじめ開いて保持し、アプリへ貸し出して使い回します。Spring Bootでは既定のプールとして自動で使われます。

JDBCのコネクションプールとは何ですか？

DBへの接続をあらかじめ複数開いておき、アプリの要求に応じて貸し出し、使い終わったら切断せずに戻して再利用する仕組みです。接続のたびに発生するTCP接続や認証の処理を省けるうえ、DBへ同時に張る接続の本数に上限を設けられます。

Spring Bootのコネクションプールは何が使われますか？

接続プールの自動選択が適用される場合、クラスパスにHikariCPがあれば優先されます。型の明示指定や独自DataSource Bean、JNDIの設定がある場合は別です。spring-boot-starter-jdbc と spring-boot-starter-data-jpa がHikariCPを依存に含むため、通常は何も設定しなくてもHikariCPです。

HikariCPのデフォルト値は？

主な値は、maximumPoolSize 10、minimumIdle は maximumPoolSize と同じ、connectionTimeout 30秒、idleTimeout 10分、maxLifetime 30分、keepaliveTime 2分、validationTimeout 5秒、leakDetectionThreshold 0（無効）です。7.1.0で読み出した一覧と下限は上の表のとおりです。