connected_clients持续上涨即为连接泄露的最直接证据；需多次执行info clients观察趋势，结合client list查idle过大或来源集中的异常连接，并检查jedis手动获取是否漏close、lettuce是否误new客户端、线程是否阻塞在getresource。
connected_clients 持续上涨就是泄露，不是“可能”
Redis 服务端的 connected_clients 值只增不减，就是最硬的证据。别信“可能是压测残留”或“刚启动还没稳定”，隔 30 秒跑两次 redis-cli -a yourpass info clients，如果数值从 1200 → 1247 → 1295，基本可以判定存在连接未回收。Lettuce 默认开启 shareNativeConnection = true，意味着多数操作复用同一个底层 Netty 连接，理论上 connected_clients 应该稳定在个位数（比如 1～3）。一旦它持续上涨，说明要么连接池被绕过、要么共享机制失效、要么连接卡死在 borrowed 状态。
Lettuce 的 shareNativeConnection 是把双刃剑
Spring Boot 2.x+ 默认使用 Lettuce，且 LettuceConnectionFactory 构造时默认设 this.shareNativeConnection = true。这本意是让同一线程内多次 RedisTemplate 调用复用一个连接，避免频繁建连开销。但问题在于：
- 若你手动 new
LettuceClientConfigurationBuilder或自定义RedisConnectionFactory时没显式保留该配置，就可能退化为每请求新建连接 - 若业务中混用
RedisTemplate和直接调用connection.getStatefulConnection()，后者拿到的连接不会自动归还，极易泄漏 - 当线程阻塞（如数据库慢查、远程 HTTP 卡住），
shareNativeConnection会把连接长期 hold 住，CLIENT LIST里看到大量idle> 3600 的连接，来源全是同一台应用机器
验证方式：CLIENT LIST 后 grep idle=，挑几个 idle 超大的连接，看 addr 和 cmd 字段——如果全是 get/set 且地址集中，基本是业务线程卡死导致连接无法释放。
Jedis 手动拿连接却漏 close，是最常见的硬伤
哪怕项目主体用 Lettuce，只要某处代码写了 jedisPool.getResource()，就必须配 finally 或 try-with-resources。Jedis 3.x+ 的 close() 不是关 TCP，而是归还给池；Jedis 2.x 则必须用 returnResource()，否则连接永远滞留在 borrowed 状态。
典型翻车现场：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
public void bad() {
Jedis jedis = jedisPool.getResource(); // ← 这里已经借出
jedis.set("k", "v");
// 忘了 close！异常分支也漏了
}
正确写法只有两种：
try (Jedis jedis = jedisPool.getResource()) { ... }- 显式
finally块中判空调jedis.close()
注意：Spring 管理的 @Autowired RedisTemplate 安全，但一旦出现 StringRedisTemplate + JedisPool 混用，就极易在同一个 Service 方法里漏掉某一支的清理。
Redis server 端 timeout=0 是帮凶，不是背景板
很多团队忽略 Redis 自身的 timeout 配置。默认 config get timeout 返回 0，即永不主动断空闲连接。这意味着客户端即使崩溃、网络中断、JVM OOM，只要没发 FIN 包，Redis 就一直挂着这个连接，connected_clients 只涨不跌。
临时缓解可运行：config set timeout 120（单位秒），观察几分钟后连接数是否回落。但治本要配合客户端动作：
- 确保 Lettuce 连接池配置了
max-idle和min-idle，并启用驱逐检测：timeBetweenEvictionRunsMillis: 30000 - 若用 Jedis，必须设
testWhileIdle=true，否则空闲连接永远不会被探活和清理 - 网络不稳环境（如跨机房、K8s Node 间）务必加
so-keepalive=true，防止中间设备静默断连
真正难缠的泄漏，往往藏在定时任务、消息监听器（RedisMessageListenerContainer）、或异步线程池里——这些地方生命周期长、异常路径多、容易被测试覆盖遗漏。排查时优先 jstack 抓堆栈，搜 getResource 和 connect，看哪些线程卡在连接获取上不动了。
