短连接频繁创建必须停，因其每次connect()+auth+select+close()开销达1–3ms，比get慢5–10倍，导致cpu卡在系统调用和上下文切换；连接数超200后，jvm线程调度与gc压力陡增，且linux临时端口耗尽引发cannot assign requested address错误。
短连接频繁创建必须停，这不是调参能救的——每次 connect() + AUTH + SELECT + close() 的开销在局域网下就达 1–3ms，比 GET 命令还慢 5–10 倍，CPU 会卡在系统调用和上下文切换上。
为什么短连接会让 Redis 客户端 CPU 飙升
每次 new Jedis() 都要走完整 TCP 三次握手、SSL（如果启用）、AUTH、SELECT DB，这些全在用户态完成。压测时常见 sys 时间占比超 60%，不是 Redis 慢，是客户端在反复“开门关门”。更隐蔽的问题是：连接数 > 200 后，JVM 线程调度压力上升，GC 频率也被带高；服务端虽不拒连，但客户端本地 TIME_WAIT 堆积会导致 Cannot assign requested address 错误——因为 Linux 默认临时端口仅约 28,000 个，按 60 秒回收周期，理论极限并发才约 466 QPS。
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（如 30000）定期探活 -
blockWhenExhausted：建议true，并配maxWaitMillis（如 2000），比抛JedisConnectionException更可控
拿连接、用连接、还连接，三步漏一环就泄漏
看似简单，但生产环境 70% 的连接泄漏都出在这三步：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 取连接必须用
jedisPool.getResource()，不是new Jedis() - 用完必须归还：推荐
try-with-resources（Jedis实现了AutoCloseable），内部自动判断是否损坏并归还或标记 - 发生异常时不能只
catch：连接可能已断，得调returnBrokenResource()（新版close()已自动处理）
错误示例：try (Jedis jedis = jedisPool.getResource()) { jedis.set("k","v"); } ✅ 正确：close() 内部会归还或标记损坏。
连接池没生效？先查这三个硬伤
监控里还看到大量 connect 系统调用，大概率是：
- 多个
JedisPool实例共存：Spring Boot 默认每声明一个@Bean JedisPool就新建一个池，必须确保全局单例（加@Scope("singleton")或直接static） - 代码里混用了
new Jedis()：grep 全项目，删干净 - 旧连接没关就 new 新池：尤其在单元测试或配置热加载场景下，老池未
close()就初始化新池，资源持续泄漏
真正难的不是配参数，而是让所有代码路径都走同一套获取-使用-归还逻辑——哪怕一个定时任务、一个异步线程、一个异常分支漏掉，池就形同虚设。
