rediscommandtimeoutexception主因是连接池配置缺陷而非超时值小：需关闭share-native-connection、设正值time-between-eviction-runs并启用test-while-idle、确保max-wait＜timeout，且须闭环检查连接池启用五要素及commons-pool2版本兼容性。
RedisCommandTimeoutException不是超时设置太小的问题
这个异常表面看是命令执行慢，实际90%以上跟timeout值本身关系不大。Lettuce默认开启share-native-connection=true，多个线程共用一个物理连接，此时max-active完全失效；同时time-between-eviction-runs若为0或负值，空闲连接驱逐线程根本不会启动，“僵尸连接”长期滞留池中，一到并发高峰就集体失联。
常见错误现象包括：项目刚启动正常，几分钟后开始报错；高峰期集中爆发；日志里反复出现RedisCommandTimeoutException: Command timed out after 5 second(s)但Redis服务本身redis-cli -h x.x.x.x -p 6379 ping始终返回PONG。
- 必须显式关闭共享：
spring.redis.lettuce.pool.share-native-connection=false -
time-between-eviction-runs必须设为正值（如30000），且搭配test-while-idle: true才有效 -
max-wait必须严格小于timeout（例如timeout: 5000ms→max-wait: 2000ms），否则取连接阶段就耗尽超时预算
连接池根本没启用的5个检查点
很多项目压根没真正用上连接池，而是走的单连接直连模式，导致所有请求排队等待同一个连接。这不是代码问题，而是配置断层。
别急着改Java，先确认这五件事是否都闭环：
- Redis服务本身是否运行：
systemctl status redis，并确认端口6379处于LISTEN状态（netstat -tulnp | grep 6379） -
protected-mode no和bind 0.0.0.0是否同时生效（Docker/K8s环境下尤其注意bind与宿主机网络模式冲突） - 防火墙/安全组是否放行6379（阿里云需单独配置安全组，CentOS用
firewall-cmd --add-port=6379/tcp） -
spring.redis.url是否完整（含密码、数据库号），缺失会导致RedisAutoConfiguration未加载，整个连接池链路失效 - 是否引入了
commons-pool2依赖（spring-boot-starter-data-redis不自动带它，缺则连接池根本不会初始化）
Lettuce空闲连接被静默关闭的真实原因
Lettuce基于Netty，默认不启用TCP keepalive，也不主动发PING，中间设备（NAT、云SLB、防火墙）会在空闲60–300秒后静默关闭连接。下次请求时，连接已断但客户端不知情，直接发命令，结果等超时才抛RedisCommandTimeoutException。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
解决方式不是加重试，而是让连接在被回收前自证健康：
- 启用
pingBeforeActivateConnection(true)：每次从池中取出连接前先发PING - 开启拓扑刷新：
ClientOptions.builder().autoReconnect(true)+ 合理设置topologyRefreshOptions - 避免手动
new LettuceConnectionFactory()：必须用@Bean注入，否则@PreDestroy不触发，连接无法释放
为什么@PreDestroy在RedisConnectionFactory上总不触发
这不是注解失效，而是Spring容器压根没把它当Bean管理。常见于手动new LettuceConnectionFactory()、或配置类中返回实例但没加@Bean注解。LettuceConnectionFactory本身实现了DisposableBean，但销毁方法destroy()只会在Bean被容器托管且上下文关闭时调用。
验证方式很简单：在LettuceConnectionFactory子类中重写destroy()，打日志，观察应用关闭时是否输出。如果没输出，说明它没进Spring生命周期管理——那连接泄漏就是必然的。
最容易被忽略的一点：连接池参数调对了，心跳也开了，但commons-pool2版本不对（比如用了2.11.0但Lettuce 6.3.x要求2.12.0+），会导致GenericObjectPool内部逻辑异常，驱逐线程不工作，所有配置形同虚设。
