max-active设过高会拉高cpu，因空闲连接持续占用netty线程、tcp socket及ssl上下文，引发调度开销与gc压力；推荐按峰值qps×1.2～1.5设定（如qps 100→120），k8s环境再增10%～20%，并禁用负数或极大值。
max-active设太高反而拉高CPU？看真实负载再定值
设成200却只用到30个连接，是典型资源浪费。Lettuce每个空闲连接背后都绑着Netty EventLoop线程、TCP socket和可能的SSL上下文，不干活也占调度和GC资源。压测时常见CPU软中断（si）飙升、Full GC变频繁、LettuceConnectionFactory实例数居高不下。
物理机部署建议：预估峰值QPS × 1.2～1.5（比如QPS 100 → max-active: 120）；K8s环境再加10%～20%，因网络延迟波动大、连接复用率更低。
- 绝对避免设为负数（如
-1）或极大值（如1000），等于放弃连接池节流能力 - 若业务QPS波动剧烈，可配合
min-idle设为max-active的30%～40%，减少冷启动抖动 -
max-active不是越大越好，它和实际并发请求量必须对齐，否则就是给JVM徒增负担
max-wait太短会触发重试风暴
max-wait控制的是从连接池获取连接的阻塞上限，单位毫秒。设成100ms看似响应快，但一旦连接池耗尽，线程不会安静等待，而是快速失败→重试→再失败，形成“重试风暴”。JVM线程频繁切换+异常堆栈生成，直接推高CPU使用率，日志里密集出现CannotGetRedisConnectionException或Timeout waiting for idle object。
生产环境推荐设为2000ms（2秒），给连接池回收与复用留出缓冲时间。它和timeout（命令执行超时）完全无关，混淆两者是线上事故高频原因。
- 若业务对延迟极其敏感（如实时风控），宁可降低
max-active并配熔断（如Resilience4j），也不要压缩max-wait到500ms以下 -
max-wait: -1ms（无限等待）在生产环境极度危险，可能导致线程长期挂起、线程池耗尽
timeBetweenEvictionRunsMillis不设正数，连接池就等于没开
这是Lettuce连接池最隐蔽的失效点。很多开发者配置了max-active、min-idle，监控却始终只看到1个连接——根本原因是timeBetweenEvictionRunsMillis没设为正值，驱逐检测机制未启用，连接池形同虚设。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
必须显式启用驱逐检测：spring.redis.lettuce.pool.time-between-eviction-runs=30000（30秒）。否则即使配置了min-idle: 5，也不会主动创建保底连接。
- 该参数在YAML中写法是
time-between-eviction-runs，不是驼峰，拼错即失效 - 值必须>0，设为0或负数等同于关闭驱逐，
min-idle永远不会生效 - Spring Boot 2.3+默认不启用此机制，必须手动打开
commons-pool2版本必须显式锁定
Spring Boot 2.3.x之后如果不显式声明org.apache.commons:commons-pool2版本，可能自动引入存在bug的老版本，导致连接泄漏。我在三个项目中实测确认过这点。
Gradle中务必显式声明：
implementation 'org.apache.commons:commons-pool2:2.11.1'
就像锁数据库驱动版本一样谨慎。不要依赖Spring Boot的间接传递依赖，尤其在升级Spring Boot主版本后，pool2的兼容性风险极高。
- 2.11.1是当前已验证稳定的版本，2.12.x在部分Netty组合下有连接未释放问题
- 若用Maven，同样需在
<dependency></dependency>中显式声明，不能只靠spring-boot-starter-data-redis带入
真正难的不是配几个数字，而是让max-active、max-wait、time-between-eviction-runs三者协同工作——一个管上限，一个管等待底线，一个管连接生命周期。少一个，池子就漏；错一个，CPU就飘。上线前务必用Actuator看/actuator/metrics/redis.connection.pool.active和idle比值，别只信YAML文件里的静态配置。
