HikariCP调优关键在于精准匹配业务与数据库能力，而非堆参数；核心是合理设置maximumPoolSize（建议10–25）、minimumIdle（常等于最大值）、maxLifetime（30分钟）、idleTimeout（10分钟）及分层超时，并启用连接泄漏检测与预编译缓存等配套优化。
直接配对关键参数比盲目调大数字更有效。HikariCP 的性能优势不来自堆配置项，而来自精准匹配业务负载与数据库能力的几个核心值。
连接池大小要算，不能猜
最大连接数不是越大越好，它必须小于数据库允许的最大连接数（如 MySQL 的 max_connections），同时避免线程竞争和资源浪费。
- 经验公式：最大连接数 ≈ （CPU 核心数 × 2）+ 有效磁盘数；常见服务建议设为 10–20，高并发读写混合场景可试 15–25
- 最小空闲连接（minimum-idle）建议设为与 maximum-pool-size 相同，避免高峰时频繁创建新连接
- 若应用部署在容器中（如 Kubernetes），需按单实例 CPU limit 计算，而非宿主机核数
生命周期控制防止“僵尸连接”
MySQL 默认 wait_timeout=28800（8 小时），但连接池里长期空闲的连接可能被服务端悄悄断开，再被借出就会报 Communications link failure。
- max-lifetime 设为 1800000ms（30 分钟），强制连接在过期前归还并重建
- idle-timeout 设为 600000ms（10 分钟），比数据库 wait_timeout 至少短 5 分钟
- 启用 keepaliveTime=30000ms（30 秒），定期发送心跳（配合 connection-test-query=SELECT 1）验证空闲连接有效性
超时与验证要分层设置
连接获取、验证、使用三个阶段的超时必须有明确边界，否则会掩盖真实问题。
立即学习“Java免费学习笔记（深入）”；
- connection-timeout=30000ms（30 秒）：业务线程最多等这么久，超时抛异常，便于快速失败和监控定位
- validation-timeout=5000ms（5 秒）：验证连接是否存活的操作不能拖慢整体流程
- 开发环境务必开启 leak-detection-threshold=2000（单位毫秒），检测未归还连接；生产环境关闭，避免性能损耗
配套优化提升复用效率
光调连接数不够，还要让每次连接用得更快、更稳。
- 开启预编译语句缓存：cachePrepStmts=true、prepStmtCacheSize=250、prepStmtCacheSqlLimit=2048
- 禁用 JMX（register-mbeans=false）：生产环境无需暴露管理接口，减少锁和内存开销
- 避免在配置中使用 autoReconnect=true 等过时参数，HikariCP 依赖自身健康检查机制，不靠驱动重连
