Jedis连接池配置不生效的根本原因是未正确使用JedisPool或未规范获取/释放连接；必须用try-with-resources调用getResource()并自动归还，禁用new Jedis()和finally中close()。
Jedis连接池配置不生效，总是新建连接
根本原因是没用对 JedisPool，或者用了但没正确获取/释放连接。Jedis本身不自动管理连接生命周期，全靠你手动调用 getResource() 和 returnResource()（或更安全的 try-with-resources）。漏掉 returnResource() 会导致连接耗尽，后续请求只能新建连接——看着像“池没起作用”。
- 必须用
try (Jedis jedis = jedisPool.getResource()) { ... }，Jedis 3.0+ 支持AutoCloseable，自动归还 - 别直接 new
Jedis()，那完全绕过池；也别在 finally 里写jedis.close()（老版本会关闭连接，不是归还） -
JedisPoolConfig默认最大空闲数是 8，如果并发 >8 且没及时归还，就会新建连接——先检查maxIdle、maxTotal是否够用 - 连接池初始化后不会主动探测节点健康状态，若 Redis 服务重启过，首次获取连接可能报
JedisConnectionException，需配合testOnBorrow=true（有性能损耗）或自行做预热
Lettuce连接池和线程安全怎么配才不踩坑
Lettuce 的连接模型和 Jedis 完全不同：它基于 Netty，单个 RedisClient 实例是线程安全的，可复用；真正需要池化的是 StatefulRedisConnection（有状态连接），但通常你根本不需要池化它——Lettuce 推荐直接复用 RedisClient，按需调用 connect()。
- 99% 的场景下，只需一个全局
RedisClient实例 + 多次调用client.connect()，返回的StatefulRedisConnection可以安全地被多个线程并发使用（它内部是无状态命令管道） - 真要池化连接（比如需要控制连接数上限），得用
GenericObjectPool<statefulredisconnection></statefulredisconnection>，但必须设置setTestOnReturn(true)，否则失效连接可能留在池里 - Lettuce 默认启用连接空闲检测（
idleDutyCycle），如果 Redis 配置了timeout 300，而客户端没设clientOptions().pingBeforeActivateConnection(true)，空闲连接可能被服务端断开却不自知 - Spring Boot 2.0+ 默认用 Lettuce，但若手动配连接池，别混淆
io.lettuce.core.resource.ClientResources和连接池——前者管线程池、DNS、SSL 等底层资源，后者才是连接实例池
连接池参数调优：maxTotal 和 minIdle 设多少才合理
没有通用值，取决于你的 QPS、平均响应时间、Redis 节点数和网络延迟。盲目调大反而引发 Redis 端连接数超限或客户端 GC 压力。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 估算公式：
maxTotal ≈ QPS × 平均RT（秒）× 1.5；例如 200 QPS、平均 RT 10ms → 约需 3 个连接，设maxTotal=8即可留余量 -
minIdle不建议设大于 0，除非你有极低延迟要求且能接受连接常驻内存；Lettuce 尤其不推荐，它的连接建立成本远低于 Jedis - Jedis 池里
maxWaitMillis别设太小（如 100ms），否则高负载时大量请求直接抛JedisConnectionException: Could not get a resource from the pool；设为 2–3 秒更稳妥 - Redis 服务端有
maxclients限制（默认 10000），所有客户端连接总和不能超这个数；一个微服务集群若部署 20 个实例，每个池maxTotal=100，就已占满 2000 连接
连接泄漏怎么快速定位和修复
最典型的症状是：应用运行几小时后，jstack 里看到大量 org.apache.commons.pool2.impl.GenericObjectPool.borrowObject 阻塞线程，或 Redis CLIENT LIST 显示连接数持续上涨不降。
立即学习“Java免费学习笔记（深入）”；
- 加 JVM 参数
-Djedis.log.enabled=true（Jedis 4.0+）或用 AOP 拦截JedisPool.getResource()/returnResource()，记录未匹配的调用对 - Lettuce 可开启日志：
logging.level.io.lettuce.core=DEBUG，关注Connecting to Redis和Closing connection日志是否成对出现 - 检查所有
try块是否覆盖了所有分支，尤其是catch后忘了returnResource()，或finally里又抛异常导致归还逻辑跳过 - Spring 中若用
@Cacheable配 Lettuce，确认没在缓存异常时触发连接泄漏——某些旧版 Spring Data Redis 在CacheErrorHandler处理失败后未清理连接
连接池不是银弹，它解决的是连接建立开销问题，而不是掩盖错误的资源管理习惯。一旦发现泄漏，优先查代码里的 getResource() 和 connect() 是否都有对应释放动作，而不是急着调大 maxTotal。
