核心参数详解：maximumPoolSize, minimumIdle, connectionTimeout 等
这堂课咱们来聊聊 HikariCP 最核心的几个参数。说实话，很多新手一上来就照着网上的配置抄，结果要么连接不够用，要么内存爆了。我个人觉得，理解这些参数背后的原理，比记住默认值重要得多。你想想看，一个连接池就像一家餐厅的座位，座位太少客人排队，座位太多浪费租金，还得管理空着的桌子——一个道理。
1. maximumPoolSize – 最大连接数
这个参数决定连接池里最多能有多少个活连接。默认值是 10，但别以为 10 就够用。我在项目中遇到过一个小型支付服务，上线后高峰期数据库连接直接打满，请求堵塞，最后查出来是 maximumPoolSize 设成了默认值 10，而实际 QPS 远高于这个数。
那到底设多少？
- 先看数据库的 max_connections 上限，别超过它。
- 再用公式：
maximumPoolSize = T × (C – 1) + 1，其中 T 是线程数，C 是核心数。其实更简单的经验是：最大连接数 ≈ 应用最大并发线程数 × 0.8。 - 我个人习惯留 20% 的余量，避免连接长时间占着不释放。
2. minimumIdle – 最小空闲连接
这个参数控制池子里至少保持多少个空闲连接。默认值跟 maximumPoolSize 一样（也就是全部保持），但这样会浪费资源。比如你凌晨流量很低，还留着 200 个空闲连接干嘛？
我的建议：
- 如果应用流量波动较大（比如白天高、夜里低），设成 maximumPoolSize 的 10%~20%。
- 如果应用是持续平稳高并发（比如消息队列消费），可以设成和 maximumPoolSize 一致，减少创建连接的延迟。
说白了，这个参数就是「保底」用的。你想想看，突然来一波请求，池子里一个空闲连接都没有，就得现场创建，那得多慢？
3. connectionTimeout – 连接超时
客户端请求连接时，如果池子里没有可用连接，最多等多久？默认 30 秒。这个值设太长，用户会等到崩溃；设太短，高并发下频繁超时，影响业务。
我习惯这样设：
- 对端到端延迟敏感的接口（如支付、下单），设 5~10 秒。
- 对后台批量任务，可以设 30~60 秒。
- 注意：
connectionTimeout和validationTimeout不一样，别搞混。
4. idleTimeout & maxLifetime – 空闲与最大寿命
这两个参数管的是连接什么时候该被干掉。
| 参数 | 作用 | 默认值 | 建议范围 |
|---|---|---|---|
| idleTimeout | 连接空闲多久后被关闭 | 600秒（10分钟） | 300~900秒 |
| maxLifetime | 连接最长存活时间 | 1800秒（30分钟） | 600~3600秒 |
为什么要限制最大寿命？因为数据库连接长时间不换有被回收的风险，特别是一些负载均衡器会在 30 分钟后断开 idle 连接。我遇到过一例：应用跑了 12 小时后，所有连接都变成断链，读数据直接抛异常，就是因为 maxLifetime 设成了 0（无限），配合防火墙的空闲超时，连接被切断后池子还不知道。
5. 参数调优实战建议
下面这张 SVG 图展示了连接池的生命周期，以及每个参数在哪个环节起作用。你可以对照着理解调优思路。
最后，我整理了一个参数配置检查清单，方便你落地时对照：
| 参数 | 检查点 | 常见错误 |
|---|---|---|
| maximumPoolSize | 是否小于数据库上限？是否等于并发线程数 × 0.8？ | 设得太大导致资源耗尽，或太小导致等待 |
| minimumIdle | 低峰期是否会造成大量空闲连接浪费？ | 设得太大占用内存，设得太小导致冷启动 |
| connectionTimeout | 是否匹配接口超时时间？ | 设得太长用户无响应，太短无效超时 |
| idleTimeout | 是否大于连接池的检查间隔？ | 设得太短频繁断开，太长连接泄漏风险 |
| maxLifetime | 是否小于数据库/中间件的空闲回收时间？ | 设成 0 或过大导致断链不感知 |
嗯，以上这几个参数，覆盖了连接池从创建到销毁的全生命周期。理解它们之间的配合关系，比死记硬背数值重要得多。下一轮咱们可以聊聊如何通过监控指标来验证调优效果，不过那是后面的事了。