还记得上次咱们聊过那个让人头皮发麻的“CPU飙高死循环”排查经历吗？当时不少“老公们”在后台直呼过瘾。今天咱们不聊CPU，换个口味，来聊聊另一个让后端工程师闻风丧胆的噩梦——内存溢出。

想象一下你正坐在面试室里空调开得有点低，面试官推了推眼镜，冷不丁地抛出一句：“Ru果Redis内存溢出了你怎么办？”

这时候，Ru果你心里只想着“重启大法好”，那基本就Ke以准备收拾东西走人了。这不仅仅是一个简单的配置问题，geng是一场关于资源权衡、算法取舍以及架构设计的深度博弈。今天我就带着大家，像剥洋葱一样，把这个问题彻底掰开了、揉碎了讲清楚。咱们直奔主题，只讲干货，顺便帮你避避那些面试里的“坑”。

一、 为什么Redis会“撑爆”？——物理限制的必然

咱们得达成一个共识：Redis这家伙，是个典型的“内存大户”。它之所以快，全是因为数据dou乖乖地躺在内存里随叫随到。但是物理机的内存是有限的，就像你的钱包一样，总有干瘪的一天。

在Redis的配置文件redis.conf里有一个至关重要的参数：maxmemory。这玩意儿就是Redis的“预算上限”。Ru果不设置，Redis会觉得自己拥有一整台机器的内存，直到操作系统把它“杀”死。所以生产环境的第一条铁律，就是一定要设置Zui大内存大小。

但是光设了上限还不够。当内存真的触碰到这条红线时Redis是直接报错？还是偷偷删东西？这就涉及到了我们今天要聊的核心——过期策略和内存淘汰策略。

二、 第一道防线：过期策略的“三选一”博弈

面试官Zui喜欢问：“Redis的Key过期了是怎么被删除的？”

理论上，删除过期Key有三种方案。咱们先来个理论大PK，kankanRedis为什么Zui终选择了现在的方案。

1. 定时删除：理想hen丰满，现实hen骨感

什么叫定时删除？就是给每个设置了过期时间的Key，dou配一个专属的“闹钟”。时间一到，闹钟一响，立马删除。

听起来hen完美对吧？既不浪费内存，数据也Neng及时清理。

但是这有个巨大的坑。Ru果你的Redis里有几十万、甚至上百万个Keydou设置了过期时间，那是不是就得维护几十万个定时器？这就好比你要同时盯着几十万个闹钟，CPU资源瞬间就被耗尽了。Redis作为高性Neng缓存，它的命根子就是CPU，Ru果全用来处理过期删除，那业务请求还怎么处理？

所以Redis坚决不用定时删除，因为它太“吃”CPU了。

2. 惰性删除：懒人的智慧

既然定时删除太累，那咱们就“懒”一点。这就是惰性删除。

它的逻辑hen简单：Key过期了？不管它，先放着。只有当程序下次来访问这个Key的时候，发现它过期了这时候才把它删掉，然后返回给客户端一个“这就没这东西”的提示。

优点：对CPU极度友好，不访问就不删，绝不浪费计算资源。

缺点：对内存不友好。想象一下Ru果一批Key过期了但之后再也没有人来访问它们，那它们岂不是成了“僵尸数据”，一直霸占着宝贵的内存空间？这就是所谓的“内存泄漏”隐患。

3. 定期删除：折中的艺术

为了解决惰性删除“清理不干净”的问题，Redis引入了定期删除。

这就像是一个保洁阿姨，每隔一段时间就过来扫一眼。但是Redis里的Key那么多，保洁阿姨也不可Neng一个个全检查一遍，那样太慢了。所以她采用的是随机抽样的策略。

她会随机抓取一批Key，把其中过期的删掉。Ru果这一批里过期的Key比例太高，说明垃圾太多，她就多干会儿活，再随机抓一批继续删；Ru果比例hen低，说明挺干净，就歇会儿，下次再来。

优点：通过限制删除操作的时长和频率，来减少对CPU的影响，同时也Neng清理掉一部分过期数据。

缺点：还是不够精确。毕竟只是随机抽样，难免会有“漏网之鱼”。

4. Redis的Zui终选择：双管齐下

kan到这里你应该明白了。为什么不单独用一种？因为惰性删不干净，定期删不精确。

RedisZui终选择了“惰性 + 定期”的组合拳。平时主要靠定期删除来“大扫除”，偶尔漏网的就靠惰性删除在访问时“顺手”清理。这种策略既不会消耗过多CPU，又Neng及时清理大部分过期数据，在性Neng和资源之间找到了一个完美的平衡点。

三、 第二道防线：当内存真的满了——内存淘汰策略

这时候，有同学可Neng会问：“Ru果过期策略搞不定怎么办？比如我的Keydou没设置过期时间，或者写入速度太快，过期策略根本来不及清理，内存还是满了这时候Redis会怎么办？”

好问题！这时候，内存淘汰策略就要闪亮登场了。

当Redis内存达到maxmemory上限时它会根据你配置的策略，强行“踢”走一些Key，给新数据腾地儿。这就像公交车满了司机必须赶下来几个人，才Neng让新的人上来。

Redis提供了好几种淘汰策略，咱们挑重点的说：

1. LRU：Zui近Zui少使用

这是Zui经典的算法。它的核心思想是：“Zui近访问的数据，大概率还会被访问；hen久没访问的数据，大概率以后也不会再用了。”

所以当内存满时LRU会优先淘汰那些Zui久没被访问过的Key。

但是标准的LRU算法需要维护一个复杂的链表，内存开销大。为了性Neng，Redis用的是近似LRU算法。它并不一定精准地找到“Zui久”的那个，而是随机采样一批Key，从中挑出Zui久没访问的那个踢走。虽然不完美，但这点误差是Ke以接受的。

2. LFU：Zui不经常使用

LRUkan的是“时间”，LFUkan的是“频率”。它的假设是：“访问频率高的数据geng有价值。”

Ru果你的业务场景里有明显的“热点数据”，那LFU可Neng比LRUgeng合适。它会优先淘汰那些平时hen少被问津的Key。Redis在4.0版本之后引入了这个策略，对于那些偶尔被访问一次但之后再也不用的数据，LFUNeng识别得geng准。

3. 生产环境怎么选？

策略那么多，面试官Ru果问你“生产环境推荐用哪个？”，你Ke以自信地回答：

allkeys-lru这是Zui通用的选择。适用于标准的缓存场景，不管Key有没有过期，dou优先淘汰Zui久没用的。

allkeys-lfuRu果你的热点数据非常明显，且希望保留那些高频访问的数据，选这个。

volatile-lru这个只淘汰设置了过期时间的Key。Ru果你不想让那些没设置过期时间的“永久数据”被删，就用这个。

配置起来也hen简单，在redis.conf里加上：

# 设置Zui大内存为4GB
maxmemory 4gb
# 设置淘汰策略为所有Key的LRU
maxmemory-policy allkeys-lru

四、 实战排查：如何监控Redis的内存状态？

光懂理论不行，出了问题还得会排查。面试官可Neng会追问：“你怎么知道Redis内存快满了？”

这时候，祭出我们的法宝：INFO memory命令。

在Redis命令行里敲入INFO memory，你会kan到一堆指标，这里重点盯住这几个：

INFO memory
# 关键指标解读：
# used_memory：Redis当前占用的物理内存大小
# maxmemory：你设置的Zui大内存限制
# maxmemory_policy：当前生效的淘汰策略
# mem_fragmentation_ratio：内存碎片率

这里有个小坑要注意：内存碎片率。Ru果这个值大于1，说明有碎片；Ru果这个值小于1，那就要警惕了这通常意味着操作系统把Redis的内存swap到硬盘上了！一旦发生swap，Redis的性Neng会呈断崖式下跌，因为硬盘比内存慢了几个数量级。

五、 避坑指南：别把Java的锅甩给Redis

说到内存溢出，hen多ZuoJava的同学容易混淆。这里我得插一句题外话，帮大家理理思路。

上次咱们聊Java堆内存溢出的时候，说过那是JVM里的事儿。别一听到“内存溢出”就以为是Redis的问题。比如你用SpringBoot 2.0以后默认操作Redis的客户端变成了Lettuce，它是基于Netty的，有时候堆外内存配置不当，也会报OutOfDirectMemoryError。

还有，在K8s环境里容器的资源限制也是个坑。你给容器设了内存限制，但Redis自己不知道啊，它还以为Neng随便用，结果被K8s直接OOM Kill了。这时候，你得确保Redis的maxmemory配置要小于K8s的容器内存限制，留点余地给操作系统。

所以排查内存问题，得先搞清楚是Redis自身的内存溢出，还是Java进程的内存溢出，亦或是容器层面的资源限制。别一上来就改配置，方向错了越努力越尴尬。

六、 一下怎么应对面试官？

好了说了这么多，咱们Zui后来个“一句话结论”复盘，方便大家记忆：

Redis为了平衡CPU和内存，不使用定时删除，而是采用“惰性删除 + 定期删除”的组合拳。Ru果过期策略还是清理不过来内存满了就会触发内存淘汰策略。平时通过INFO memory监控状态，注意区分Redis内存溢出和JVM内存溢出的区别。

下次面试官再问你这个问题，你就Ke以把这些逻辑娓娓道来顺便再聊聊K8s里的资源限制和Netty的堆外内存，相信我，面试官kan你的眼神绝对不一样。

技术这条路，坑多路滑，咱们慢慢走，踩过的坑多了也就成了专家。下次咱们再聊聊别的“翻车”现场，敬请期待！

---