连接Redis前必须确认JedisPool配置正确、Redis服务端已启用认证且绑定正确网卡、客户端防火墙未拦截6379端口；需用telnet或redis-cli测试连通性，并确保bind和protected-mode配置适配访问场景。
连接Redis前必须确认的三件事
Jedis不是开箱即用的“连上就跑”，连不上、连得慢、连着连着断，八成是卡在这三个地方：JedisPool没配对、Redis服务端没开认证或绑定错网卡、客户端防火墙/网络策略拦了6379端口。别急着写set，先用telnet 127.0.0.1 6379或nc -zv 127.0.0.1 6379测通不通。Linux下redis-cli -h 127.0.0.1 -p 6379 ping返回PONG才算真正就绪。
- Redis默认只监听
127.0.0.1，远程连接要改bind配置或注释掉，同时关掉protected-mode yes - 如果Redis启用了密码（
requirepass），JedisPool构造时必须传password参数，漏了会报NOAUTH Authentication required - Jedis默认不支持SSL，用阿里云等托管Redis时若强制SSL，得换
JedisSslPool或加ssl=true参数（4.0+版本）
字符串操作：别直接new Jedis，用try-with-resources包住
手写new Jedis()是典型反模式——连接不归还池子，几轮请求后JedisPool就耗尽，报Could not get a resource from the pool。所有get/set必须走JedisPool.getResource()，且务必释放。
try (Jedis jedis = jedisPool.getResource()) {
jedis.set("user:1001", "alice");
String name = jedis.get("user:1001");
}
// 自动调用 jedis.close()，归还连接
-
jedis.close()不是销毁连接，而是归还给池；手动调用destroy()才真关掉 - 不要在
finally里close()——try-with-resources已覆盖；重复close可能抛JedisConnectionException -
set带过期时间用set(key, value, SetParams.setParams().ex(3600))，别用老式setex，后者不支持NX/XX等条件
哈希操作：hgetall返回Map但值全是byte[]
jedis.hgetAll("user:1001")看着像能直接用，实际返回的是Map<byte byte></byte>，Java里直接toString会是乱码[B@3a71f4dd。这不是bug，是Jedis默认用Protocol.DEFAULT_CHARSET = "UTF-8"编码，但没帮你转String。
- 简单场景：用
BinaryJedis或显式转码，new String(value, StandardCharsets.UTF_8) - 推荐做法：初始化
JedisPool时指定new JedisPool(poolConfig, host, port, timeout, password, database, "UTF-8")，后续所有hget/hgetAll返回的就是String类型Map - 注意
hgetAll在数据量大时阻塞主线程，单次别超1万字段；高频读建议拆成hmget按需取几个字段
JedisPool配置不当的两个高发后果
很多人抄个new JedisPool(new JedisPoolConfig(), host)就上线，结果压测时连接数暴涨、超时频发。核心参数就三个：最大空闲数、最大总连接数、获取连接超时时间，设错一个就连锁反应。
立即学习“Java免费学习笔记（深入）”；
maxIdle ，否则池子建不起来；生产建议<code>maxIdle = maxTotal * 0.8，留缓冲空间-
maxWaitMillis设太小（如100ms）会导致大量JedisConnectionException: Could not get a resource from the pool；建议500–2000ms，配合监控看平均等待时间 - 忘记设
testOnBorrow = true，失效连接（如Redis重启后）会被借出，首次操作直接抛java.net.SocketException: Broken pipe
池子配置不是越“大”越好，maxTotal超过Redis的maxclients（默认10000）反而触发拒绝连接。真实瓶颈常在Redis单线程吞吐，而不是客户端连接数。
