📚 课程目录第3章 HikariCP快速入门

3. HikariCP快速入门：Spring Boot集成HikariCP，基础配置

你放心，这章不会讲复杂理论。

咱们直接上手，看看HikariCP怎么跟Spring Boot搭在一起。

说白了，Spring Boot从2.0开始，默认连接池就是HikariCP。你什么都不用配，它就已经在背后跑着了。但如果你只管爽不管调，生产环境早晚要给你颜色看。我记得刚带团队时，有个新同事稀里糊涂就上线了，结果一天后数据库连接池被打爆...嗯，后来我让他把配置检查表打印出来贴工位上。

核心观点：Spring Boot + HikariCP 是一对默认CP。你只需要加几行配置，就能让连接池处于健康状态。

3.1 Spring Boot为什么选HikariCP？

Spring Boot社区做过评测，在所有主流连接池里——Druid、C3P0、Tomcat JDBC、HikariCP——HikariCP在吞吐量和延迟上都是最优的。具体来说：

字节码精简：HikariCP对热路径做了极致优化，很少的对象创建和垃圾回收。
FastList替代ArrayList：HikariCP自己实现了FastList，把Statement缓存的遍历效率提了上来。这个细节我当初看源码时真是拍大腿。
ConcurrentBag无锁设计：比起synchronized这种粗锁，ConcurrentBag采用CAS + ThreadLocal缓存，并发抢连接时性能好很多。

所以，别觉得“默认就好”。默认虽然能用，但离最佳状态还有距离。

3.2 基础配置：application.yml怎么写？

你只需在application.yml里加一段配置。我建议把连接池参数独立成一块，别跟datasource的其他属性混在一起。这样以后改参数，一眼就能找到。

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/myapp?useSSL=false&serverTimezone=Asia/Shanghai
    username: app_user
    password: your_secure_password
    driver-class-name: com.mysql.cj.jdbc.Driver
    hikari:
      # -------- 核心参数 --------
      pool-name: MyAppPool
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000
      # -------- 连接验证 --------
      connection-test-query: SELECT 1
      validation-timeout: 5000
      # -------- 其他推荐 --------
      auto-commit: true
      read-only: false

你会发现，核心参数就那么五六个。为什么这么少？因为HikariCP的设计理念就是“让默认值照顾好80%的场景，剩下的你只需要调几个关键参数”。

我的习惯：每次新建项目，我会先把这个模板拷过来，然后根据数据库负载预期调整max-lifetime和idle-timeout。记得有一次，我接手一个老项目，发现它的max-lifetime设成了24小时，结果每天凌晨4点数据库重启...嗯，你可以想象那个场景。

3.3 参数详解：别只看数字，要理解原理

参数名	默认值	我推荐的范围	一句话解释
maximum-pool-size	10	10~30	池子里最多能有多少连接。不是越大越好，数据库并发有限，太多了反而耗CPU。
minimum-idle	10	5~10	池子里至少保持多少空闲连接。设太小，高并发时连接创建有延迟。
connection-timeout	30000	5000~30000	客户端等连接的最大时间（毫秒）。超时就报异常，别让用户一直转圈。
idle-timeout	600000	300000~600000	空闲连接存活多久（毫秒）。超过这个时间，连接会被回收。
max-lifetime	1800000	1200000~1800000	连接的最大寿命（毫秒）。强迫连接定期刷新，避免数据库端主动断开。
connection-test-query	无	SELECT 1	用来验证连接是否有效。MySQL用SELECT 1，PostgreSQL用SELECT 1。
validation-timeout	5000	3000~5000	验证查询的超时时间（毫秒）。太长会导致调用方堆积等待。

3.4 自定义配置：当默认值不够用的时候

有些公司有特殊要求，比如所有连接必须用密文密码。这时候你需要手动配一个DataSource bean。

@Configuration
public class DataSourceConfig {

    @Bean
    public DataSource dataSource() {
        HikariConfig config = new HikariConfig();

        config.setJdbcUrl("jdbc:mysql://localhost:3306/myapp");
        config.setUsername("app_user");
        config.setPassword(decryptPassword());  // 解密方法
        config.setDriverClassName("com.mysql.cj.jdbc.Driver");

        // 关键参数
        config.setMaximumPoolSize(20);
        config.setMinimumIdle(5);
        config.setConnectionTimeout(30000);
        config.setIdleTimeout(600000);
        config.setMaxLifetime(1800000);
        config.setConnectionTestQuery("SELECT 1");

        // 可选：记录连接池运行状态
        config.setMetricRegistry(myMetricRegistry());
        config.setHealthCheckRegistry(myHealthCheckRegistry());

        return new HikariDataSource(config);
    }

    private String decryptPassword() {
        // 你在项目中实现的解密逻辑
    }
}

为什么我推荐用Java配置而不是yml？

因为当你需要集成加密、监控、动态配置中心时，Java配置更灵活。比如你在项目里对接了Vault或AWS Secrets Manager，那你就可以在decryptPassword()里调用远程获取密码。

3.5 连接验证：千万不能省

很多新手会在connection-test-query上偷懒，觉得“数据库很少挂”。但我要告诉你一个常见的坑：

我曾经踩过的坑：有次上线后，高峰期突然出现大量“Connection is not available”异常。排查发现，数据库端做了连接空闲超时策略（wait_timeout=300秒），但HikariCP的idle-timeout没配合好，导致连接被数据库踢掉后，应用还认为它可用。后来加上了SELECT 1验证，问题立刻消失。

所以，我给你的建议是：

MySQL：SELECT 1
PostgreSQL：SELECT 1
Oracle：SELECT 1 FROM DUAL
SQL Server：SELECT 1

不需要写复杂的查询，SELECT 1就够了。HikariCP会在每次从池里取连接时，间隔执行这个检测（具体由connection-test-query触发频率控制），确保交到你手上的连接是活的。

3.6 一个容易忽略的参数：leak-detection-threshold

如果你发现连接池里的连接数一直往上窜，怎么也降不下来，很可能是代码里有连接泄露——拿到的连接没归还。HikariCP提供了一个检测开关：

config.setLeakDetectionThreshold(60_000); // 60秒

当一条连接被借出超过60秒还没归还，HikariCP会在日志里打印完整的堆栈信息，告诉你谁借走的这条连接。这个功能在开发环境非常有用，但生产环境建议设长一点（比如5分钟），避免因为正常长事务产生误报。