开启lazyfree-lazy-expire能缓解大Key过期阻塞，但无法消除高负载——它仅将内存释放移至后台线程，而过期扫描、key发现及逻辑摘除仍在主线程执行。
开启 lazyfree-lazy-expire 能显著缓解大Key过期时的主线程阻塞，但不能完全消除高负载——它只是把内存释放动作从主线程挪到后台线程，而过期扫描、key发现、逻辑摘除等步骤仍在主线程执行。
为什么大Key过期会卡住Redis主线程
Redis默认采用“定期扫描 + 惰性删除”双策略清理过期key。当大量key（尤其含大集合）在同一秒内集中过期，定时任务（serverCron）会反复执行：随机抽20个key → 删除其中过期的 → 若过期率＞25%就再抽20个……这个循环可能持续数十毫秒甚至更久。若其中恰好包含一个 hash 有50万字段的key，DEL 同步释放操作就会直接阻塞主线程，导致所有请求延迟飙升。
lazyfree-lazy-expire 实际生效的边界条件
该配置只在满足以下全部条件时才触发异步删除：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- key已过期，且被定时扫描任务或惰性访问路径发现
- key对应的数据结构元素个数 ≥
LAZYFREE_THRESHOLD（硬编码为64） - key未被其他命令（如
RENAME）隐式同步删除
注意：lazyfree-lazy-expire on 不影响“惰性删除”路径（即客户端访问时检查过期），只影响“定时扫描”路径中发现的过期key的释放方式。如果业务里大量使用 GET/HGET 触发惰性删除，这部分仍走同步逻辑，不走lazyfree。
必须配合的配置与实操建议
单独开 lazyfree-lazy-expire 效果有限，需组合调整：
- 确保 Redis 版本 ≥ 4.0（推荐 ≥ 6.2，修复了早期lazyfree在AOF重写期间的竞态问题）
- 同时开启
lazyfree-lazy-server-del yes，避免RENAME/RESTORE等隐式DEL触发同步阻塞 - 调低
hz值（如设为5）可减少定时扫描频率，但会延长过期key残留时间；设为15~20可在及时性与CPU开销间折中 - 监控
expired_keys和evicted_keys指标突增，结合latency monitor定位是否真由过期引发延迟 - 用
redis-cli -p 6379 --bigkeys定期扫描，对确认的大key主动用UNLINK替代DEL，而非被动等它过期
容易被忽略的副作用
lazyfree把内存释放交给后台线程，但内存真正归还OS存在延迟，可能导致 INFO memory 中的 used_memory_rss 持续高于 used_memory，尤其在内存紧张时易触发 maxmemory 淘汰。此时若淘汰策略是 volatile-lru，后台线程正在释放的key仍会计入LRU排序，造成误判。务必观察 lazyfree_pending_objects 指标，持续 > 1000 说明后台释放积压，需检查是否阈值设置过低或后台线程被IO阻塞。
