HikariCP连接池性能优化需协同配置maxPoolSize、minimumIdle、connectionTimeout、idleTimeout、maxLifetime五大参数，并结合压测与实时监控验证；盲目调大反而易压垮数据库。
直接调大连接池大小不等于性能提升，关键在匹配应用负载与数据库承受能力。盲目设高可能压垮数据库，设低又导致请求排队超时。真正有效的调整，是围绕五个核心参数做协同配置，并配合真实流量验证。
最大连接数（maxPoolSize）要按并发峰值设
它不是拍脑袋定的数字，而是基于业务高峰期的并发请求数和单次数据库操作耗时来估算。比如平均每次查询耗时100ms，系统每秒需处理200个请求，理论最小连接数约为 200 × 0.1 = 20。实际建议在此基础上上浮30%~50%，设为30–40。HikariCP默认是10，DBCP是8，通常远不够用。
- 线上压测时重点观察：活跃连接数是否持续接近 maxPoolSize，且等待获取连接的线程明显增多
- 若出现“connection timeout”或大量线程卡在 getConnection()，说明 maxPoolSize 已成为瓶颈
- 但超过数据库允许的最大连接数（如 MySQL 的 max_connections=200），反而会触发拒绝连接，得不偿失
最小空闲连接数（minimumIdle）决定冷启动响应
这个值保障池中始终有可用连接，避免突发流量来临时临时创建连接拖慢首请求。它一般设为 maxPoolSize 的 20%~50%，例如 maxPoolSize=40，minimumIdle 可设为10–20。
- 太小（如设为0或1）：流量突增时，前几批请求要等新连接建立，响应时间跳变明显
- 太大（如等于 maxPoolSize）：空闲连接长期占用数据库资源，可能被数据库主动断开（尤其设置了 wait_timeout）
- HikariCP 默认 minimumIdle 等于 maxPoolSize，生产环境建议显式下调
连接超时与空闲回收必须配套设置
光调大小没用，超时机制不到位会导致连接堆积或失效。两个参数必须联动：
立即学习“Java免费学习笔记（深入）”；
- connectionTimeout（获取连接超时）：建议 3–5 秒。太短用户看到频繁报错，太长线程阻塞影响整体吞吐
- idleTimeout（空闲连接存活时间）：建议 10 分钟（600000ms）。比数据库的 wait_timeout 小至少 2 分钟，防止连接被 DB 主动踢掉后 Java 还以为有效
- maxLifetime（连接最大生命周期）：建议 30 分钟（1800000ms）。强制轮换连接，避免因网络闪断、数据库重启等导致的“假死连接”累积
监控指标比配置数字更重要
参数调完不看效果，等于没调。重点关注三个运行时指标：
- activeConnections：当前正在使用的连接数。持续 > 80% maxPoolSize，说明池子偏小
- idleConnections：空闲连接数。长期为 0，说明 minimumIdle 过低或连接未归还（存在泄漏）
- threadsAwaitingConnection：等待连接的线程数。> 0 就是性能瓶颈信号，需立即扩容或查泄漏
推荐用 HikariCP 自带的 MBean 或 Micrometer + Prometheus 做可视化，比日志排查快得多。
