---
title: "HikariCPとは？既定値一覧とSpring Bootでの設定・タイムアウト対処【7.1.0】"
url: "https://www.issoh.co.jp/tech/details/6492/"
published: 2025-05-01
updated: 2026-10-15
categories: ["Java"]
publisher: "株式会社一創"
---

# 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）](https://docs.spring.io/spring-boot/reference/data/sql.html)は接続プールの選択順を「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()` が次の順で空き接続を探します。

1. そのスレッドが最近返した接続のリスト（スレッドローカル・最大16件）を後ろから見る。
2. 全接続を持つ共有リスト（`CopyOnWriteArrayList`）を先頭から走査し、空いている接続の状態をCAS（比較して交換）で「使用中」に切り替える。
3. 空きがなければ接続の追加を依頼し、`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のバージョン一覧](/tech/details/5172/)で確認できます。

```
<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の設定項目一覧](https://github.com/brettwooldridge/HikariCP#gear-configuration-knobs-baby)に記載された下限を並べます。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系の変更点](/tech/details/17478/)で扱っています。

### 独自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の節](https://github.com/brettwooldridge/HikariCP#statement-cache)は、プール層のキャッシュは接続ごとにしか持てない（よく使うクエリ250本×20接続なら5,000の実行計画になる）ため「anti-pattern」だと説明し、PostgreSQL、Oracle、MySQLなどドライバ側のキャッシュを使うよう勧めています。MySQL Connector/Jはキャッシュが既定で無効なので、wiki「[MySQL Configuration](https://github.com/brettwooldridge/HikariCP/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](https://github.com/brettwooldridge/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側の接続上限やプール構成を含めた見直しは、一想の[データベース設計・移行支援](/service/system/database/)でも相談を受け付けています。

## 「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を呼ぶ、巨大な結果セットを読み続けるなど。[トランザクションの範囲と分離レベル](/tech/details/13690/)を見直し、外部呼び出しをトランザクションの外へ出す。
- 画面描画中の遅延ロード：Spring Bootの既定では[spring.jpa.open-in-view（OSIV）](/tech/details/3692/)が有効で、トランザクション外の遅延ロードでも接続を使用する。接続の取得・返却単位は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の設定](/tech/details/1931/)、収集とアラート設定は[Prometheusで監視を構築する手順](/tech/details/17516/)を参照してください。ログで確認したいときは `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のデータソース設定ガイド](https://quarkus.io/guides/datasource)のとおり、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で読み出した一覧と下限は上の表のとおりです。

### HikariCPの開発者は誰ですか？

Brett Wooldridge氏です。GitHubの brettwooldridge/HikariCP で開発されており、ライセンスはApache License 2.0です。

### HikariDataSourceとは何ですか？

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

### HikariPoolとは何ですか？

接続の貸し出しや補充、寿命管理を行うHikariCP内部のクラスです。ログの「HikariPool-1」は、プール名を付けていない1つ目のプールを指します。

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

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

## 関連記事

- [Spring Bootとは｜4.1系の依存名の変更と最小Web APIの作り方](/tech/details/17478/)
- [spring.jpa.open-in-viewとは？OSIVの既定値trueと起動時警告の消し方・falseの判断基準](/tech/details/3692/)
- [トランザクションとは？分離レベルの違い・ACID・commit/rollbackを実装目線で解説【2026年版】](/tech/details/13690/)
- [Spring Boot Actuatorの設定｜exposure.includeとaccessの使い分け【4.1対応】](/tech/details/1931/)
- [Spring Bootバージョン一覧とサポート期限（EOL）【2026年10月】最新版は4.1、4.0の無償サポートは12月末終了](/tech/details/5172/)

---

出典: [HikariCPとは？既定値一覧とSpring Bootでの設定・タイムアウト対処【7.1.0】](<https://www.issoh.co.jp/tech/details/6492/>)（株式会社一創）