Jedis常见问题核心是配置未对齐：socketTimeout和connectionTimeout需显式调大；JedisCluster需配置可路由IP、增大maxRedirections并规范key哈希；务必用try-with-resources防连接泄漏；避免滥用testOnBorrow，合理设置testWhileIdle与超时协同。
Connection timeout异常：不是网络问题，而是配置没对齐
Jedis抛JedisConnectionException: java.net.SocketTimeoutException: Read timed out，十有八九不是Redis服务器卡了，而是socketTimeout和connectionTimeout设得太小，尤其在高延迟网络或慢查询场景下。
默认值极不友好：connectionTimeout=2000ms、socketTimeout=2000ms，但实际生产中一次pipeline批量操作或含Lua脚本的请求，很容易超。
-
JedisPoolConfig里必须显式加大：setSocketTimeout(5000)、setConnectionTimeout(3000) - 如果用
JedisCluster，光改池配置不够——它内部每个Jedis实例还得单独设超时，得传GenericObjectPoolConfig+new JedisPoolConfig()再叠加JedisPool构造参数 - 别信“设成0就永不超时”，JVM GC停顿或网络闪断会导致连接假死，最终积压大量ESTABLISHED状态连接，触发Linux
net.ipv4.tcp_fin_timeout连锁反应
JedisCluster槽位错误：MOVED/ASK重定向失败的真正原因
遇到redis.clients.jedis.exceptions.JedisMovedDataException: MOVED 12345 10.0.1.5:6379，说明客户端缓存的槽位映射已过期，但JedisCluster本该自动重试——失败通常因为以下三点。
- 集群节点间
CLUSTER NODES返回的IP是内网地址（如10.0.1.5），而应用部署在公网或Docker容器里，根本连不通这个IP；解决方案是让Redis节点配置cluster-announce-ip为可路由地址 - 客户端初始化时没传
maxRedirections参数，默认值是5，但跨机房集群+多次ASK跳转可能突破该限制，需显式设为8或10 - 执行
EVAL等命令时，key哈希槽不一致（比如EVAL "return redis.call('get',KEYS[1])" 2 key1 key2），JedisCluster无法拆分路由，直接抛JedisClusterException而非重定向，这类必须改用{key}标签强制落在同一槽位
连接泄漏：close()调用时机比你想的更关键
Jedis对象不是线程安全的，且Jedis.close()不等于“释放连接”，而是把连接还给JedisPool。漏掉close()或在异常分支里没覆盖，池子里的连接数会缓慢上涨，直到maxTotal耗尽，新请求直接阻塞或抛JedisExhaustedPoolException。
立即学习“Java免费学习笔记（深入）”；
- 永远用
try-with-resources：Jedis实现了AutoCloseable，try (Jedis jedis = pool.getResource()) { ... }能确保无论是否异常都归还 - 别在
finally里写jedis.close()——如果jedis初始化失败（比如池已枯竭），变量是null，null.close()会触发NullPointerException -
JedisCluster例外：它本身不实现AutoCloseable，且内部连接由它自己管理，你只需保证JedisCluster.close()在应用退出时调用一次，平时不用手动关
超时与重试组合：别让Jedis替你做业务决策
很多人给JedisPoolConfig加setTestOnBorrow(true)，以为能提前发现坏连接。实际上这会让每次getResource()都发PING，在QPS高时显著拖慢获取速度，且掩盖了真正的连接老化问题。
- 更稳的做法是关掉
testOnBorrow，打开testWhileIdle+timeBetweenEvictionRunsMillis=30000，让空闲连接定期自检 - 对
SET、GET这类幂等操作，可在上层加最多1次重试（捕获JedisConnectionException后重试）；但对INCR、LPUSH等非幂等操作，重试等于重复执行，必须靠业务层加唯一ID或分布式锁兜底 - 集群模式下，
MOVED重定向本身已是Jedis内置重试，此时再包一层业务重试，可能造成两次重定向+两次命令执行，数据错乱风险陡增
槽位映射刷新、连接生命周期、超时阈值——这三件事互相咬合，改一个就得同步看另外两个。比如调大socketTimeout后，testWhileIdle的间隔也得相应延长，否则空闲连接还没等到被检测，就已经因超时被服务端断开了。
