Redis 内存碎片是什么？为什么删除数据后，内存占用没有明显下降？

知识点详解：删除的数据，内存去了哪里？

内存不是只有“有数据”和“没数据”两种状态

假设一个缓存实例经历大量写入，又删除了很多不同大小的 Key。Redis 不再需要某些对象，就会释放对应的分配。

但释放首先发生在 Redis 与分配器之间。分配器可能把这部分空间留着，供后续申请复用；只有满足相应条件，才会把页面归还给操作系统。

因此，删除 Key 后进程 RSS 不立即下降，并不自动意味着 Key 没有删除，也不自动证明发生了内存泄漏。Redis 内存优化文档 对这种现象有说明。

哪几个指标应该一起看？

指标	主要观察什么	不能单独证明什么
used_memory	Redis 通过分配器统计的内存分配	不等于全部 RSS
used_memory_rss	操作系统看到的常驻内存	不全是有效数据
allocator_allocated	分配器已分配给应用的空间	不等于所有驻留页面
allocator_active / resident	活跃页面与分配器驻留情况	需结合具体分配器解释

可以通过 INFO memory 和 MEMORY STATS 查看。不同版本字段和分配器实现有差异，使用前要核对 INFO 与 MEMORY STATS 的定义。

比例为什么容易误导？一个数据很少的实例，固定开销就可能占很大比例；删掉大量数据后，分母下降，也会让比例暂时变高。因此，还要看额外占用了多少字节，是否持续增长，以及业务数据是否稳定。

图：空位能复用，不一定能整页归还。

主动碎片整理和释放页面，不是一回事

主动碎片整理会尝试搬动可整理的分配，让内存更紧凑。它需要运行时和分配器支持，也会带来一定 CPU 开销。并不是打开以后，所有空闲页面就立即返还系统。

分配器回收则更接近“把不用的页面归还”。例如 MEMORY PURGE 的能力取决于分配器支持，它也不是对任意碎片都能生效的万能按钮。

实际治理前，先在相同数据分布和写删模式下测试。除了内存下降多少，还要看延迟、CPU 和后续重新分配的成本。

为什么 maxmemory 不能当作 RSS 的硬上限？

maxmemory 控制 Redis 的相关内存使用和淘汰行为，但操作系统看到的进程内存还有其他部分。复制、持久化及写时复制期间，也可能带来额外内存压力。

所以实例容量需要留余量，不能把宿主机可用内存全部配置成 maxmemory。回到假设场景，应先保存指标趋势，再决定是整理、调整数据结构、扩容，还是在有恢复方案的情况下安排重启。

图：这里分开看淘汰规则、进程 RSS 和机器容量，几种口径不是可以直接相加的精确公式；后台写时复制的峰值还要另外预留。

面试官继续追问

重启后内存降了，能证明之前是碎片吗？

只能提供线索。重启还会改变分配历史、缓存内容、后台任务等状态。需要结合重启前的分配器指标，而不能用一个结果代替原因分析。

UNLINK 能解决碎片吗？

它主要把释放工作放到后台，减少同步删除对主线程的影响。它改变释放时机，不等于保证 RSS 马上下降或碎片全部消失。

什么情况下要怀疑泄漏？

在数据量、流量和后台任务相对稳定时，相关内存仍持续增长且无法解释，才应进一步分析分配来源。先排除正常保留、客户端缓冲和持久化峰值。

面试速记卡

• 删除 Key：释放分配，不保证立即降低 RSS。
• 碎片比例：结合绝对字节、数据规模和趋势判断。
• 排查层次：Redis 分配、分配器页面、进程 RSS。
• 治理：整理和页面回收是不同动作。
• 容量：为 RSS 额外开销和后台任务预留空间。