连接池耗尽本质是连接被卡住未归还或池子过小，需聚焦现象确认、泄漏排查、配置验证三点：查日志中“Connection is not available”等错误，监控活跃=最大、pending>0、idle=0即确认耗尽；用jstack定位停在getConnection的线程，重点检查事务内外部调用、未关闭资源、异步任务泄漏；核对maxPoolSize是否匹配QPS×响应时间，避免默认值过小。
连接池耗尽异常不是数据库或Redis服务挂了，而是应用端“拿不到连接”——本质是连接被卡住、没还回去，或者池子太小扛不住流量。快速定位要聚焦三点：现象确认、泄漏排查、配置验证。
看日志和监控，先确认是不是真耗尽
别一看到报错就开查代码。先看两类关键信号：
- 日志里有没有 “Cannot get Jedis connection” 或 “HikariPool-1 - Connection is not available” 这类明确提示获取失败的错误；注意堆栈是否集中在
getResource()或getConnection() - 如果有监控（如Druid控制台、HikariCP的JMX指标），直接查实时数据：
活跃连接数 = 最大连接数，
等待连接的线程数 > 0，
空闲连接数长期为 0
满足这三条，基本就是池子真打满了。
抓线程堆栈，找谁在“占着不还”
连接没归还，通常意味着某段代码卡住了或漏写了释放逻辑。最直接的办法是抓当前线程快照：
- 执行
jstack，搜索关键词 “getResource”、“getConnection”、“await”，看哪些线程停在获取连接那一步，再顺着堆栈看调用方是谁> thread.log - 特别关注是否在事务中执行了慢SQL、大KEY操作、外部HTTP调用，或者有未捕获异常导致
finally块没执行 - 如果用了 try-with-resources，确认Jedis/Connection对象确实是通过池子获取的（不是手动 new 的），且没有被缓存复用
查代码里高频路径，盯紧资源释放点
重点扫这些地方，80% 的泄漏藏在这里：
- 所有
pool.getResource()或dataSource.getConnection()调用，必须配对close()，且放在finally或 try-with-resources 中；禁止在 if/else 分支里只写一半 - 事务方法（
@Transactional）里嵌套了数据库操作 + Redis 操作，但 Redis 报错后事务没回滚，连接被持有直到超时 - 流式处理或分页查询场景：ResultSet 或 JedisCursor 没关闭，间接导致底层连接无法释放
- 异步任务（如
CompletableFuture或线程池提交）中使用了连接，但异常吞掉、没做兜底关闭
核对连接池参数，排除配置过小
默认配置（比如 HikariCP maxPoolSize=10，Jedis maxTotal=8）在稍有并发的接口下几秒就打满。快速检查项：
- 当前最大连接数是否小于预估峰值QPS × 平均响应时间（秒）？例如 QPS=200，平均耗时 200ms → 理论需至少 40 个连接
- 获取连接超时时间（
connection-timeout或maxWaitMillis）是否设得太短（如 500ms）？太短会导致快速失败掩盖真实瓶颈 - 开启连接池健康统计：定期打印
getNumActive()、getNumIdle()、getNumWaiters()，观察趋势比单次值更有价值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
