jedispool不自动处理主从切换或断连重连，需应用层干预；卡住主因是连接池耗尽或失效连接未剔除，而非未重连。
JedisPool 本身不自动处理主从切换或同步断开后的重连，必须靠应用层主动干预；单纯依赖 JedisPool.getResource() 拿连接，遇到主从切换失败时大概率抛出 JedisConnectionException: Could not get a resource from the pool。
为什么 JedisPool 拿不到连接就卡住？
根本原因不是“没重连”，而是连接池已耗尽或连接不可用却未被及时剔除。常见场景包括：
- 主从切换期间，旧主节点下线、新主节点尚未完成选举或地址未更新，
JedisPool仍指向原 host:port，所有getResource()请求都在等一个永远连不上的地址 -
JedisPoolConfig中setBlockWhenExhausted(true)（默认值）+setMaxWaitMillis(2000)，连接池满或全失效时会阻塞 2 秒后才抛异常，业务线程直接卡住 - 连接池里残留了已断开但未验证的连接（比如 TCP FIN 后未触发
testOnBorrow），getResource()返回后一用就崩
testOnBorrow 和 testOnReturn 不是万能的
开启这两个参数确实能在借/还时做 PING 检测，但有明显局限：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检测仅针对单次连接，无法感知整个集群拓扑变化（例如主从角色互换、哨兵地址变更）
- 如果 Redis 实例处于“假活”状态（如只读中、正在加载 RDB、replication backlog 耗尽），
PING成功但后续SET/GET仍失败 - 频繁
PING增加网络和 Redis 负载，尤其在高并发写场景下可能放大延迟 - 默认
testOnBorrow=false，很多项目压根没开——等于裸奔
真正有效的重连策略：按场景分层应对
不能指望一个通用 getResource() 包打天下，要区分读/写/订阅三类操作：
-
写操作（
SET/HSET等）：必须确认连接指向当前主节点。建议在初始化时通过INFO replication或ROLE命令校验角色，失败则刷新JedisPool实例（注意：不能复用旧JedisPoolConfig，需重建） -
读操作（
GET/HGETALL）：可容忍短暂从节点延迟，但需捕获JedisConnectionException并 fallback 到备用地址（如哨兵地址或 DNS 解析的新 VIP） -
订阅（
psubscribe）：必须用while(true)循环包裹，每次异常后close()当前Jedis，sleep 1s 后重新getResource()—— 因为psubscribe是阻塞调用，断开后不会自动重入
最容易被忽略的配置项：setMinEvictableIdleTimeMillis 和 setTimeBetweenEvictionRunsMillis
这两个参数决定空闲连接多久被驱逐、多久检查一次。若设置不合理，会导致：
-
setMinEvictableIdleTimeMillis=30000（30秒），但 Redis 的timeout配置是 60 秒 → 连接池提前把“还健康”的连接干掉，造成无谓重建 -
setTimeBetweenEvictionRunsMillis=-1（默认关闭）→ 空闲坏连接永远留在池里，直到被借出才暴露问题 - 推荐组合：
setMinEvictableIdleTimeMillis(60000)+setTimeBetweenEvictionRunsMillis(30000)，略大于 Redistimeout值即可
