connected_clients持续上涨是redis连接泄露的最直接信号；需多次执行info clients观察趋势，结合client list查idle过大或来源集中的异常连接，并检查lettuce手动获取连接是否漏close、pub/sub是否未显式关闭、client_name是否缺失导致定位困难。
connected_clients 持续上涨，基本就是连接泄漏了——别等服务挂了才看。
怎么看 connected_clients 是否真在涨
只跑一次 INFO clients 没用，得盯趋势。用下面命令隔 30 秒连查三次：
redis-cli -a yourpass INFO clients | grep connected_clients sleep 30 redis-cli -a yourpass INFO clients | grep connected_clients sleep 30 redis-cli -a yourpass INFO clients | grep connected_clients
如果数值从 102 → 108 → 115 这样稳定爬升，尤其在低流量时段也涨，大概率是泄漏。注意区分压测、主从切换或网络抖动引起的瞬时突增，要结合业务日志时间点交叉比对。
用 CLIENT LIST 定位异常连接来源
CLIENT LIST 输出每行一个连接，关键字段要盯住这四个：
-
addr：看是不是集中来自某台应用机器（比如全是10.20.30.41:56789） -
idle：值大于 3600 秒的连接，大概率是“借出去没还” -
age：超过几小时还活着，且idle也高，基本是僵尸连接 -
cmd：最后执行的是SUBSCRIBE或空（cmd=），要特别小心——Pub/Sub 连接不显式Close()就不会释放
快速筛出可疑连接的命令：
redis-cli -a yourpass CLIENT LIST | awk '$5 > 3600 {print $2,$5,$6,$18}' | head -20
输出里 $2 是 addr，$5 是 idle，$6 是 age，$18 是 cmd。
Spring Boot 项目里最容易漏关的三类连接
Lettuce 默认复用连接，但以下场景仍会新建连接且不自动回收：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 手动调用
redisConnectionFactory.getConnection()后，没调close()——Jedis 和老版 Lettuce 都容易踩 - 用
RedisTemplate.execute()传自定义RedisCallback，在回调里 new 了StatefulRedisConnection却没 close - 订阅场景：
redisTemplate.listen()或redisClient.subscribe()返回的ChannelMessageListener/PubSubConnection必须显式close()，不能只靠 GC
尤其注意：Lettuce 的 StatefulRedisPubSubConnection 关闭必须调 close()，不是 disconnect()，后者只是断开网络，连接对象还在池里占位。
加 client_name 让来源一目了然
光看 addr 不够准，多实例部署时 IP 相同。用 client_name 给每个客户端打标：
Spring Boot 2.3+ 配置里加：
spring:
redis:
lettuce:
client-name: ${spring.application.name}-${server.port}
或代码里初始化 RedisClient 时传参：
RedisClient.create(RedisURI.create("redis://:pwd@localhost:6379"))
.setOptions(ClientOptions.builder()
.socketOptions(SocketOptions.builder().connectTimeout(Duration.ofSeconds(3)).build())
.generalOptions(GeneralOptions.builder().clientName("order-service-8081").build())
.build());
之后 CLIENT LIST 的 name 字段就带上了标识，排查时直接 grep order-service-8081 就能锁定问题模块。
真正难搞的不是发现泄漏，而是确认哪段代码没关连接——client_name + idle + cmd 三者合起来，才能把问题钉死到具体服务、具体线程、具体操作上。
