最大连接数应匹配数据库限制、CPU核数与实际并发压力，推荐设为数据库max_connections的70%、CPU核数×2～6，并经压测验证；idleTimeout（10分钟）须小于maxLifetime（30分钟），配合keepaliveTime探活防失效。
核心参数含义与典型取值
不同连接池（如 HikariCP、DBCP2、Druid）参数名略有差异，但语义高度一致：
-
maximumPoolSize / maxTotal：池中最多允许的活跃连接数。默认常为 10–20，高并发服务需提升，但不宜超过数据库
max_connections的 70%； - minimumIdle / minIdle：始终保留在池中的最小空闲连接数。设为 5–10 可减少冷启动延迟，避免突发流量时频繁建连；
- connectionTimeout：应用等待连接的最长时间。建议设为 10–30 秒，过长会拖慢接口响应，过短易误抛异常；
- idleTimeout：空闲连接在池中保留的最久时间（不被使用）。推荐 600 秒（10 分钟），防止被中间件或数据库主动踢断；
- maxLifetime：连接从创建起最长存活时间。建议设为 1800–5400 秒（30–90 分钟），强制轮换连接，规避长连接导致的 MySQL wait_timeout 或连接泄漏；
- maxWaitQueueLength（HikariCP 无此参数，由 connectionTimeout 间接控制）：等待获取连接的队列长度上限。DBCP2 等支持该参数，设为 0 表示无限排队，生产环境建议设有限值（如 200），防 OOM。
如何科学设定最大连接数
盲目调大 maximumPoolSize 是常见误区。它应基于三方面综合判断：
- 数据库侧限制：查 MySQL 的
show variables like 'max_connections';，留出 20% 余量供后台任务或管理连接； - CPU 与线程模型：若应用是 CPU 密集型，连接数 ≈ CPU 核数 × 2～4；若是 I/O 密集型（如大量查询+远程调用），可适度提高至 ×6，但需压测验证；
- 实际并发压力：用 JMeter 或 wrk 模拟真实请求链路，观察连接等待时间（
connection acquisition time）、平均响应时间及 DB CPU/连接数监控，找到“等待开始明显上升”的拐点值。
空闲与生命周期参数协同配置
idleTimeout 和 maxLifetime 需配合设置，否则可能冲突：
- 若
idleTimeout > maxLifetime，连接可能在被回收前就因超龄失效，归还时触发校验失败； - 推荐组合：
idleTimeout = 600000（10 分钟），maxLifetime = 1800000（30 分钟），确保空闲连接有足够“缓冲期”再被强制淘汰； - HikariCP 默认开启连接健康检查（
connectionTestQuery已弃用，改用validationTimeout+keepaliveTime），建议启用keepaliveTime=30000（30 秒），定期探活，避免 DNS 变更或防火墙超时导致的静默失效。
其他实用优化点
除基础参数外，这些细节常决定连接池是否真正稳定高效：
立即学习“Java免费学习笔记（深入）”；
-
预编译语句缓存：对 HikariCP，添加
config.addDataSourceProperty("cachePrepStmts", "true")和"prepStmtCacheSize", "250"，降低 SQL 解析开销； -
连接泄露防护：启用
leakDetectionThreshold（如 60000 毫秒），日志中输出未关闭连接的堆栈，快速定位代码问题； -
命名与监控：设
poolName="ProdHikariPool"，配合 Micrometer 或 Actuator 暴露hikaricp.connections.active等指标，实时看板比日志更早发现问题； -
避免配置漂移：Spring Boot 中优先用
spring.datasource.hikari.*属性统一管理，而非硬编码 Config 类，方便多环境切换。
