**问题核心在哪？应用侧短连接失控，连接池形同虚设。** 根本原因并不在Redis服务器端，而是Spring Boot应用这一侧：频繁创建短连接，且连接池配置未能生效。Linux内核协议栈在客户端主动关闭TCP连接后，强制进入`TIME_WAIT`状态（通常维持60秒），这段窗口内端口无法复用。只要QPS稍高，本地端口范围（默认32768–65535）很快就被耗尽——这才是一大堆`TIME_WAIT`的真正源头。

**为什么redisTemplate或Lettuce自动配置依然会触发短连接？** Spring Boot 2.0之后默认使用Lettuce作为Redis客户端，但它自带的连接池并非自动生效——配置只停留在“可配置”层面，实际跑起来，池可能根本没被用上。常见的情景有四种： - 手动new `RedisConnectionFactory`，或者反复调用`getRedisConnection()`——这种用法直接绕过了Spring管理的连接池 - 定义`RedisTemplate`的`@Bean`时，没有明确指定`connectionFactory`，或者factory本身就是一个每次new出来的新实例 - 在`@Async`等异步任务中直接new `RedisClient`、`StatefulRedisConnection`，完全没从连接池中取 - 测试类里用`new RedisClient(...)` + `connect()` + `close()`，每次调用都等同于新建一个TCP连接 这些问题大部分都是“习惯性代码写法”带来的副作用。代码层面看起来没毛病，但网卡上的TCP连接数已经出卖了真相。 **如何确认是Spring Boot应用产生了TIME_WAIT，而非其他进程？** 千万别先查Redis服务器。正确的排查方向是在Spring Boot应用所在的宿主机上执行： ```bash ss -tan state time-wait sport = :6379 | wc -l ``` 再按源IP聚合，看看是不是集中在当前机器上： ```bash ss -tan sport = :6379 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -5 ``` 如果输出第一列是本机IP、计数持续高于2000，基本可以锁定该应用在制造短连接风暴。如果源头是其他IP，那问题就不在你这一层。 **Lettuce连接池的关键配置与避坑点** Spring Boot 2.3+默认启用Lettuce，但`maxConnections`、`minIdle`这类参数必须显式配置才能生效。光靠默认值是撑不住的。 以下是经验总结的配置清单： - `spring.redis.lettuce.pool.max-active=200`：这个数值建议按预估并发峰值的1.5倍来设（比如QPS 100 => 150）。设太小会导致连接不够、请求阻塞；设太大则浪费内存。 - `spring.redis.lettuce.pool.time-between-eviction-runs=30000`：这是空连接清理线程的扫描间隔。一定要开启这个定时任务，否则连接迟迟不释放，池里存活的都是“僵尸连接”。 - 禁用`spring.redis.lettuce.shutdown-timeout=0`：避免容器关闭时强制中断连接——非优雅关闭会直接拉高`TIME_WAIT`数量。 - 还有一个容易踩的坑：业务代码里调用`connection.close()`或`redisClient.shutdown()`。Lettuce连接的生命周期由池管理，手动关闭只会破坏复用逻辑。 **为什么说Jedis比Lettuce更容易踩TIME_WAIT的坑？** Jedis默认采用同步阻塞I/O，它的`JedisPool`配置稍有不慎，就会退化为一堆短连接。以下三种情况经常被忽略： - `maxTotal=1`或者`blockWhenExhausted=false`——线程池满了直接抛异常，业务层通常会“补救”式地新建一个Jedis对象，直接变成短连接 - `testOnBorrow=true`未开启、`minEvictableIdleTimeMillis`设置过长——大量失效连接堆积在池中，取出来的连接立刻报错，业务只能再建新的 - Spring Boot 2.x的项目，如果没有显式排除`spring-boot-starter-data-redis`的默认依赖，很可能意外引入了Jedis，自己还没发现 相比之下，Lettuce底层基于Netty，连接复用更稳定；Jedis每条命令都走独立socket读写，对连接生命周期的控制更脆弱。 最容易被忽视的是：即使配置了连接池，只要有一处代码写了`new Jedis(...)`或`redisClient.connect()`并紧跟着`close()`，那一行就足以让整个池形同虚设。`TIME_WAIT`不会因为“用了Spring”就自动消失，它只取决于应用实际怎么发TCP包。