最大连接数和超时等待时间是jdbc连接池最关键的两个配置项，需结合业务吞吐、数据库能力与响应特征设定：最大连接数建议不超过数据库max_connections的70%～80%，超时等待时间推荐1000～5000毫秒，并辅以等待队列长度、空闲超时和泄露检测等参数协同控制。
最大连接数和超时等待参数是 JDBC 连接池最直接影响可用性与稳定性的两个配置项。配得太小，高并发下请求排队甚至报错；配得太大，又可能压垮数据库或造成连接泄露。关键不是套用固定数值，而是结合业务吞吐、数据库能力与响应特征来设。
最大连接数（maximumPoolSize / maxTotal）怎么设
这个值代表连接池最多能提供多少个活跃连接。它不是越大越好，必须参考数据库的 max_connections 限制，并预留缓冲空间：
- 先查数据库实际允许的最大连接数，例如 MySQL 默认通常是 151，生产环境可能调到 500～1000
- 应用侧最大连接数建议不超过数据库上限的 70%～80%，比如数据库设了 600，则应用连接池设 400～480 较稳妥
- 也可按经验公式粗略估算：(平均单次查询耗时秒 × 每秒请求数 QPS) × 1.5，再向上取整
- HikariCP 中设
maximumPoolSize=40，Commons DBCP 或 Druid 则对应maxTotal=40
获取连接的超时等待时间（connectionTimeout）
这是从连接池中拿连接时，愿意等多久。默认值往往偏保守（如 HikariCP 是 30 秒），但线上服务通常应更严格：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 建议设为 1000～5000 毫秒（1～5 秒），避免线程长时间阻塞拖垮整个接口
- 若频繁触发此超时，说明连接不够用或有连接未释放——优先排查连接泄露，而非盲目调大
- HikariCP 中用
connectionTimeout配置，单位毫秒；Druid 对应maxWait
空闲连接与等待队列的辅助控制
光调这两个还不够，还需配合其他参数防止“假堵”：
- maxWaitQueueLength：等待队列长度上限（HikariCP 无此参数，Druid/DBCP 支持）。设为有限值（如 50），超限直接拒绝，避免雪崩
- idleTimeout：空闲连接存活时长（如 10 分钟）。防止长期不用的连接僵在池里却已失效
- leakDetectionThreshold：连接泄露检测阈值（如 60000ms）。开启后，若 getConnection 后超过该时长未 close，会打印告警堆栈
这些参数要写在初始化连接池时的配置对象里，而不是靠运行时动态改——多数连接池不支持热更新关键容量参数。不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
