3、连接池大小与超时的关系：最大连接数、最小空闲数对超时的影响
参数调优走到这一步，我得跟你聊聊一个很有意思的话题——连接池大小和超时，它们到底怎么互相影响？
很多人调优时，喜欢把最大连接数和最小空闲数当成独立的参数来配。但我在好几个项目里都吃过亏，才发现它们之间的联动关系，才是决定连接池是否稳定的关键。说白了，参数配错了，超时设置再精确也没用。
3.1 最大连接数：池子的“天花板”
最大连接数（maxTotal 或 maximumPoolSize）是连接池能撑住的最大连接数量。它就像一个池子的天花板，决定了你系统能扛多少并发。
这个值设小了会怎样？
- 业务高峰时，所有连接都被占满，新的请求只能排队等——这就是 等待超时（ConnectionTimeout） 的根源。
- 我遇到过一个小型支付系统，并发量一上去，等待队列瞬间堆满，接口直接雪崩。
那设大了呢？
- 后端数据库可能扛不住。每个连接都占用数据库的线程、内存、锁资源。
- 连接创建和销毁的开销也会变大，反而拖慢性能。
- 我记得有一次调个报表系统，把最大连接数从100调到500，结果数据库CPU直接飙到90%。
注意：最大连接数不是越大越好。它必须在后端能承受的范围内。你要做的，是找到那个“够用又不浪费”的值。
3.2 最小空闲数：池子的“保底”
最小空闲数（minIdle 或 minimumIdle）是连接池保证至少保留的空闲连接数。它决定了你在低峰时，池子里还能有多少连接“随时待命”。
这个值设低了会怎样？
- 突然来了一个请求，池子里没有空闲连接，就只能新建。而新建连接通常会花上几十到几百毫秒——这就是 连接获取超时（ConnectionAcquisitionTimeout） 的常见原因。
- 我刚开始做连接池调优时，曾经把最小空闲数设为零，想着省资源。结果每次请求都要新建连接，接口响应时间直接翻倍。
那设高了呢？
- 连接长期闲置，但依然占用数据库资源。对于MySQL或PostgreSQL这类数据库，太多空闲连接会影响查询性能。
- 连接可能因为网络或数据库侧的超时而“僵死”，变成所谓的僵尸连接。
我的个人习惯：最小空闲数通常设为核心线程数的50%左右。太低容易冷启动，太高会浪费资源。你可以在压测时观察空闲连接的使用率，再微调。
3.3 两个参数如何协同影响超时
为什么这两个参数会影响到超时？我们来拆解一下。
当系统收到一个请求时，连接池先做什么？
- 检查池子里有没有空闲连接。
- 有的话，直接返回该连接。
- 没有的话，检查当前连接数是否达到 最大连接数。
- 没达到，就新建一个连接；达到了，就进入等待队列。
- 如果在 连接超时时间 内没有等到空闲连接，就抛异常。
看到了吗？最大连接数 决定了队列的长度，最小空闲数 决定了队列被排空的速度。任何一个设置不合理，都会直接导致超时。
我举个例子：
| 参数组合 | 场景 | 可能导致的问题 |
|---|---|---|
| maxTotal=10, minIdle=0 | 高并发短连接请求 | 频繁新建连接，引发 连接获取超时 |
| maxTotal=10, minIdle=5 | 稳定负载系统 | 预留较多空闲，超时概率低，但资源占用高 |
| maxTotal=200, minIdle=10 | 突发流量场景 | 峰值时不会因连接不够而超时，但需注意后端数据库承受能力 |
| maxTotal=50, minIdle=40 | 低并发但需要快速响应的场景 | 大量空闲连接，可能造成数据库连接僵死，间接引发超时 |
你想想看，是不是每个组合都有它的适用场景和风险？没有通用的“最佳值”，只有针对你业务的最优解。
核心观点：
- 最大连接数：控制并发天花板，过高或过低都会引发超时。
- 最小空闲数：控制冷启动概率，太低会引发连接获取超时，太高可能引发僵死连接超时。
- 它们是一对跷跷板：你需要在“不超时”和“不浪费”之间找到平衡。
3.4 实战建议：避免我踩过的坑
最后，分享几个我踩过的坑，希望能帮到你。
- 不要盲目增大最大连接数。我曾经以为能解决所有问题，结果数据库直接被打挂。一定要先摸清后端能承受的极限。
- 不要将最小空闲数设为零。除非你的业务对首次连接延迟不敏感，否则这会成为高频超时的根源。
- 结合超时时间一起看。比如连接超时时间设置得很长（比如60秒），最大连接数可以适当放小；但如果超时时间很短（比如1秒），那最大连接数就得大一点。
- 监控空闲连接的真实使用情况。很多连接池框架（如HikariCP）都提供指标。我习惯在压测时观察空闲连接数，如果长时间保持在最大值，可以考虑降低 minIdle。