连接池配小了确实会让请求排队等待，但通常不会无限期等下去，达到最大等待时间后请求就会直接抛异常。这个过程就像银行只开两个窗口，高峰期来了二十个人，剩下十八个只能在等候区坐着，问题是，等候区也有上限,超过容量就得有人被请走。
连接池是怎么工作的？为什么配小了会排队
连接池的本质是“复用数据库连接”，每次操作数据库都要新建连接太贵了，于是程序启动时先创建一批连接放在池子里，请求来了就借走一个，用完再还回来,池子的大小由maxActive这类参数控制。
当所有连接都被占用时，新的请求就只能进入等待队列，这个队列不是无限长的，取决于maxWait参数，maxWait指的是“最长等待时间”，单位通常是毫秒，如果设置了5000，那么请求最多等5秒，超时直接抛出异常，比如常见的Connection pool timeout或者Wait millis错误。
一个典型的连接池排队场景
想象一个电商秒杀活动，平时数据库连接池配置了20个连接，活动开始后，瞬间涌入200个下单请求，前20个请求顺利拿到连接，剩下180个全部开始等待，如果每个请求处理耗时100毫秒，20个连接一秒钟能处理200个请求，其实够用，但实际每个请求可能要查询库存、扣减、写订单，耗时300毫秒以上，这样20个连接一秒钟只能处理大约66个请求,180个等待的请求就会排起长队。
如果maxWait配置的是3000毫秒，队列中靠后的请求等待时间超过3秒，就会报错，用户看到的就是“系统繁忙”或者“操作失败”，所以连接池配小了，排队是必然的，但“一直等着”只会在maxWait配置为-1时发生，maxWait为-1表示无限等待，这种情况下请求确实会一直占着线程,直到拿到连接或者应用被重启。
连接池配置多少合适？主要看这几个参数
很多同学问“数据库连接池配置多少合适”，这个没有固定数字，但有一套行业共识的调整思路,核心参数有三个：
- maxActive：最大活跃连接数,决定了池子最多能同时借出多少连接。
- maxWait：最大等待时间,避免请求无限期排队。
- minIdle：最小空闲连接数，保证低峰期也有连接可用,避免冷启动。
不同场景下的参考配置
老牌Tomcat JDBC Pool、Druid、HikariCP等连接池的参数名略有差异，但逻辑相同，以HikariCP为例，官方推荐maximumPoolSize设置为cpu核心数×2 + 磁盘IO等待因子，实际上多数业务场景下，50到100个连接足够支撑每秒数千次的数据库操作，原因很简单，一条SQL执行通常几毫秒到几十毫秒，连接本身不慢,慢的是网络和磁盘。
下表是不同业务类型的经验值参考：
| 业务特征 | maximumPoolSize | maxWait | 说明 |
|---|---|---|---|
| 后台管理系统，低并发 | 10-20 | 3000 | 大多数时间只有几个管理员操作 |
| 面向用户的中等流量应用 | 20-50 | 5000 | 常见电商、内容系统的初始配置 |
| 高并发秒杀或抢购 | 50-100 | 1000-3000 | 等待时间要短，宁可快速失败也不要拖垮线程池 |
| 内部定时任务批量处理 | 10-30 | 10000 | 批量任务对延迟不敏感，但需要稳定连接 |
这里有个容易被忽略的点：连接池大小还要考虑数据库自身的承受能力，MySQL默认最大连接数是151，如果你把应用连接池配到200，数据库自己先扛不住，所以配置前先查一下数据库的max_connections。
连接池排队等待超时怎么办？三步定位问题
遇到连接池等待超时的报错，别急着调大maxActive，先做三步排查,否则可能调大之后问题更严重。
第一步：确认是连接池等待还是其他瓶颈
日志里看到Connection is not available, request timed out after 3000ms这类信息，只能说明连接不够用，但根本原因可能是SQL慢、锁等待、或者连接泄漏，先看慢查询日志，如果大量SQL超过1秒，那么调大连接池只会让更多慢SQL同时跑,数据库更快崩溃。
第二步：查看连接池监控指标
大多数连接池都有监控功能，Druid有监控页面，HikariCP可以通过Micrometer暴露指标,重点看两个数字：
- 活跃连接数是否经常打满，如果maxActive是50，活跃连接长期在45以上,说明池子确实偏小。
- 等待次数和等待时间，如果等待次数很少，偶尔超时，可能只是瞬时尖峰,调整maxWait更有效。
第三步：按需调大maxActive和maxWait
如果确认是连接数不足，才考虑调参，以一个Spring Boot项目为例，在application.yml中修改HikariCP配置：
spring:
datasource:
hikari:
maximum-pool-size: 50
minimum-idle: 10
connection-timeout: 5000
改完之后压测，观察QPS和响应时间，如果调大后数据库CPU使用率飙到80%以上，说明连接池不是瓶颈，数据库已经是瓶颈了,这时候应该优化SQL或者加缓存。
常见误区：调大连接池就万事大吉了吗？
并不是，连接池配大之后，排队问题可能消失,但新的问题立刻出现。
连接数不是越多越好
每个连接都会占用数据库内存和文件句柄，MySQL中每个连接约有1MB级别的内存开销，1000个连接就是1GB内存，这还不包括执行SQL时的临时内存，业内专家指出，连接数超过一定程度后，数据库性能会显著下降，因为CPU大量时间花在上下文切换上,而不是真正执行SQL。
连接池与数据库负载的平衡
一个典型场景：某应用把连接池从50调到200，结果数据库CPU从30%飙升到95%，所有请求都变慢了，原因是之前连接数不够时，请求在排队，数据库负载反而不高，现在连接数足够，并发SQL量暴增,数据库直接过载。
所以正确的做法是：连接池大小要结合数据库压测结果来定，先确定数据库能承受的最大并发连接数，再给应用配置一个安全比例，比如数据库能扛100个连接，应用连接池就设60-70,预留一部分给管理后台和备用系统。
连接池配小了会排队，但不会一直等，真正要关心的是超时后的处理策略和整体系统容量，把maxWait设置成合理值，让请求快速失败，比无限制排队更有价值，记住一个原则：连接池是资源调度器，不是数据库加速器，合理配置，让请求在合理时间内拿到连接,才是正解。
连接池maxWait设置多少合适？常见问题解答
问题：连接池maxWait设置多少合适？
maxWait取决于业务对延迟的容忍度，面向用户的操作建议设成1000到3000毫秒，超过3秒用户基本就放弃了，后台批处理可以设成10秒以上，因为任务失败重跑的成本更高，设成-1虽然避免了超时异常，但会让请求线程全部阻塞，拖垮应用本身的线程池,极不推荐。
问题：连接池被打满后请求会丢失吗？
不会丢失，只会超时，连接池的等待队列在内存中保存着请求任务，如果等待时间没到，请求还排着队；超时后抛出异常，由上层代码决定是重试还是提示用户，但如果应用配置了无限等待，同时线程池也被占满，新的请求可能直接进不了线程池，表现为Tomcat返回connection reset，所以连接池超时和线程池饱和要一起考虑,通常给线程池也设置一个较短的排队时间。