lettuce 官方不提供 lettuceclientpool 类，需用 apache commons pool2 的 genericobjectpool 包装 statefulredisconnection；redisclient 必须复用，statefulredisconnection 可池化但非必需；哨兵模式需匹配 master name；集群模式下不应额外池化，应直接使用 redisclusterclient。
为什么直接 new LettuceClientPool 会报错
Lettuce 本身不提供开箱即用的「连接池类」，LettuceClientPool 这个名字在官方 API 里根本不存在。常见错误是照着旧版 Jedis 习惯去搜“Lettuce 连接池”，结果引入了非官方封装或过时的第三方包，导致 NoClassDefFoundError 或 IllegalArgumentException: clientResources must not be null。
真实做法是：用 GenericObjectPool（来自 Apache Commons Pool2）包装 StatefulRedisConnection，再配合 RedisClient 和 ClientResources 手动管理生命周期。
- 必须显式创建
ClientResources，否则高并发下线程池和 DNS 缓存会出问题 -
StatefulRedisConnection是线程安全的，但「不推荐」直接丢进池子——它内部已带命令队列与重连逻辑，池化反而增加调度开销 - 真正该池化的，是轻量级的
StatefulRedisConnection实例，不是RedisClient
如何配置一个生产可用的 Lettuce 连接池
核心不是堆参数，而是匹配 Redis 部署模式：单机、哨兵、集群，初始化方式完全不同。用错会导致连接始终超时或随机 RedisCommandTimeoutException。
以哨兵模式为例，正确初始化步骤：
立即学习“Java免费学习笔记（深入）”；
- 用
RedisURI.create("redis-sentinel://127.0.0.1:26379/0#mymaster")构造 URI，#mymaster必须和哨兵中配置的 master name 一致 -
RedisClient要复用，不能每次请求都 new；但StatefulRedisConnection可池化 - 池配置重点设三项：
setMaxIdle(16)、setMinIdle(4)、setMaxWaitMillis(1000)；设太大容易拖垮 Redis，太小则频繁建连
示例关键片段：
RedisClient client = RedisClient.create(RedisURI.create("redis-sentinel://127.0.0.1:26379/0#mymaster"));
GenericObjectPool<StatefulRedisConnection<String, String>> pool = ConnectionPoolSupport
.createGenericObjectPool(() -> client.connect(), poolConfig);
pool.borrowObject() 后忘记 close() 会怎样
这不是“资源泄漏”那么简单。Lettuce 的 StatefulRedisConnection 调用 close() 并不会断物理连接，而是归还到池中；但若漏掉这步，连接就永远卡在“borrowed”状态，池子慢慢被占满，后续调用直接卡在 borrowObject() 等待，直到超时抛 NoSuchElementException。
- 必须用 try-with-resources，且泛型要写对：
try (StatefulRedisConnection<string string> conn = pool.borrowObject()) { ... }</string> - 禁止在 connection 上调用
reset()或flushCommands()后再归还——可能破坏连接状态，导致下一次 borrow 出现RedisException: Connection closed - 如果业务需要事务（MULTI/EXEC），别在池化 connection 上做——Lettuce 的事务状态不支持跨调用延续，容易混用
Redis 集群环境下还能用同一个池吗
不能。Lettuce 对集群模式做了特殊处理：RedisClusterClient 内部已自带连接管理，它会按 slot 自动路由、维护多个节点连接，并支持拓扑刷新。你再套一层 GenericObjectPool 不仅无效，还会干扰重试和故障转移逻辑。
- 集群场景下，直接用
RedisClusterClient.connect()得到的StatefulRedisClusterConnection即可，它是线程安全的，无需池化 - 若硬要池化，必须为每个节点单独建池（不现实），或者改用
ClusterTopologyRefreshOptions控制拓扑更新频率，避免频繁重连 - 验证是否误用了池：看日志里有没有反复出现
Cluster topology refresh failed或Unable to resolve Master for slot
连接池这件事，本质是权衡——Lettuce 已经把连接复用、重连、超时、序列化这些事做得挺深了。盲目池化，往往是因为没看清它在哪一层发力。
