redis连接池耗尽异常本质是应用无法从jedis连接池获取可用连接，主因是连接泄漏、未及时归还或配置不合理；需确保每次getresource()后必调close()（推荐try-with-resources），并合理调优maxtotal、maxwaitmillis等参数。
Redis连接池耗尽异常（如 JedisConnectionException: Could not get a resource from the pool）本质是应用无法从Jedis连接池获取可用连接，常伴随 System.out 打印堆栈或日志中出现 JedisException。核心原因不是Redis服务宕机，而是连接被长期占用、泄漏或配置不合理。
检查连接是否未正确释放
这是最常见原因：Jedis对象使用后未调用 close() 或未在 try-with-resources 中管理。
- Jedis实例不是线程安全的，每次操作应获取新连接、用完立即归还；不要缓存或复用Jedis对象
- 确保所有
Jedis jedis = pool.getResource()都有对应jedis.close()（等价于pool.returnResource(jedis)），且放在finally块中 - 推荐改用
try-with-resources（需Jedis 3.0+，且Jedis实现AutoCloseable）：try (Jedis jedis = pool.getResource()) { jedis.set("key", "value"); } // 自动 close，归还连接
验证连接池配置是否合理
默认配置（如 maxTotal=8）在高并发下极易打满，需结合业务压力调整。
- 关键参数示例（使用
JedisPoolConfig）： maxTotal：最大连接数（默认8），建议设为预估并发请求数 × 1.5～2倍
maxIdle：最大空闲连接数，通常设为maxTotal的 70%～100%
minIdle：最小空闲连接数，避免频繁创建销毁，可设为maxTotal的 20%～30%
blockWhenExhausted=true（默认true）：池耗尽时阻塞等待而非直接抛异常（便于观察等待时间）
maxWaitMillis：最大阻塞等待毫秒数，超时抛异常，建议设为 1000～3000 - 启用连接池监控：通过
pool.getNumActive()、pool.getNumIdle()、pool.getNumWaiters()在健康接口或日志中输出，实时观察连接使用趋势
排查长连接占用与超时设置
连接被长时间占用（如大KEY扫描、网络延迟、慢查询）会导致连接“卡住”，无法及时归还。
- 检查Redis命令执行是否超时：设置
JedisPool构造参数中的timeout（单位毫秒），建议socketTimeout和connectionTimeout均设为 2000～5000，避免单次请求拖垮整个池 - 禁用
soKeepAlive=false（默认false）——不开启TCP保活，避免连接假死；但若网络不稳定，可尝试设为true并配合合理tcpKeepAlive时间 - 使用
redis-cli --latency或redis-cli -p 6379 --intrinsic-latency 5检测服务端响应延迟，排除Redis自身性能瓶颈
确认是否有连接泄漏的代码路径
某些异常分支（如catch块中未close）、异步任务、Stream操作、Lambda表达式内使用Jedis，都容易遗漏资源释放。
- 全局搜索代码中
pool.getResource()出现位置，逐个核对是否均有close()或 try-with-resources - 特别注意：Spring Boot中若混用
JedisConnectionFactory和手动JedisPool，可能因模板类自动管理导致重复释放或未释放 - 开启Jedis日志（logback/log4j配置
org.apache.commons.pool2.impl.GenericObjectPool为 DEBUG 级），查看池的 borrow/return 日志，定位未归还连接的操作点
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
