连接池耗尽是生产环境中最常见的数据库故障之一，典型表现是应用日志突然刷出大量获取连接失败的异常，接口响应时间从几十毫秒飙升到几十秒，最终整批请求超时失败。要彻底解决这类问题，光靠调大连接池容量只是治标不治本，必须从连接复用机制和超时参数两方面入手，让每一个借出去的连接都能按时归还，让池子本身具备自我清理的能力。
先弄清楚连接池为什么会耗尽
连接池的核心逻辑很简单：初始化时创建若干数据库连接放进池子里，业务代码需要访问数据库时从池中借出一个连接，用完之后归还。问题在于，如果借出去的连接迟迟不归还，池子里的连接就会被一点点占光，后续请求只能排队等待。
导致连接不归还的原因主要有三类。第一类是代码层面忘记释放，比如使用完Connection之后没有调用close方法，或者在异常分支中遗漏了释放逻辑。这类问题在try-catch写得混乱的老代码里特别常见。第二类是长事务，一个方法里开启了事务，中间又调用了外部接口或者执行了耗时计算，事务持有连接的时间远超预期，高并发场景下池子很快就被拖垮。第三类是配置层面的缺陷，比如连接的最大存活时间设置得比数据库端的连接超时时间长，数据库那边已经把连接断掉了，连接池还拿着失效的连接给业务用，请求失败后反复重试，进一步加剧连接占用。
排查时可以先从监控入手。如果使用的是Druid，可以通过内置的监控页面查看ActiveCount、WaitThreadCount等指标；如果使用HikariCP，可以开启JMX或者接入Micrometer观察connection pending的状态。WaitThreadCount持续大于零说明已经有线程在排队等连接，这是连接池接近耗尽的直接信号。
连接复用：从代码层面杜绝泄漏
解决连接泄漏最根本的手段是保证连接在任何路径下都能被释放。传统的JDBC代码需要手动在finally块中关闭连接，稍微疏忽就会出问题：
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try {
conn = dataSource.getConnection();
ps = conn.prepareStatement("select id, name from user where id = ?");
ps.setLong(1, userId);
rs = ps.executeQuery();
while (rs.next()) {
// 处理结果
}
} finally {
// 无论是否发生异常都必须释放，且关闭顺序不能乱
if (rs != null) rs.close();
if (ps != null) ps.close();
if (conn != null) conn.close();
}从连接池的角度看，调用close并不是真正关闭底层连接，而是把连接归还给池子，这也是连接复用的关键机制。理解了这一点就会明白，频繁创建和销毁DataSource同样是错误做法，DataSource应该在应用启动时初始化一次，全局共享。有些团队在工具类里每次都new一个连接池对象，用完销毁，这等于完全放弃了复用，性能极差还容易把数据库的连接数打满。
更现代的做法是使用try-with-resources语法，让编译器自动生成释放逻辑：
String sql = "update account set balance = ? where id = ?";
try (Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql)) {
conn.setAutoCommit(false);
ps.setBigDecimal(1, newBalance);
ps.setLong(2, accountId);
ps.executeUpdate();
conn.commit();
} catch (SQLException e) {
// try-with-resources会在异常前自动关闭conn，连接正常归还池中
throw new RuntimeException("更新账户失败", e);
}如果使用Spring框架，配合@Transactional注解可以把事务管理完全交给框架，业务代码只需要关注SQL本身，连接的获取和归还由Spring的事务同步机制自动完成，这是目前最推荐的写法，基本可以杜绝人为疏忽造成的泄漏。
超时参数配置：让连接池具备自我修复能力
超时参数是连接池配置中最容易被忽视的部分，很多人只设置了最大连接数就不再管了。实际上，一套合理的超时配置能让连接池在出现问题时快速暴露故障、自动剔除坏连接，而不是让请求无限期挂死。
以HikariCP为例，几个核心参数的含义必须区分清楚。connectionTimeout是获取连接的最长等待时间，默认30秒，建议根据业务容忍度调整到几百毫秒到几秒之间，快速失败比长时间挂起对系统更友好。idleTimeout控制空闲连接的存活时间，一个连接闲置超过这个时长就会被池子移除。maxLifetime是连接的最大存活时间，超过后连接会被关闭重建，这个参数最重要的原则是必须小于数据库端或者网络中间件（比如MySQL的wait_timeout、负载均衡器的空闲超时）的连接超时时间，通常建议设置为数据库超时减去30秒到60秒，留出安全余量。
# HikariCP推荐配置示例 spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.minimum-idle=5 spring.datasource.hikari.connection-timeout=3000 spring.datasource.hikari.idle-timeout=600000 spring.datasource.hikari.max-lifetime=1500000 spring.datasource.hikari.leak-detection-threshold=60000
特别值得一提的是leak-detection-threshold这个参数，开启后如果某个连接被借出超过设定时长还未归还，HikariCP会在日志中打印持有该连接的堆栈信息，直接指出是哪行代码没有释放连接。排查线上连接泄漏时，这个参数往往能在几分钟内定位到问题代码，效率远高于人工翻代码。建议在生产环境长期开启一个合理的阈值，比如60秒。
连接池大小也不是越大越好。根据实践经验，连接数并非与并发能力成正比，过多的连接会加剧数据库上下文切换的开销。一个常用的估算公式是：连接数约等于CPU核心数乘以2加上有效磁盘数。对于大多数部署在SSD上的服务，20到50个连接已经足够支撑相当高的吞吐量。真正决定系统容量的是单次SQL的执行速度，慢查询才是吞噬连接的元凶，配合连接池治理的同时一定要审查慢SQL。
故障发生时的应急排查流程
当连接池耗尽已经发生时，可以按固定流程快速定位。第一步查看连接池监控指标，确认活跃连接数是否已经顶到最大值，以及等待线程数量。第二步检查数据库端的连接列表，比如MySQL执行show processlist，观察这些连接当前执行的SQL和状态，如果大量连接处于Sleep状态且来自应用服务器，大概率是应用侧没有归还连接；如果大量连接在执行同一条SQL，说明是慢SQL导致连接被长期占用。
-- 查看当前连接及执行状态 SHOW PROCESSLIST; -- 按状态统计连接 SELECT command, count(*) AS cnt FROM information_schema.processlist GROUP BY command;
第三步确认网络中间件的超时配置。不少公司的数据库前面有代理或负载均衡层，它们有各自的空闲连接超时，一旦这些超时小于连接池的maxLifetime，就会出现连接池拿着已被中间层断开的死连接去执行SQL的问题，表现为不定时的connection reset异常。这种情况的解决办法就是前面强调的原则：应用侧的连接存活时间要小于链路上任何一个环节的超时时间。
最后建立常态化的防护措施。给所有获取连接的操作加上明确的超时时间，避免线程无限阻塞；开启连接泄漏检测并接入告警；将连接池的关键指标接入监控系统，设置ActiveCount达到容量80%时的预警。这些手段组合起来，基本可以保证连接池耗尽的问题在演变成故障之前就被发现和处理。