短连接导致Redis CPU飙升，因频繁TCP握手、SSL、AUTH等操作引发大量系统调用和上下文切换；JedisPool需合理配置maxTotal、minIdle/maxIdle、testOnBorrow、blockWhenExhausted四参数，并确保单例、正确获取/归还/关闭连接。
为什么短连接会让Redis CPU飙升
每次用 Jedis 直连 Redis 都要走 TCP 三次握手 + SSL（如果开了）+ AUTH 认证 + SELECT DB，这些操作全在用户态做，频繁新建连接会把 CPU 卡在系统调用和上下文切换上。压测时常见 sys 时间占比超 60%，不是 Redis 慢，是客户端在反复“开门关门”。
- 单次
Jedis构造函数调用 ≈ 1~3ms 开销（含 DNS 解析、Socket 初始化） - 连接数 > 200 后，JVM 线程调度开销明显上升，GC 频率也会被带高
- Redis 服务端本身不拒绝短连接，但
TIME_WAIT堆积会导致端口耗尽或连接失败
JedisPool 初始化必须设对的 4 个参数
JedisPool 不是开了就高效，几个关键配置设错反而比直连还慢。重点看这四个：
-
maxTotal：别盲目设大。默认 8 太小，但设到 200+ 可能挤占堆内存；建议按业务 QPS × 平均 RT（秒）× 1.5 估算，比如 1000 QPS × 0.02s × 1.5 ≈ 30 -
minIdle和maxIdle：保持minIdle == maxIdle更稳，避免空闲连接被回收又重建；设为maxTotal的 30%~50% 即可 -
testOnBorrow：必须false。每次取连接都PING一次，延迟直接翻倍；改用testWhileIdle+timeBetweenEvictionRunsMillis定期探活更轻量 -
blockWhenExhausted：建议true，配合maxWaitMillis（如 2000），比抛JedisConnectionException更可控
拿连接、用连接、还连接的三步不能错
写法看着简单，但漏掉任何一环都会导致连接泄漏或复用失效：
- 取连接必须用
jedisPool.getResource()，不是new Jedis() - 用完必须
returnResource()或更推荐的 try-with-resources（Jedis实现了AutoCloseable） - 发生异常时，不能只 catch 了事——
Jedis连接可能已断，得调returnBrokenResource()（新版用close()自动判断）
错误示例：
try (Jedis jedis = jedisPool.getResource()) {
jedis.set("k", "v");
} // ✅ 正确：close() 内部会归还或标记损坏
连接池没生效？先查这三处硬伤
明明配了 JedisPool，监控里还是看到大量 connect 系统调用，大概率是下面这几个地方出了问题：
- 多个
JedisPool实例共存：Spring Boot 默认每配一个@Bean JedisPool就新建一个池，应确保全局单例（加@Scope("singleton")或直接 static） - 忘记关闭旧连接：代码里混用了
new Jedis()和jedisPool.getResource()，旧连接没关，新池又建，双倍消耗 - 连接超时后未清理：
socketTimeoutMillis设太小（如 100ms），网络抖动就触发重连，池里大量半死连接；建议设为业务最大容忍延迟的 2 倍（如 500ms）
最简单的验证方式：在应用启动后执行 redis-cli client list | wc -l，稳定在 maxTotal 附近才说明池真正接管了流量。
池化不是银弹——连接复用省的是建立成本，但单次命令延迟、序列化开销、网络往返这些，还得靠 pipeline、二进制协议、读写分离来解。别指望一个 JedisPool 配置包治百病。
