redis 6.0 的 io 线程不参与内存清理，因多线程仅限网络 i/o（读请求、写响应），而 del、unlink、过期回收等均由主线程或 bio 线程处理，io 线程对此无直接作用。

Redis 6.0 的 IO 线程完全不参与内存清理（如 DEL、UNLINK、过期 key 回收）——开启 io-threads 对内存回收效率没有直接提升。

为什么 io-threads 不处理内存回收

Redis 6.0 的多线程仅限网络 I/O：读取请求（read）、写回响应（write），所有命令解析、键查找、内存分配/释放、过期扫描、淘汰策略执行，全由主线程串行完成。包括：

• DEL 同步删除：主线程 memcpy + 释放内存，全程阻塞
• UNLINK 异步删除：交由后台 BIO 线程（bgsave / bgrewriteaof 同源线程池）处理，与 io-threads 无关
• 被动过期（访问时检查）和主动过期（activeExpireCycle）：全部在主线程中执行

真正影响内存回收效率的关键配置

当你发现 DEL 延迟高、evicted_keys 突增、或 INFO memory 显示 mem_fragmentation_ratio 偏高，问题不在网络层，而在内存生命周期管理：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 必须启用 lazyfree-lazy-eviction yes：LRU/LFU 淘汰触发的删除走异步路径
• 必须启用 lazyfree-lazy-expire yes：过期 key 清理移交 BIO 线程
• 必须启用 lazyfree-lazy-server-del yes：对 RENAME、RESTORE 等内部 DEL 操作也懒删除
• 确认 maxmemory 设置合理，且未长期处于 95%+ 占用；否则 activeExpireCycle 扫描频率飙升，持续抢占主线程 CPU
• 避免在大 key 上频繁 DEL：比如 10MB 的 SET value，同步删会卡主线程数毫秒；应改用 UNLINK

io-threads 和内存回收的间接关联点

虽然 io-threads 不干回收的活，但若配置不当，会放大内存压力带来的副作用：

• 开了 io-threads 却没开 lazyfree：网络吞吐上去了，但大 DEL 或驱逐爆发时，主线程被卡住，IO 线程全部空转，整体延迟反而更抖
• io-threads-do-reads no（默认值）：即使设了 io-threads 4，读请求仍全压主线程，导致主线程既要处理命令又要收包，内存回收类任务更难抢到时间片
• 客户端未用 pipeline 或连接池：大量短连接反复握手认证，把主线程 CPU 耗在 accept 和 auth 上，留给 activeExpireCycle 的周期变少

验证是否真需要调优内存回收

别一上来就改 redis.conf，先看指标：

• 执行 INFO commandstats，检查 cmdstat_del:usec_per_call 是否 > 10000（即 >10ms）
• 执行 INFO memory，观察 lazyfreed_objects 是否持续 > 0；若为 0 但 used_memory_rss 长期高于 used_memory，说明 jemalloc 碎片没及时归还
• 查 INFO stats 中的 expired_keys 和 evicted_keys 每秒增量，若突增 5 倍以上，优先排查业务逻辑而非线程数

主线程永远是内存回收的单点；IO 线程只是帮它把“收包”和“发包”这两件事卸载出去——卸得再干净，删不动的 key 还是得它亲手（或委托 BIO 线程）去处理。