这是 why 哥的第 81 篇原创文章
你面试的时候遇见过 LRU 吗？
LRU 算法，全称是 Least Recently Used。
翻译过去就是最近起码应用算法。
这个算法的思维就是： 如果一个数据在最近一段时间没有被拜访到，那么在未来它被拜访的可能性也很小。所以，当指定的空间已存满数据时，该当把最久没有被拜访到的数据淘汰。
听形容你也晓得了，它是一种淘汰算法。
这个算法也是面试的一个高频考点。
有的面试官甚至要求手撸一个 LRU 算法进去。
其实我感觉吧，遇到这种状况也不要慌，你就依照本人的思路写一个进去就行。
赌一把，面试官兴许本人短时间内都手撸不进去一个无 bug 的 LRU。他也只是查看几个关键点、看看你的代码格调、察看一下你的解题思路而已。
但其实大多数状况下面试场景都是这样的：
面试官：你晓得 LRU 算法吗？
我：晓得，翻译过去就是最近起码应用算法。其思维是（后面说过，就不复述了）……
面试官：那你能给我谈谈你有哪些办法来实现 LRU 算法呢？
这个时候问的是什么？
问的是：咱们都晓得这个算法的思路了，请你依照这个思路给出一个能够落地的解决方案。
不必徒手撸一个。
计划一：数组
如果之前齐全没有接触过 LRU 算法，仅仅晓得其思路。
第一次听就要求你给一个实现计划，那么数组的计划应该是最容易想到的。
假如咱们有一个定长数组。数组中的元素都有一个标记。这个标记能够是工夫戳，也能够是一个自增的数字。
假如咱们用自增的数字。
每放入一个元素，就把数组中曾经存在的数据的标记更新一下，进行自增。当数组满了后，就将数字最大的元素删除掉。
每拜访一个元素，就将被拜访的元素的数字置为 0。
这不就是 LRU 算法的一个实现计划吗？
依照这个思路，撸一份七七八八的代码进去，问题应该不大吧？
然而这一种计划的弊病也是很显著：须要不停地保护数组中元素的标记。
那么你感觉它的工夫复杂度是多少？
是的，每次操作都随同着一次遍历数组批改标记的操作，所以工夫复杂度是 O(n)。
然而这个计划，面试官必定是不会称心的。因为，这不是他心中的标准答案。
兴许他都没想过：你还能给出这种计划呢？
然而它不会说进去，只会微微的说一句：还有其余的计划吗？
计划二：链表
于是你扣着脑壳想了想。最近起码应用，感觉是须要一个有序的构造。
我每插入一个元素的时候，就追加在数组的开端。
我每拜访一次元素，就把被拜访的元素挪动到数组的开端。
这样最近被用的肯定是在最初面的，头部的就是最近起码应用的。
当指定长度被用完了之后，就把头部元素移除掉就行了。
这是个什么构造？
这不就是个链表吗？
保护一个有序单链表，越凑近链表头部的结点是越早之前拜访的。
当有一个新的数据被拜访时，咱们从链表头部开始程序遍历链表。
如果此数据之前曾经被缓存在链表中了，咱们遍历失去这个数据的对应结点，并将其从原来的地位删除，并插入到链表尾部。
如果此数据没在缓存链表中，怎么办？
分两种状况：
- 如果此时缓存未满，可间接在链表尾部插入新节点存储此数据；
- 如果此时缓存已满，则删除链表头部节点，再在链表尾部插入新节点。
你看，这不又是 LRU 算法的一个实现计划吗？
依照这个思路，撸一份八九不离十的代码进去，问题应该不大吧？
这个计划比数组的计划好在哪里呢？
我感觉就是莫名其妙的高级感，就是看起来就比数组高级了一点。
从工夫复杂度的角度看，因为链表插入、查问的时候都要遍历链表，查看数据是否存在，所以它还是 O(n)。
总之，这也不是面试官想要的答案。
当你答复出这个计划之后，面试官兴许会说： 你能不能给我一个查问和插入的工夫复杂度都是 O(1) 的解决方案？
到这里，就得看天性了。
有一说一，如果我之前齐全没有接触过 LRU 算法，我能够十分自信的说：
计划三：双向链表 + 哈希表。
如果咱们想要查问和插入的工夫复杂度都是 O(1)，那么咱们须要一个满足上面三个条件的数据结构：
- 1. 首先这个数据结构必须是有时序的，以辨别最近应用的和很久没有应用的数据，当容量满了之后，要删除最久未应用的那个元素。
- 2. 要在这个数据结构中疾速找到某个 key 是否存在，并返回其对应的 value。
- 3. 每次拜访这个数据结构中的某个 key，须要将这个元素变为最近应用的。也就是说，这个数据结构要反对在任意地位疾速插入和删除元素。
那么，你说什么样的数据结构同时合乎下面的条件呢？
查找快，咱们能想到哈希表。然而哈希表的数据是乱序的。
有序，咱们能想到链表，插入、删除都很快，然而查问慢。
所以，咱们得让哈希表和链表联合一下，成长一下，造成一个新的数据结构，那就是：哈希链表，LinkedHashMap。
这个构造大略长这样：
借助这个构造，咱们再来剖析一下下面的三个条件：
- 1. 如果每次默认从链表尾部增加元素，那么显然越凑近尾部的元素就越是最近应用的。越凑近头部的元素就是越久未应用的。
- 2. 对于某一个 key，能够通过哈希表疾速定位到链表中的节点，从而获得对应的 value。
- 3. 链表显然是反对在任意地位疾速插入和删除的，批改指针就行。然而单链表无奈依照索引快速访问某一个地位的元素，都是须要遍历链表的，所以这里借助哈希表，能够通过 key，疾速的映射到任意一个链表节点，而后进行插入和删除。
这才是面试官想要对于 LRU 的正确答案。
然而你认为答复到这里就完结了吗？
面试官为了确认你的把握水平，还会诘问一下。
那么请问： 为什么这里要用双链表呢，单链表为什么不行？
你心里一慌：我靠，这题我也背过。一时想不起来了。
所以，别只顾着背答案，得了解。
你想啊，咱们是不是波及到删除元素的操作？
那么链表删除元素除了本人自身的指针信息，还须要什么货色？
是不是还须要前驱节点的指针？
那么咱们这里要求工夫复杂度是 O(1)，所以怎么能力间接获取到前驱节点的指针？
这玩意是不是就得上双链表？
咦，你看在一波灵魂诘问中，就失去了答案。
面试官的第二个问题又随之而来了： 哈希表外面曾经保留了 key，那么链表中为什么还要存储 key 和 value 呢，只存入 value 不就行了？
不会也不要慌，你先剖析一波。
刚刚咱们说删除链表中的节点，须要借助双链表来实现 O(1)。
删除了链表中的节点，而后呢？
是不是还遗记了什么货色？
是不是还有一个哈希表遗记操作了？
哈希表是不是也得进行对应的删除操作？
删除哈希表须要什么货色？
是不是须要 key，能力删除对应的 value？
这个 key 从哪里来？
是不是只能从链表中的结点外面来？
如果链表中的结点，只有 value 没有 key，那么咱们就无奈删除哈希表的 key。那不就完犊子了吗？
又是一波灵魂诘问。
所以，你当初晓得答案了吗？
另外在多说一句，有的小伙伴可能会间接答复借助 LinkedHashMap 来实现。
我感觉吧，你要是切实不晓得，也能够这样说。
然而，这个答复可能是面试官最不想听到的答复了。
他会感觉你投机取巧。
然而呢，理论开发中，真正要用的时候，咱们还是用的 LinkedHashMap。
你说这个事件，好受不好受。
好了，你认为到这里面试就完结了？
LRU 在 MySQL 中的利用
面试官：小伙子刚刚 LRU 答复的不错哈。要不你给我讲讲，LRU 在 MySQL 中的利用？
LRU 在 MySQL 的利用就是 Buffer Pool，也就是缓冲池。
它的目标是为了缩小磁盘 IO。
缓冲池具体是干啥的，我这里就不开展说了。
你就晓得它是一块间断的内存，默认大小 128M，能够进行批改。
这一块间断的内存，被划分为若干默认大小为 16KB 的页。
既然它是一个 pool，那么必然有满了的时候，怎么办？
就得移除某些页了，对吧？
那么问题就来了：移除哪些页呢？
刚刚说了，它是为了缩小磁盘 IO。所以应该淘汰掉很久没有被拜访过的页。
很久没有应用，这不就是 LRU 的主场吗？
然而在 MySQL 外面并不是简略的应用了 LRU 算法。
因为 MySQL 外面有一个预读性能。预读的出发点是好的，然而有可能预读到并不需要被应用的页。
这些页也被放到了链表的头部，容量不够，导致尾部元素被淘汰。
哦豁，升高命中率了，凉凉。
还有一个场景是全表扫描的 sql，有可能间接把整个缓冲池外面的缓冲页都换了一遍，影响其余查问语句在缓冲池的命中率。
那么怎么解决这种场景呢？
把 LRU 链表分为两截，一截外面放的是热数据，一截外面放的是冷数据。
打住，不能再说了。
再说就是另外一篇文章了，点到为止。
如果你不分明，倡议去学习一下哦。
LRU 在 Redis 中的利用
既然是内存淘汰算法，那么咱们罕用的 Redis 外面必然也有对应的实现。
Redis 的内存淘汰策略有如下几种：
- noenviction：默认策略。不继续执行写申请（DEL 申请能够解决），读申请能够持续进行。这样能够保障不会失落数据，然而会让线上的业务不能继续进行。
- volatile-lru：从已设置过期工夫的数据集中筛选最近起码应用的数据淘汰。没有设置过期工夫的 key 不会被淘汰。
- volatile-random：从已设置过期工夫的数据集中随机抉择数据淘汰。
- volatile-ttl：从已设置过期工夫的数据集中筛选将要过期的数据淘汰。
- allkeys-lru：和 volatile-lru 不同的是，这个策略要淘汰的 key 对象是整体的 key 汇合。
- allkeys-random：从所有数据集中随机抉择数据淘汰。
Redis 4.0 之后，还减少了两个淘汰策略。
- volatile-lfu：对有过期工夫的 key 采纳 LFU 淘汰算法
- allkeys-lfu：对全副 key 采纳 LFU 淘汰算法
对于 Redis 中的 LRU 算法，官网上是这样说的：
https://github.com/redis/redis-doc/blob/master/topics/lru-cache.md
在 Redis 中的 LRU 算法不是严格的 LRU 算法。
Redis 会尝试执行一个近似的 LRU 算法，通过采样一小部分键，而后在采样键中回收最适宜的那个，也就是最久没有被拜访的那个（with the oldest access time）。
然而，从 Redis3.0 开始，改善了算法的性能，使得更靠近于实在的 LRU 算法。做法就是保护了一个回收候选键池。
Redis 的 LRU 算法有一个十分重要的点就是你能够通过批改上面这个参数的配置，本人调整算法的精度。
maxmemory-samples 5
最重要的一句话我也曾经标记进去了：
The reason why Redis does not use a true LRU implementation is because it costs more memory.
Redis 没有应用实在的 LRU 算法的起因是因为这会耗费更多的内存。
而后官网上给了一个随机 LRU 算法和严格 LRU 算法的比照图：
对于这个图官网是这样说的：
你能够从图中看到三种不同的小圆点造成的三个不同的带：
- 浅灰色带是被回收（被 LRU 算法淘汰）的对象
- 灰色带是没有被回收的对象
- 绿色带是新增加的对象
因为 Redis 3.0 对 LRU 算法进行了改良，减少了淘汰池。
所以你能够看到，同样应用 5 个采样点，Redis 3.0 体现得比 Redis 2.8 要好。
同时能够看出，在 Redis 3.0 中应用 10 为采样大小，近似值曾经十分靠近实践性能。
写到这里我忽然想起了另外一个面试题。
数据库中有 3000w 的数据，而 Redis 中只有 100w 数据，如何保障 Redis 中寄存的都是热点数据？
这个题你说它的考点是什么？
考的就是淘汰策略呀，同志们，只是形式比拟费解而已。
咱们先指定淘汰策略为 allkeys-lru 或者 volatile-lru，而后再计算一下 100w 数据大略占用多少内存，依据算进去的内存，限定 Redis 占用的内存。
搞定。
满腹经纶，难免会有纰漏，如果你发现了谬误的中央，能够在后盾提出来，我对其加以批改。
感谢您的浏览，我保持原创，非常欢送并感谢您的关注。
我是 why，一个被代码耽搁的文学创作者，不是大佬，然而喜爱分享，是一个又暖又有料的四川好男人。
还有，欢送关注我呀。