根本原因是Lettuce基于Netty通信，高并发下连接数激增、空闲连接未及时释放或缓冲区回收不及时，导致Netty堆外内存（Direct Memory）耗尽；而非Java堆内存不足。
为什么Lettuce会触发OutOfDirectMemoryError
根本原因不是Java堆内存不够，而是Netty在底层分配的堆外内存（Direct Memory）耗尽。Lettuce基于Netty通信，每个连接默认会为读写缓冲区分配堆外内存；高并发下连接数猛增、连接长期空闲不释放、或缓冲区未及时回收，都会让io.netty.util.internal.OutOfDirectMemoryError频繁出现。
这不是配置“忘了加”那么简单——哪怕你设了max-active: 8，如果网络抖动导致连接半死不活，Lettuce仍可能不断新建连接来重试，旧连接的堆外内存却没被及时释放。尤其在K8s滚动更新、Redis服务端主动断连等场景下，这个问题会集中爆发。
连接池参数必须同步调优的三个关键点
只改max-active是无效的，这几个参数必须成对调整：
-
max-active和max-idle建议设为相同值（如16），避免连接池“缩容”时强制关闭活跃连接，引发Netty资源泄漏 -
min-idle不要设为0（默认值），至少配2，保证空闲时有连接常驻，减少冷启动重连开销 -
max-wait必须小于timeout：比如timeout: 5000，则max-wait: 3000，否则线程可能卡在“等连接”阶段超时，掩盖真实连接问题
物理连接不回收的典型表现与修复
现象包括：应用日志里反复出现Connection closed或RedisCommandTimeoutException，但netstat -an | grep :6379显示大量TIME_WAIT或ESTABLISHED连接未释放。
这是因为Lettuce默认不启用空闲连接检测，失效连接滞留在池中。修复方式是显式开启保活检查：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
spring:
redis:
lettuce:
pool:
test-while-idle: true
time-between-eviction-runs: 30000
min-evictable-idle-time-millis: 60000
注意：test-while-idle依赖底层PING命令验证连接有效性，若Redis禁用了PING（如安全策略限制），该机制会失效，需配合connect-timeout和timeout双超时兜底。
别碰-Dio.netty.maxDirectMemory这个参数
很多文章建议通过JVM参数-Dio.netty.maxDirectMemory=512m强行扩大堆外内存上限，这是典型的“掩耳盗铃”。它只是把OOM时间点往后推，无法解决连接泄漏或缓冲区堆积的根本问题。反而可能让故障更隐蔽——内存撑到极限才崩，排查窗口更小。
真正有效的做法只有两个：
- 升级Lettuce到
6.3.0+（Spring Boot 3.5+默认集成），该版本修复了Netty 4.1.100+的DirectBuffer回收逻辑缺陷 - 在
LettuceClientConfiguration中显式关闭自动重连，改用指数退避策略，避免雪崩式重建连接：.shutdownTimeout(Duration.ofSeconds(2))+.commandTimeout(Duration.ofSeconds(5))
连接池不是越大越好，而是在业务RT、QPS和GC压力之间找平衡点。一个被忽略的事实是：Lettuce单连接能支撑比Jedis高3–5倍的吞吐，盲目扩max-active反而增加Netty事件循环负担，得不偿失。
