Hikaricp

HikariCP 是 Spring Boot 2.x 及以上版本的默认数据库连接池，spring-boot-starter-jdbc／spring-boot-starter-data-jpa 在类路径上检测到它时会自动创建对应的 DataSource，见 spring-boot-relational-persistence.md。 核心设计取向 HikariCP 相比 DBCP、C3P0 等老连接池，主打「轻量、少锁竞争」：连接获取路径尽量避免同步阻塞，字节码层面做了不少微优化（如去掉不必要的包装类）。这也是它成为默认选型的主要原因——同等硬件下吞吐更高、延迟更低。 关键参数 参数 作用 建议 maximumPoolSize 连接池最大连接数 不是越大越好，经验公式 连接数 = (核心数 * 2) + 有效磁盘数；通常 10-20 已足够，过大会导致数据库端连接争用、上下文切换开销上升 minimumIdle 最小空闲连接数 建议和 maximumPoolSize 设成一致，避免连接数动态伸缩带来的抖动（官方推荐固定池大小） connectionTimeout 从池中获取连接的等待超时 默认 30s，业务上一般调到 3-5s，超时快速失败优于线程一直阻塞 idleTimeout 空闲连接被回收前的最长空闲时间 默认 10 分钟，仅在 minimumIdle < maximumPoolSize 时生效 maxLifetime 连接最大生命周期 默认 30 分钟，必须比数据库或负载均衡器的连接超时（如 MySQL wait_timeout）短，否则会用到已被服务端关闭的连接 leakDetectionThreshold 连接泄漏检测阈值 默认 0（关闭）；生产建议设 30000-60000ms，超过该时间连接还未归还池会打印 WARN 日志和借出时的调用栈 application.yml 配置示例： spring: datasource: hikari: maximum-pool-size: 15 minimum-idle: 15 connection-timeout: 3000 max-lifetime: 1500000 leak-detection-threshold: 60000 maxLifetime 为什么防不住连接泄漏 容易有的误解是：既然配了 maxLifetime，超时的连接应该会被自动回收，不会一直泄漏下去。实际上 maxLifetime 只对归还回池中的空闲连接生效，对被业务代码借出、一直没有 close() 的连接不生效。 ...