unlink有时仍卡主线程，因它仅保证o(1)摘除key，内存释放是否异步取决于lazyfree-lazy-user-del配置（默认no）、watch监控、refcount>1或内存紧张等场景，此时自动降级为同步删除且不报错。
UNLINK 为什么有时还是卡主线程
UNLINK 返回 (integer) 1 不代表真异步——它只表示 key 已从数据库字典中“摘除”，但内存释放是否进后台线程，取决于 lazyfree-lazy-user-del 配置和运行时状态。该配置默认是 no，哪怕 Redis ≥ 4.0，UNLINK 也照样退化为同步 DEL。
常见误判场景：
- 没检查
CONFIG GET lazyfree-lazy-user-del，直接信了文档说“4.0+ 支持 UNLINK” - 临时
CONFIG SET lazyfree-lazy-user-del yes后没验证是否生效（重启后失效） - key 正被
WATCH监控，或OBJECT REFCOUNT> 1，UNLINK 自动降级且不报错
必须开的三个 lazyfree 配置项
光开 lazyfree-lazy-user-del 不够，真实生产环境要组合启用：
-
lazyfree-lazy-user-del yes：让UNLINK和（开启后）DEL都走异步释放 -
lazyfree-lazy-expire yes：过期扫描发现的大 key（元素 ≥ 64）才异步释放内存，否则仍同步删 -
lazyfree-lazy-server-del yes：避免RENAME、RESTORE等隐式DEL触发同步阻塞
注意：lazyfree-lazy-eviction 建议慎开——内存淘汰时异步释放可能延迟归还内存，导致 used_memory_rss 短期冲高甚至触发 OOM。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
怎么验证异步删除真在跑
别只看命令返回快，要盯住后台线程和内存变化：
- 执行
UNLINK前后快速跑两次INFO memory，观察used_memory_human是否缓慢下降（不是立刻掉），同时lazyfree_pending_objects先升后降 - 查
INFO stats中的lazyfree_pending_objects，非零说明有任务排队；长期 > 0 可能是 BIO 线程积压或内存紧张被拒收 - 用
redis-cli --bigkeys定期扫出大 key，对确认的 hash/set/zset 主动UNLINK，别等它过期——因为惰性删除（访问时触发）仍是同步的
大 key 删除前必须确认的三件事
UNLINK 不是银弹，运行时约束会悄悄让它回退：
- key 不能被
WATCH：事务未提交前调用UNLINK，立刻同步删 -
OBJECT REFCOUNT <code>key必须为 1：若值为 2，说明正参与RENAME或刚被GET引用，UNLINK 会同步执行 - 内存不能极度紧张：
INFO memory中mem_not_counted_for_lazyfree显著上升，说明 BIO 线程已拒绝新任务，此时 UNLINK 也会同步删
最易被忽略的是 refcount 和内存压力——这两项不报错、不打日志，只默默卡主线程。上线前务必在压测环境模拟冷热 key 混合删除场景。
