连接池：那个让无数人吃亏的隐形性能杀手
三年前，我接手了一个接口响应时间 2 秒的系统。团队信誓旦旦："数据库没问题，SQL 优化过了，索引加了，服务器配置也够。"
我花了三天查遍了所有慢查询日志，一无所获。最后我打开了监控面板看了一眼连接池——最小连接数是 2，最大连接数是 10，而当时服务并发量是每秒 300 请求。
十分钟改完配置，接口响应时间降到 80 毫秒。
这个故事告诉我们一个血淋淋的道理：很多人连自己手里工具的基本原理都没搞明白，就敢上生产环境。
连接池到底是什么？
先来一个标准答案：连接池是预建立一批数据库连接，用完放回而不是关闭，下次直接复用，不用每次请求都重新建立 TCP 握手的机制。
但问题来了——连接池的"池"到底多大合适？
我见过的配置，千奇百怪：
- 最小 2，最大 10（经典小作坊配置）
- 最小 100，最大 500（暴力流）
- 各种默认值复制粘贴，连 dbcp 和 druid 的区别都不知道
这背后折射出一个普遍现象：国内大部分团队把连接池当玄学，踩一次坑学一次。今天我来把这件事彻底讲透。
连接数到底怎么算出来的？
很多人配置连接池，最大连接数张口就是 50、100、200，仿佛在买彩票。
实际上有一个公式：
最佳连接数 ≈ CPU 核心数 × 有效线程数 × (1 / 单请求阻塞系数)
对于典型的 CRUD 应用：
- 单请求阻塞系数大约 0.7（30% 时间在 CPU，70% 在等 I/O）
- 4 核 CPU，有效线程数 2（保守）
- 最佳连接数 ≈ 4 × 2 × (1/0.7) ≈ 11
但如果你用连接池做长连接查询，或者数据库在另一台机器上（网络延迟 1-5ms），这个数字就完全不一样了。
更关键的是：连接池配置的参照物永远是你的数据库最大连接数上限。PostgreSQL 默认 max_connections=100，MySQL 默认 151。你一个应用就占了 500，数据库直接原地爆炸。
-- PostgreSQL 查看当前连接数
SELECT count(*) FROM pg_stat_activity;
-- MySQL 查看
SHOW STATUS LIKE 'Threads_connected';
-- 查看最大允许连接数
SHOW VARIABLES LIKE 'max_connections';
那些年我们踩过的连接池坑
坑一：最小连接数设成 0，等于每次重启都是一场灾难
有些同学觉得"初始连接数设为 0 环保"，结果每次服务启动后，第一个请求要等 3-5 秒建立连接。对于一个高并发 API，这 3-5 秒就是一场小型雪崩。
正确做法：最小连接数至少等于预期并发量的 10%-20%，保证预热。
坑二：最大连接数设太大，等于在给数据库上刑
连接不是越多越好。每条连接都要占用数据库内存（MySQL 每条连接约 4-10MB），还要数据库端维护会话状态、锁表、MVCC 快照等。
当连接数超过数据库处理能力时，新的请求在排队——表面上接口还活着，实际上已经慢到用户骂街。
坑三：连接超时和查询超时傻傻分不清
connectionTimeout 和 socketTimeout 是两码事：
- connectionTimeout：等获取连接的时间，超过就报超时异常
- socketTimeout：查询执行时间，超过就断连接
我见过有人把 socketTimeout 设成 0（无限等待），然后数据库卡住时整个服务 hang 死。永远不要把 socketTimeout 设为 0，这是给自己埋的定时炸弹。
坑四：连接池满了就加连接，不找根本原因
这是最蠢的操作。当连接池频繁满载，正确的排查顺序是：
- 慢查询是否增多？（加索引、优化 SQL）
- 事务是否长时间不提交？（检查代码是否有死锁、长事务）
- 连接是否泄漏？（有没有 finally 里没 close 的代码）
- 业务并发量是否真的需要那么多连接？（考虑读写分离、分库分表）
加连接池上限是最后手段，不是首选方案。
连接泄漏：那个你可能每天都在犯但不自知的 bug
连接泄漏是生产环境最常见的连接池问题之一。典型场景：
Connection conn = dataSource.getConnection();
try {
// 业务逻辑
if (someCondition) {
return; // 提前 return，conn 没 close！
}
// 更多业务逻辑
} finally {
conn.close(); // 正常情况下关了
}
这个问题听起来很简单，但实际项目中，我见过无数人踩坑：异常分支、提前 return、多层嵌套 try-catch 导致 finally 逻辑混乱。
更隐蔽的泄漏场景——连接未正常归还：
// 线程池 + 连接池混用的经典死亡组合
CompletableFuture.runAsync(() -> {
Connection conn = dataSource.getConnection();
// 异步操作，没等执行完线程就归还了
// conn 实际没 close，但 conn 对象在另一个线程里已经"丢失"
});
怎么检测泄漏？定期打印连接池活跃数和空闲数，设置告警阈值：
// HikariCP 为例
HikariDataSource ds = (HikariDataSource) dataSource;
logger.info("活跃: {}, 空闲: {}, 等待: {}, 总体: {}",
ds.getHikariPoolMXBean().getActiveConnections(),
ds.getHikariPoolMXBean().getIdleConnections(),
ds.getHikariPoolMXBean().getThreadsAwaitingConnection(),
ds.getHikariPoolMXBean().getTotalConnections());
如果活跃数持续等于最大连接数，而空闲数长期为 0，恭喜你——连接泄漏或者严重并发过载。
真实的连接池调优案例
去年帮一个电商团队做性能优化，他们的订单接口 P99 延迟 8 秒。
排查过程：
- 慢 SQL 日志：无明显异常
- CPU/内存：正常
- 连接池监控：活跃连接数恒定在 50（最大连接数 50），等待队列在排队
问题找到了——他们的最大连接数只有 50，但 Tomcat 线程池 maxThreads 是 200。相当于 200 个人排队等 50 把椅子。
调优方案：
- 数据库最大连接数上限：150
- 应用连接池最小：30，最大：120
- Tomcat maxThreads：150（线程不是越多越好，太多上下文切换反而拖慢）
- 核心线程数：50
结果：P99 从 8 秒降到 200 毫秒。团队表示之前找错方向了，以为是 SQL 问题。
核心教训：连接池配置必须和线程池配置、业务并发量三者联合起来看，不能单独调任何一个。
给不同场景的推荐配置
没有银弹，但有几个参考区间：
| 场景 | 最小连接数 | 最大连接数 | 备注 |
|---|---|---|---|
| 低并发 API（QPS < 50） | 5 | 20 | 瓶颈不在连接池 |
| 中等并发 API（QPS 50-500） | 连接等待时间 / 单查询耗时 | CPU核数×线程数/阻塞系数 | 需要实际压测 |
| 高并发短查询 | 最大连接数的 30% | 数据库 max_connections 的 60-70% | 避免超过数据库承载 |
| 长连接/大查询场景 | 较小 | 极保守设置 | 单查询占用连接时间长 |
connectionTimeout 我建议设 30 秒，socketTimeout 设 60 秒，嫌不够可以调，但要清楚自己在干什么。
监控才是终极奥义
配置再合理，不监控等于盲人摸象。连接池一定要接入监控：
- HikariCP 可以通过 JMX 暴露指标，接入 Prometheus/Grafana
- Druid 自带监控页面，虽然丑但管用
- 告警规则：活跃连接数 / 最大连接数 > 80% 持续 5 分钟，立刻通知
我见过太多团队上线前豪情壮志，上线后监控空空如也。等故障来了才发现："原来连接池一直在告警，但我们不知道。"
最后说几句
连接池这个话题，十年过去了，面试还在问，踩坑的人还在踩。不是因为它多复杂，而是太多人愿意花时间学新框架，却不愿意把手上常用的东西搞清楚。
花半小时读一下你用的连接池（HikariCP/Druid/DBCP）的源码和官方调优文档，比你加一周班调什么 SQL 都有用。
记住：工具不是玄学，配置不是玄学，你不懂的时候才是玄学。下次再遇到性能问题，别急着加机器，先看看连接池监控。
共勉。
