连接池：我见过最冤的背锅侠，替无数烂代码背了多年黑锅
先问个问题：如果你的数据库开始报 too many connections，你第一反应是什么？
大概率是骂连接池配置太小了对吧。毕竟这个词听起来就很“池”，小了就装不下，装不下就溢，溢了就报错。逻辑完美，童叟无欺。
但我今天要说一句很多人不爱听的话：连接池配置99%的时候不是问题的根源，它只是第一个被发现症状的倒霉蛋。
真正让连接池背锅的，是你们系统里那些写得很烂的数据库操作，以及某些团队祖传的神秘配置。
你以为连接池是在“管”连接？不，它是在“等”连接
很多人对连接池的理解是这样的：数据库有一堆连接，我建个池子，用的时候从池子拿，用完了还回去。看起来很合理对吧？
但理解错了。
连接池的核心问题从来不是有没有连接，而是连接能不能及时归还。
你池子再大，如果每个请求拿到的连接平均要30秒才还回来，那池子再大也是坐等爆雷。为啥30秒？因为你的SQL跑了28秒，因为你的代码里藏了个 Thread.sleep(25000)，因为你打开连接查完数据之后还在那里搞一堆业务逻辑才close。
连接池就像共享单车，用的人多了不怕，怕的是每个人骑完了不锁，就这么推着走。自行车再多也扛不住这种用法。
那些年，我们一起踩过的连接池大坑
坑1：最大连接数配置得跟玄学似的
我见过最离谱的配置是这样的：数据库最大连接数设了200，应用连接池最大连接数也设了200。看起来很对称对吧？
但问题是，应用不止一个实例啊。四个实例各200，加起来800，数据库扛得住吗？
还有一种情况：测试环境数据库最大连接数设了50，生产设了200，结果代码在测试环境跑得好好的，上生产疯狂报错。一查，连接池设的最小50，最大200——等等，最小50？测试环境数据库只能扛50，你最小连接数就设50，等于一开始就占满，别的请求来了只能排队，排队超时直接爆炸。
最小连接数不是“保底”，是“起手就梭哈”。这个概念搞不清楚，连接池永远配不明白。
坑2：连接泄漏——不是不还，是忘了还
连接泄漏是连接池的头号敌人。但我见过的情况不是“故意不还”，而是“真的忘了”。
典型场景：
public void getUserById(String id) {
Connection conn = dataSource.getConnection();
// 查数据库
ResultSet rs = conn.prepareStatement("SELECT * FROM users WHERE id=?").executeQuery();
// 处理业务逻辑
doSomethingWith(rs);
// 草，好像忘记 close() 了
}在异常情况下更惨：
public void doSomething() {
Connection conn = null;
try {
conn = dataSource.getConnection();
// 业务逻辑
if (something) throw new RuntimeException("业务异常");
} finally {
// 好一点的代码会在这里close
// 但我见过太多连finally都没有的
if (conn != null) conn.close();
}
}try-finally都不敢保证你每次都走得到。如果有多个return路径，有嵌套的try-catch，总有那么一两个路径你是拿不到连接的。
正确姿势：用框架。用连接池框架。MyBatis、Hibernate、Spring JDBC Template，哪个不比手写conn强。这些框架替你管连接的生命周期，出了问题也能很快定位。手写JDBC不是不行，是你写完三个月之后自己都看不懂了。
坑3：长事务——连接池的慢性毒药
这个坑极其隐蔽，因为它的症状不是一下子爆出来，而是慢慢累积，等你发现的时候已经晚了。
什么叫长事务？就是一个请求拿着连接不放，开始干一堆事情：调第三方API、发消息、写本地文件、回滚重试。一套下来，10秒起步，30秒正常，60秒也不是没可能。
连接池的连接就这么被慢慢耗尽。你说加机器？加池子大小？可以，但这是打吗啡，不是治病。
真正的治法是：控制每个事务的时长，超时强制释放。数据库连接不是什么稀缺资源，它是一种需要高效周转的资源。你占有它的时间越长，系统整体吞吐越低。1秒能释放的连接，被一个10秒的事务占着，系统吞吐量就直接打了个1/10。
给所有涉及数据库的操作都加上超时配置，这是铁律。查数据超时、事务超时、能多久就多久——对不起，应该反过来，能多短就多短。数据库操作从来不应该超过5秒，超过就说明你的SQL要优化，或者你的架构要重构。
连接池配置的万能公式
说了这么多坑，终于到实操环节。连接池到底怎么配？
我给一个经过实践验证的万能公式，适用于大多数Java技术栈（HikariCP为例）：
maximumPoolSize = (核心数 * 2) + 磁盘数
minimumIdle = maximumPoolSize / 2
connectionTimeout = 30000 (30秒)
idleTimeout = 600000 (10分钟)
maxLifetime = 1800000 (30分钟)
但这只是起点，不是终点。真正科学的配法是：
第一步，先用最小配置跑，压测看数据库实际能扛多少并发。第二步，逐步加大连接池大小，同时观察RT和错误率。第三步，找到RT开始上升、错误率开始增加的那个点，倒推回来，取那个值80%作为最终最大连接数。
为什么要80%？留buffer。流量有波动，业务有峰值，你不能把数据库跑满，至少留20%应对突发。
另外，不同环境的配置必须不同。测试环境数据库可能只有生产1/5的容量，你的测试配置不能抄生产，不然测了个寂寞。
监控才是连接池的正确打开方式
讲了这么多配置，但最重要的事情还没说：你必须监控你的连接池。
哪些指标？
- 活跃连接数：当前正在被使用的连接有多少。这个值如果长期接近最大连接数，说明系统在极限边缘试探。
- 空闲连接数：池子里闲置的连接有多少。如果经常为0，说明最小连接数设低了，或者连接归还不及时。
- 等待获取连接的线程数：拿不到连接要排队的请求有多少。这个值如果大于0，说明连接不够用了。
- 连接获取耗时：从请求连接到拿到连接要多久。正常应该小于10毫秒，超过100毫秒说明有问题。
- 连接创建/销毁速率：每秒创建多少连接，销毁多少。如果创建速度很高，说明连接周转太快，要么是泄漏，要么是池子太小。
没有监控的连接池就像没有仪表盘的汽车，你知道你在开，但你不知道油还剩多少、水温多少、转数多少。开久了迟早抛锚。
最后说两句
连接池这个东西，看起来简单，但它的复杂性在于：它不是你自己写的代码，所以你的代码里任何一个不经意的操作，都可能在它身上产生蝴蝶效应。
一个没关的连接、一个超长的SQL、一个没有超时的第三方调用、一个catch之后静默吞掉的异常——这些东西单独看都不致命，但它们叠加在一起的时候，连接池就成了背锅侠。
所以下次系统出问题了，别急着骂连接池。先看看自己的代码，问自己三个问题：连接有没有及时归还？SQL有没有超时控制？事务有没有最小化？
如果这三个问题的答案都是“我看看”或者“应该是有的”，那你骂连接池的时候，手可能需要抖一下——因为大概率是你自己的问题。
好了，今天的分享就到这里。写代码不规范的朋友，建议把这篇文章转发给你们团队 Leader，看看能不能申请点时间做重构。连接池的锅背了这么多年，也该歇歇了。
