Redis怎样排查Spring项目中的Redis连接泄露

connected_clients持续上涨是Redis连接泄露的最直接信号；需多次执行info clients观察趋势，结合CLIENT LIST查idle过大或来源集中的异常连接，并检查Jedis手动获取是否漏close、Lettuce是否误new客户端、线程是否阻塞在getResource。看 connected_clients 是否持续上涨这是最直接的信号：如果 Redis 服务端的连接数只增不减，基本坐实了泄露。用 redis-cli -a yourpass info clients 查看 connected_clients 字段，隔几十秒多跑几次，观察趋势。别只看一次——有些泄露是缓慢积累的，尤其低并发内部系统，可能几天才涨到几千。顺手再跑 CLIENT LIST，重点关注 idle 值极大（比如 >3600 秒）或 addr 来源集中在某台应用机器的连接。这些大概率是“借出去没还”的连接。运维常忽略一点：Spring Boot 默认启用 Lettuce 客户端，它底层是基于 Netty 的连接复用，connected_clients 上涨 ≠ 每次操作都建新连接，但若持续上涨，说明连接未被正确回收或连接池未生效如果用的是老项目配的 Jedis，connected_clients 几乎等于活跃连接数，上涨就更危险注意区分：连接数突增也可能是短时压测或主从切换重连风暴，要结合时间点和业务变更日志交叉判断查 Spring 中 RedisTemplate 或 Jedis 获取逻辑是否漏 closeSpring 管理的 RedisTemplate 本身不涉及手动释放，但一旦你绕过它、直接从 JedisPool 拿连接，就必须确保归还——哪怕在异常分支里。典型错误写法：public void badExample() { Jedis jedis = jedisPool.getResource(); try { jedis.set("key", "val"); } catch (Exception e) { log.error(e); // ? 忘了 close！连接永远卡在 borrowed 状态 }}正确做法必须带 finally 或用 try-with-resources：public void goodExample() { Jedis jedis = null; try { jedis = jedisPool.getResource(); jedis.set("key", "val"); } finally { if (jedis != null) jedis.close(); // ? 归还给池，不是销毁 }}jedis.close() 在 Jedis 3.x+ 中等价于 returnResource，不是关 TCP；Jedis 2.x 需显式调用 returnResource，否则会报错用 @Autowired RedisTemplate 是安全的，但若项目混用了 StringRedisTemplate + 手动 Jedis，容易在同一个 Bean 里漏掉清理特别警惕 RedisMessageListenerContainer：它内部持有一个长期连接，若配置了错误的重试策略（如无限重连），会在后台偷偷建大量连接抓线程堆栈看是不是卡在 Pool.getResource当应用变慢、CPU 不高但线程数飙升时，立刻 jstack <pid> > jstack.txt，然后搜 getResource：cat jstack.txt | grep 'getResource' | wc -l如果返回几百甚至上千，说明大量线程堵在取连接这一步——不是没连接可用，就是连接池满了，根源还是已有连接没归还。 唱鸭 音乐创作全流程的AI自动作曲工具，集 AI 辅助作词、AI 自动作曲、编曲、混音于一体