核心内容摘要
ssm基于java的泉文化管理系统(源码+文档+调试+vue+前后端分离)
你有没有遇到过这种情况：Redis 用着用着，内存突然满了，但系统还在拼命往里塞数据？
这时候 Redis 并不会崩溃，而是悄悄地“清人腾位”。
那它凭什么决定“谁走谁留”？
今天，小米就带你认识 Redis 背后的那位老管家——LRU 算法，用一个仓库的故事，把这套内存回收机制彻底讲清楚。
故事从一个被塞爆的仓库开始我是小米，今年 31 岁，写代码第 10 年。
那天我正坐在工位上，刚泡好一杯咖啡，监控突然红了一片：Redis used_memory 达到 maxmemoryQPS 开始抖延迟飙升我心里一紧，第一反应是：“完了，是不是 Redis 要炸了？
”但很快我发现一个奇怪的现象：Redis没有挂，而是慢慢恢复了平稳。
我突然意识到一件事：Redis，在自己偷偷“扔东西”。
这就像一个仓库，被塞满了，但仓库管理员并没有锁门不干活，而是开始把“没用的旧货”往外丢。
这个管理员，名字叫LRU。
Redis 的内存不是无限的在 Redis 的世界里，有一条铁律：内存是有限的，优先级是残酷的。
你在配置文件里通常会看到这两行：maxmemory 4gbmaxmemory-policy allkeys-lru这两行翻译就是：Redis 最多只能用 4GB 内存如果内存满了，就按LRU 算法来淘汰数据于是问题来了：什么是 LRU？
LRU 是谁？
他是个什么样的人？