Redis UNLINK 删除大键后如何判断内存何时回收

我在清理 Redis 大 key 时最容易误判的一点，是把 UNLINK 返回成功理解成“内存已经回来了”。实际上它先把 key 从键空间摘掉，真正释放对象内存由后台线程继续完成；即使 Redis 已经释放对象，分配器也可能暂时保留页面，所以进程 RSS 仍然不降。

官方地址：https://redis.io/

判断回收不能只看 UNLINK 的返回值。先看 lazyfree_pending_objects 是否消化，再对照 used_memory、used_memory_rss 和分配器指标；前两层完成，不代表操作系统 RSS 必须马上回到删除前。

UNLINK 到底删除了什么

UNLINK key [key ...] 与 DEL 的结果边界不同：返回整数表示有多少个 key 被从键空间摘除，不存在的 key 会被忽略。Redis 官方文档给出的复杂度是每个 key 的摘除操作为 O(1)，之后对对象内部多份分配执行 O(N) 的释放工作，并放到其他线程处理。

因此可以把一次删除拆成三个观察层：第一层是应用已经无法通过原 key 读到对象；第二层是后台释放线程把待处理对象逐步清掉；第三层是分配器是否把空闲页继续交还给操作系统。标题里的“何时回收”如果不说明层次，就很容易把三个时间点混成一个。

用 lazyfree 指标判断异步释放是否完成

删除大 key 后，先取一组内存信息作为基线，再按固定间隔重复采样。下面的命令只是观测示例，不应把单次输出当成真实固定阈值：

# 只读取内存区，关注异步释放队列和 RSS 的趋势
redis-cli INFO memory | grep -E 'lazyfree|used_memory|allocator|fragmentation'

# 每秒采样一次，便于观察队列是否持续堆积
redis-cli -r -1 -i 1 INFO memory | grep -E 'lazyfree_pending_objects|lazyfreed_objects|used_memory:|used_memory_rss:'

lazyfree_pending_objects 表示等待释放的对象数量，lazyfreed_objects 表示已经异步释放的对象数量。一个实用判断是：pending 不再持续增长并逐步消化，同时 freed 单调增加或至少不再停滞，说明后台队列正在追上删除速度。它仍然不是“某个时间点一定完成”的承诺，因为对象大小、分配次数、CPU 竞争和同时发生的写入都会改变耗时。

为什么 used_memory 降了，RSS 还可能不降

used_memory 更接近 Redis 仍在使用的分配量，used_memory_rss 则是进程从操作系统视角占用的常驻内存。Redis 文档特别提醒：释放的内存先回到分配器，分配器是否把页面还给系统是另一件事。因此删除完成后可能看到 used_memory 明显下降，而 RSS 只小幅下降，甚至短时间保持不变。

可以用下面的组合读数做分层判断：

用 MEMORY 命令做删除前后对照

MEMORY USAGE 适合确认单个 key 的估算占用，MEMORY STATS 适合观察分配器层面的整体指标。它们不能直接告诉你“后台线程还要几秒”，但可以帮助你把对象大小和进程内存变化放在同一个时间窗口里比较：

实际排障时建议保存删除前、UNLINK 返回后、pending 消化后这三组读数，并保证采样间隔和业务负载相近。不要用 MEMORY PURGE 代替异步释放判断：它是请求分配器尝试释放内存的管理命令，效果取决于分配器和当前页面布局，也不能证明某一次 UNLINK 的对象已经全部处理完。

常见问题

UNLINK 返回 1，是不是已经释放了一个大 key 的全部内存？

不是。它表示一个 key 已从键空间摘除；对象实际释放仍可能在后台进行，内存是否归还操作系统还要看分配器。

pending 已经是 0，但 RSS 仍然很高怎么办？

先确认 used_memory 是否下降，再看 allocator 和 fragmentation。若 Redis 已释放对象，RSS 仍高可能是分配器保留页或外部碎片，不要仅凭 RSS 判断 UNLINK 失败。

能否给大 key 设一个固定回收秒数？

不建议。对象内部 allocation 数量、后台线程负载、CPU 竞争和并发删除都会改变耗时。用 pending、freed、used_memory 和 RSS 的趋势判断，比写死等待时间可靠。

小结：Redis UNLINK 的“删除完成”至少有键空间、对象释放、分配器归还三个层次。排查大 key 清理后内存不降时，先用 lazyfree 指标确认异步队列，再把 used_memory 与 RSS 分开解释，最后用 MEMORY STATS 和碎片指标判断是否只是分配器行为。