3. 连接池超时：连接复用中的超时陷阱与配置
连接池这东西，说白了就是「复用」。你想想看，每次请求都新建 TCP 连接，三次握手加 TLS 握手，光握手开销就能吃掉你几百毫秒。所以业界普遍的做法是——用完的连接别丢，放回池子里，下次直接用。
但问题来了。池子里的连接，真的永远可用吗？
我在项目中遇到过不止一次：线上突然出现大量超时，查了一圈发现连接池里的连接早就被服务端关了，客户端却不知道，还在傻傻地复用。这就是连接池超时配置没做好的典型后果。
3.1 连接池的核心机制
先看一张图，帮你快速理解连接池的生命周期：
从图上你能看到，连接池不是简单的「存-取」容器。它有三个核心超时参数，任何一个配错，都会引发连锁问题。
3.2 三个核心超时参数
3.2.1 连接空闲超时（idleTimeout）
这个参数控制的是：一条连接在池子里闲着多久，就该被清理掉。
我见过很多团队把这个值设得特别大，比如 30 分钟。他们的想法是「省得频繁创建连接」。但这里有个坑——服务端通常有自己的空闲超时，比如 Nginx 默认 60 秒就会关掉空闲连接。你客户端设 30 分钟，服务端 1 分钟就关了，那池子里存的连接全是「僵尸连接」。
我个人习惯的做法是：先查清楚中间件或反向代理的空闲超时配置，然后客户端设成它的 70%-80%。比如 Nginx 默认 60s，我就设 45s。
3.2.2 连接最大存活时间（maxLifetime）
这个参数更隐蔽。它规定了一条连接从创建到销毁的最长寿命，不管它有没有被用过。
为什么要设这个？因为网络设备、防火墙、负载均衡器都有连接跟踪表。一条 TCP 连接如果活得太久，中间设备可能会把它的状态给忘了。我记得有一次排查线上问题，发现每隔 8 小时就会批量超时，最后定位到是防火墙的连接跟踪超时是 8 小时，而连接池的 maxLifetime 没设，默认无限长。
| 参数 | 推荐值 | 说明 |
|---|---|---|
| idleTimeout | 30s - 60s | 小于服务端空闲超时 |
| maxLifetime | 30min - 60min | 小于网络设备连接跟踪超时 |
| waitTimeout | 100ms - 500ms | 根据业务响应时间调整 |
3.2.3 等待获取连接超时（waitTimeout）
这个参数决定了：当池子里没有空闲连接时，调用方愿意等多久。
设得太短，流量尖峰时大量请求直接失败。设得太长，请求排队堆积，线程池被打满，最终拖垮整个服务。
我曾经在一个高并发项目里，把 waitTimeout 设成了 5 秒。结果某次促销流量上来，连接池瞬间被占满，后续请求全部排队 5 秒才拿到连接。5 秒啊，用户早走了。后来我改成 200 毫秒，配合快速失败和重试机制，效果好了很多。
3.3 连接泄漏：比超时更可怕的陷阱
超时配置错了还能调，但连接泄漏是代码层面的问题。我见过最典型的场景：
- 从连接池拿了连接，业务逻辑异常了，忘记归还
- 或者归还时没放到正确的池子里
- 或者用了 try-with-resources 但内部又嵌套了连接获取
连接泄漏的后果是：池子里的连接被慢慢耗尽，新请求拿不到连接，全部进入 waitTimeout 排队，最终服务雪崩。
怎么排查？我一般用两个手段：
- 监控连接池指标：活跃连接数、空闲连接数、等待线程数。这三个指标同时上涨，基本就是泄漏了。
- 设置连接泄漏检测：像 HikariCP 有 leakDetectionThreshold，设成 5 秒，超过这个时间连接还没归还就打印堆栈。
// HikariCP 连接泄漏检测配置示例
HikariConfig config = new HikariConfig();
config.setLeakDetectionThreshold(5000); // 5秒
config.setConnectionTimeout(300); // waitTimeout 300ms
config.setIdleTimeout(45000); // 45秒
config.setMaxLifetime(1800000); // 30分钟3.4 连接池大小：不是越大越好
很多人觉得连接池越大，并发能力越强。其实不是。
数据库连接是重量级资源。每条连接都要占用内存、文件描述符、数据库端的线程。连接数过多反而会导致上下文切换加剧、锁竞争严重。
我记得有个经典公式：连接数 = (核心线程数 + 1) × 2。当然这只是经验值，具体要看你的数据库性能和业务复杂度。
核心原则： 连接池不是越大越好，而是「够用就好」。多出来的连接只会增加管理开销，不会提升吞吐量。
3.5 避坑指南
最后总结几个我踩过的坑，你直接拿去用：
- 坑一： idleTimeout 设得比服务端大。结果就是频繁报「Connection reset」。解法：统一对齐上下游超时配置。
- 坑二： maxLifetime 不设，默认无限。结果就是半夜批量超时。解法：设成 30-60 分钟，定期刷新连接。
- 坑三： waitTimeout 设得太大。结果就是请求排队拖垮服务。解法：设小一点，配合熔断降级。
- 坑四： 连接池大小设得太大。结果就是数据库被打满。解法：压测找到最佳值，别拍脑袋。
我曾经在一个金融项目里，把所有超时参数都压测调优了一遍，连接池从 200 减到 50，吞吐量反而提升了 30%。嗯，有时候少即是多。