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 的SETvalue，同步删会卡主线程数毫秒；应改用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 线程）去处理。
