为什么要有虚拟内存？

虚拟内存

• 我们程序所使⽤的内存地址叫做虚拟内存地址（Virtual Memory Address）
• 实际存在硬件⾥⾯的空间地址叫物理内存地址（Physical Memory Address）。

内存分段

分段机制下，虚拟地址和物理地址是如何映射的？

内存分页

段页式内存管理

Linux内存管理

我们再来瞧⼀瞧， Linux 的虚拟地址空间是如何分布的？

总总结结

malloc 是如何分配内存的？

Linux 进程的内存分布长什么样？

在 Linux 操作系统中，虚拟地址空间的内部又被分为内核空间和用户空间两部分，不同位数的系 统，地址空间的范围也不同。比如最常见的 32 位和 64 位系统，如下所示：

通过这里可以看出：

• 32 位系统的内核空间占用 1G ，位于最高处，剩下的 3G 是用户空间；
• 64 位系统的内核空间和用户空间都是 128T ，分别占据整个内存空间的最高和最低处，剩下 的中间部分是未定义的。

再来说说，内核空间与用户空间的区别：

虽然每个进程都各自有独立的虚拟内存，但是每个虚拟内存中的内核地址，其实关联的都是相同 的物理内存。这样，进程切换到内核态后，就可以很方便地访问内核空间内存。

接下来，进一步了解虚拟空间的划分情况，用户空间和内核空间划分的方式是不同的，内核空间 的分布情况就不多说了。 我们看看用户空间分布的情况，以 32 位系统为例，我画了一张图来表示它们的关系：

通过这张图你可以看到，用户空间内存从低到高分别是 6 种不同的内存段：

• 代码段，包括二进制可执行代码；
• 数据段，包括已初始化的静态常量和全局变量；
• BSS 段，包括未初始化的静态变量和全局变量；
• 堆段，包括动态分配的内存，从低地址开始向上增长；
• 文件映射段，包括动态库、共享内存等，从低地址开始向上增长（跟硬件和内核版本有关 ）；
• 栈段，包括局部变量和函数调用的上下文等。栈的大小是固定的，一般是 8 MB 。当然系统也 提供了参数，以便我们自定义大小；

在这 6 个内存段中，堆和文件映射段的内存是动态分配的。比如说，使用 C 标准库的 malloc() 或者 mmap() ，就可以分别在堆和文件映射段动态分配内存。

malloc 是如何分配内存的？

实际上，malloc() 并不是系统调用，而是 C 库里的函数，用于动态分配内存。 malloc 申请内存的时候，会有两种方式向操作系统申请堆内存。

方式一实现的方式很简单，就是通过 brk() 函数将「堆顶」指针向高地址移动，获得新的内存空 间。如下图：

方式二通过 mmap() 系统调用中「私有匿名映射」的方式，在文件映射区分配一块内存，也就是 从文件映射区“偷”了一块内存。如下图：

malloc() 源码里默认定义了一个阈值：

• 如果用户分配的内存小于 128 KB，则通过 brk() 申请内存；
• 如果用户分配的内存大于 128 KB，则通过 mmap() 申请内存；

注意，不同的 glibc 版本定义的阈值也是不同的。

malloc() 分配的是物理内存吗？

不是的，malloc() 分配的是虚拟内存。

如果分配后的虚拟内存没有被访问的话，虚拟内存是不会映射到物理内存的，这样就不会占用物 理内存了。

只有在访问已分配的虚拟地址空间的时候，操作系统通过查找页表，发现虚拟内存对应的页没有 在物理内存中，就会触发缺页中断，然后操作系统会建立虚拟内存和物理内存之间的映射关系。

malloc(1) 会分配多大的虚拟内存？

具体会预分配多大的空间，跟 malloc 使用的内存管理器有关系，我们就以 malloc 默认的内存管理 器（Ptmalloc2）来分析。

接下里，我们做个实验，用下面这个代码，通过 malloc 申请 1 字节的内存时，看看操作系统实际 分配了多大的内存空间。

#include <stdio.h>
#include <malloc.h>
int main() {
printf("使用cat /proc/%d/maps查看内存分配\n",getpid());
//申请1字节的内存
void *addr = malloc(1);
printf("此1字节的内存起始地址：%x\n", addr);
printf("使用cat /proc/%d/maps查看内存分配\n",getpid());
//将程序阻塞，当输入任意字符时才往下执行
getchar();
//释放内存
free(addr);
printf("释放了1字节的内存，但heap堆并不会释放\n");
getchar();
return 0;
}

执行代码（先提前说明，我使用的 glibc 库的版本是 2.17）：

我们可以通过 /proc//maps 文件查看进程的内存分布情况。我在 maps 文件通过此 1 字节的内存 起始地址过滤出了内存地址的范围。

这个例子分配的内存小于 128 KB，所以是通过 brk() 系统调用向堆空间申请的内存，因此可以看到 最右边有 [heap] 的标识。

可以看到，堆空间的内存地址范围是 00d73000-00d94000，这个范围大小是 132KB，也就说明了 malloc(1) 实际上预分配 132K 字节的内存。 可能有的同学注意到了，程序里打印的内存起始地址是 d73010 ，而 maps 文件显示堆内存空间 的起始地址是 d73000 ，为什么会多出来 0x10 （16字节）呢？ 

这个问题，我们先放着，后面会说。

free 释放内存，会归还给操作系统吗？

我们在上面的进程往下执行，看看通过 free() 函数释放内存后，堆内存还在吗？

从下图可以看到，通过 free 释放内存后，堆内存还是存在的，并没有归还给操作系统。

这是因为与其把这 1 字节释放给操作系统，不如先缓存着放进 malloc 的内存池里，当进程再次申 请 1 字节的内存时就可以直接复用，这样速度快了很多。

当然，当进程退出后，操作系统就会回收进程的所有资源。

• 上面说的 free 内存后堆内存还存在，是针对 malloc 通过 brk() 方式申请的内存的情况。
• 如果 malloc 通过 mmap 方式申请的内存，free 释放内存后就会归归还给操作系统。

#include <stdio.h>
#include <malloc.h>
int main() {
//申请1字节的内存
void *addr = malloc(128*1024);
printf("此128KB字节的内存起始地址：%x\n", addr);
printf("使用cat /proc/%d/maps查看内存分配\n",getpid());
//将程序阻塞，当输入任意字符时才往下执行
getchar();
//释放内存
free(addr);
printf("释放了128KB字节的内存，内存也归还给了操作系统\n");
getchar();
return 0;
}

执行代码：

查看进程的内存的分布情况，可以发现最右边没有 [heap] 标志，说明是通过 mmap 以匿名映射的 方式从文件映射区分配的匿名内存。

然后我们释放掉这个内存看看：

再次查看该 128 KB 内存的起始地址，可以发现已经不存在了，说明归还给了操作系统。

对于 「malloc 申请的内存，free 释放内存会归还给操作系统吗？」这个问题，我们可以做个总结 了：

• malloc 通过 brk() 方式申请的内存，free 释放内存的时候，并不会把内存归还给操作系统，而 是缓存在 malloc 的内存池中，待下次使用；
• malloc 通过 mmap() 方式申请的内存，free 释放内存的时候，会把内存归还给操作系统，内存 得到真正的释放。

为什么不全部使用 mmap 来分配内存？

因为向操作系统申请内存，是要通过系统调用的，执行系统调用是要进入内核态的，然后在回到 用户态，运行态的切换会耗费不少时间。

所以，申请内存的操作应该避免频繁的系统调用，如果都用 mmap 来分配内存，等于每次都要执 行系统调用。

另外，因为 mmap 分配的内存每次释放的时候，都会归还给操作系统，于是每次 mmap 分配的虚 拟地址都是缺页状态的，然后在第一次访问该虚拟地址的时候，就会触发缺页中断。

也就是说，频繁通过 mmap 分配的内存话，不仅每次都会发生运行态的切换，还会发生缺页中断 （在第一次访问虚拟地址后），这样会导致 CPU 消耗较大。

为了改进这两个问题，malloc 通过 brk() 系统调用在堆空间申请内存的时候，由于堆空间是连续 的，所以直接预分配更大的内存来作为内存池，当内存释放的时候，就缓存在内存池中。

等下次再申请内存的时候，就直接从内存池取出对应的内存块就行了，而且可能这个内存块的虚拟地址和物理地址的映射关系还 存在，这样不仅减少了系统调用的次数，也减少了缺页中断的次数，这将大大降低CPU的消耗。

既然 brk 那么牛逼，为什么不全部使用 brk 来分配？

前面我们提到通过 brk 从堆空间分配的内存，并不会归还给操作系统，那么我们那考虑这样一个 场景。

如果我们连续申请了 10k，20k，30k 这三片内存，如果 10k 和 20k 这两片释放了，变为了空闲内 存空间，如果下次申请的内存小于 30k，那么就可以重用这个空闲内存空间。

但是如果下次申请的内存大于 30k，没有可用的空闲内存空间，必须向 OS 申请，实际使用内存继 续增大。

所以，malloc 实现中，充分考虑了 brk 和 mmap 行为上的差异及优缺点，默认分配大块内存 (128KB) 才使用 mmap 分配内存空间。

free() 函数只传入一个内存地址，为什么能知道要释放多大的内存？

还记得，我前面提到， malloc 返回给用户态的内存起始地址比进程的堆空间起始地址多了 16 字 节吗？

这个多出来的 16 字节就是保存了该内存块的描述信息，比如有该内存块的大小。

这样当执行 free() 函数时，free 会对传入进来的内存地址向左偏移 16 字节，然后从这个 16 字节 的分析出当前的内存块的大小，自然就知道要释放多大的内存了。

内存满了，会发生什么？

虚拟内存有什么作用？

• 第一，虚拟内存可以使得进程对运行内存超过物理内存大小，因为程序运行符合局部性原理， CPU 访问内存会有很明显的重复访问的倾向性，对于那些没有被经常使用到的内存，我们可以 把它换出到物理内存之外，比如硬盘上的 swap 区域。
• 第二，由于每个进程都有自己的页表，所以每个进程的虚拟内存空间就是相互独立的。进程也 没有办法访问其他进程的页表，所以这些页表是私有的，这就解决了多进程之间地址冲突的问题。
• 第三，页表里的页表项中除了物理地址之外，还有一些标记属性的比特，比如控制一个页的读 写权限，标记该页是否存在等。在内存访问方面，操作系统提供了更好的安全性。

然后今天主要是聊聊第二个问题，「系统内存紧张时，会发生什么？」 

内存分配的过程是怎样的？

应用程序通过 malloc 函数申请内存的时候，实际上申请的是虚拟内存，此时并不会分配物理内 存。

当应用程序读写了这块虚拟内存，CPU 就会去访问这个虚拟内存， 这时会发现这个虚拟内存没有 映射到物理内存， CPU 就会产生缺页中断，进程会从用户态切换到内核态，并将缺页中断交给内 核的 Page Fault Handler （缺页中断函数）处理。

缺页中断处理函数会看是否有空闲的物理内存，如果有，就直接分配物理内存，并建立虚拟内存 与物理内存之间的映射关系。

如果没有空闲的物理内存，那么内核就会开始进行回收内存的工作，回收的方式主要是两种：直 接内存回收和后台内存回收。

• 后台内存回收（kswapd）：在物理内存紧张的时候，会唤醒 kswapd 内核线程来回收内存，这 个回收内存的过程异步的，不会阻塞进程的执行。
• 直接内存回收（direct reclaim）：如果后台异步回收跟不上进程内存申请的速度，就会开始直 接回收，这个回收内存的过程是同步的，会阻塞进程的执行。

如果直接内存回收后，空闲的物理内存仍然无法满足此次物理内存的申请，那么内核就会放最后 的大招了 ——触发 OOM （Out of Memory）机制。

OOM Killer 机制会根据算法选择一个占用物理内存较高的进程，然后将其杀死，以便释放内存资 源，如果物理内存依然不足，OOM Killer 会继续杀死占用物理内存较高的进程，直到释放足够的内存位置。

申请物理内存的过程如下图：

哪些内存可以被回收？

系统内存紧张的时候，就会进行回收内存的工作，那具体哪些内存是可以被回收的呢？

主要有两类内存可以被回收，而且它们的回收方式也不同。

• 文件页（File-backed Page）：内核缓存的磁盘数据（Buffer）和内核缓存的文件数据 （Cache）都叫作文件页。大部分文件页，都可以直接释放内存，以后有需要时，再从磁盘重新 读取就可以了。而那些被应用程序修改过，并且暂时还没写入磁盘的数据（也就是脏页），就 得先写入磁盘，然后才能进行内存释放。所以，回收干净页的方式是直接释放内存，回收脏页 的方式是先写回磁盘后再释放内存。
• 匿名页（Anonymous Page）：这部分内存没有实际载体，不像文件缓存有硬盘文件这样一个载体，比如堆、栈数据等。这部分内存很可能还要再次被访问，所以不能直接释放内存，它们回收的方式是通过 Linux 的 Swap 机制，Swap 会把不常访问的内存先写到磁盘中，然后释放这些 内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入内存就可以了。

文件页和匿名页的回收都是基于 LRU 算法，也就是优先回收不常访问的内存。LRU 回收算法，实 际上维护着 active 和 inactive 两个双向链表，其中：

• active_list 活跃内存页链表，这里存放的是最近被访问过（活跃）的内存页；
• inactive_list 不活跃内存页链表，这里存放的是很少被访问（非活跃）的内存页；

越接近链表尾部，就表示内存页越不常访问。这样，在回收内存时，系统就可以根据活跃程度， 优先回收不活跃的内存。

活跃和非活跃的内存页，按照类型的不同，又分别分为文件页和匿名页。可以从 /proc/meminfo 中，查询它们的大小，比如：

# grep表示只保留包含active的指标（忽略大小写）
# sort表示按照字母顺序排序
[root@xiaolin ~]# cat /proc/meminfo | grep -i active | sort
Active: 901456 kB
Active(anon): 227252 kB
Active(file): 674204 kB
Inactive: 226232 kB
Inactive(anon): 41948 kB
Inactive(file): 184284 kB

回收内存带来的性能影响

在前面我们知道了回收内存有两种方式。

• 一种是后台内存回收，也就是唤醒 kswapd 内核线程，这种方式是异步回收的，不会阻塞进程。
• 一种是直接内存回收，这种方式是同步回收的，会阻塞进程，这样就会造成很长时间的延迟， 以及系统的 CPU 利用率会升高，最终引起系统负荷飙高。

可被回收的内存类型有文件页和匿名页：

• 文件页的回收：对于干净页是直接释放内存，这个操作不会影响性能，而对于脏页会先写回到 磁盘再释放内存，这个操作会发生磁盘 I/O 的，这个操作是会影响系统性能的。
• 匿名页的回收：如果开启了 Swap 机制，那么 Swap 机制会将不常访问的匿名页换出到磁盘 中，下次访问时，再从磁盘换入到内存中，这个操作是会影响系统性能的。

可以看到，回收内存的操作基本都会发生磁盘 I/O 的，如果回收内存的操作很频繁，意味着磁盘 I/O 次数会很多，这个过程势必会影响系统的性能，整个系统给人的感觉就是很卡。

下面针对回收内存导致的性能影响，说说常见的解决方式。

调整文件页和匿名页的回收倾向

从文件页和匿名页的回收操作来看，文件页的回收操作对系统的影响相比匿名页的回收操作会少 一点，因为文件页对于干净页回收是不会发生磁盘 I/O 的，而匿名页的 Swap 换入换出这两个操作 都会发生磁盘 I/O。

Linux 提供了一个 /proc/sys/vm/swappiness 选项，用来调整文件页和匿名页的回收倾向。

swappiness 的范围是 0-100，数值越大，越积极使用 Swap，也就是更倾向于回收匿名页；数值越 小，越消极使用 Swap，也就是更倾向于回收文件页。

一般建议 swappiness 设置为 0（默认值是 60），这样在回收内存的时候，会更倾向于文件页的回 收，但是并不代表不会回收匿名页。

尽早触发kswapd内核线程异步回收内存

如何查看系统的直接内存回收和后台内存回收的指标？

我们可以使用 sar -B 1 命令来观察：

图中红色框住的就是后台内存回收和直接内存回收的指标，它们分别表示：

• pgscank/s : kswapd(后台回收线程) 每秒扫描的 page 个数。
• pgscand/s: 应用程序在内存申请过程中每秒直接扫描的 page 个数。
• pgsteal/s: 扫描的 page 中每秒被回收的个数（pgscank+pgscand）。

如果系统时不时发生抖动，并且在抖动的时间段里如果通过 sar -B 观察到 pgscand 数值很大，那 大概率是因为「直接内存回收」导致的。 针对这个问题，解决的办法就是，可以通过尽早的触发「后台内存回收」来避免应用程序进行直接内存回收。

针对这个问题，解决的办法就是，可以通过尽早的触发「后台内存回收」来避免应用程序进行直 接内存回收。

什么条件下才能触发 kswapd 内核线程回收内存呢？

内核定义了三个内存阈值（watermark，也称为水位），用来衡量当前剩余内存（pages_free）是 否充裕或者紧张，分别是：

• 页最小阈值（pages_min）；
• 页低阈值（pages_low）；
• 页高阈值（pages_high）；

这三个内存阈值会划分为四种内存使用情况，如下图

• kswapd 会定期扫描内存的使用情况，根据剩余内存（pages_free）的情况来进行内存回收的工作。
• 图中绿色部分：如果剩余内存（pages_free）大于 页高阈值（pages_high），说明剩余内存是 充足的；
• 图中蓝色部分：如果剩余内存（pages_free）在页高阈值（pages_high）和页低阈值 （pages_low）之间，说明内存有一定压力，但还可以满足应用程序申请内存的请求；
• 图中橙色部分：如果剩余内存（pages_free）在页低阈值（pages_low）和页最小阈值 （pages_min）之间，说明内存压力比较大，剩余内存不多了。这时 kswapd0 会执行内存回 收，直到剩余内存大于高阈值（pages_high）为止。虽然会触发内存回收，但是不会阻塞应用 程序，因为两者关系是异步的。
• 图中红色部分：如果剩余内存（pages_free）小于页最小阈值（pages_min），说明用户可用内 存都耗尽了，此时就会触发直接内存回收，这时应用程序就会被阻塞，因为两者关系是同步的。

可以看到，当剩余内存页（pages_free）小于页低阈值（pages_low），就会触发 kswapd 进行后 台回收，然后 kswapd 会一直回收到剩余内存页（pages_free）大于页高阈值（pages_high）。

也就是说 kswapd 的活动空间只有 pages_low 与 pages_min 之间的这段区域，如果剩余内存低于 了 pages_min 会触发直接内存回收，高于了 pages_high 又不会唤醒 kswapd。

min_free_kbytes 虽然设置的是页最小阈值（pages_min），但是页高阈值（pages_high）和页低 阈值（pages_low）都是根据页最小阈值（pages_min）计算生成的，它们之间的计算关系如下：

如果系统时不时发生抖动，并且通过 sar -B 观察到 pgscand 数值很大，那大概率是因为直接内存 回收导致的，这时可以增大 min_free_kbytes 这个配置选项来及早地触发后台回收，然后继续观察 pgscand 是否会降为 0。

增大了 min_free_kbytes 配置后，这会使得系统预留过多的空闲内存，从而在一定程度上降低了应 用程序可使用的内存量，这在一定程度上浪费了内存。极端情况下设置 min_free_kbytes 接近实际 物理内存大小时，留给应用程序的内存就会太少而可能会频繁地导致 OOM 的发生。

所以在调整 min_free_kbytes 之前，需要先思考一下，应用程序更加关注什么，如果关注延迟那就 适当地增大 min_free_kbytes，如果关注内存的使用量那就适当地调小 min_free_kbytes。

NUMA架构下的内存回收策略

什么是 NUMA 架构？

再说 NUMA 架构前，先给大家说说 SMP 架构，这两个架构都是针对 CPU 的。

SMP 指的是一种多个 CPU 处理器共享资源的电脑硬件架构，也就是说每个 CPU 地位平等，它们 共享相同的物理资源，包括总线、内存、IO、操作系统等。每个 CPU 访问内存所用时间都是相同 的，因此，这种系统也被称为一致存储访问结构（UMA，Uniform Memory Access）。

随着 CPU 处理器核数的增多，多个 CPU 都通过一个总线访问内存，这样总线的带宽压力会越来越 大，同时每个 CPU 可用带宽会减少，这也就是 SMP 架构的问题。

为了解决 SMP 架构的问题，就研制出了 NUMA 结构，即非一致存储访问结构（Non-uniform memory access，NUMA）。 NUMA 架构将每个 CPU 进行了分组，每一组 CPU 用 Node 来表示，一个 Node 可能包含多个 CPU 。

每个 Node 有自己独立的资源，包括内存、IO 等，每个 Node 之间可以通过互联模块总线 （QPI）进行通信，所以，也就意味着每个 Node 上的 CPU 都可以访问到整个系统中的所有内存。但是，访问远端 Node 的内存比访问本地内存要耗时很多。

NUMA 架构跟回收内存有什么关系？

在 NUMA 架构下，当某个 Node 内存不足时，系统可以从其他 Node 寻找空闲内存，也可以从本 地内存中回收内存。

具体选哪种模式，可以通过 /proc/sys/vm/zone_reclaim_mode 来控制。它支持以下几个选项：

• 0 （默认值）：在回收本地内存之前，在其他 Node 寻找空闲内存；
• 1：只回收本地内存；
• 2：只回收本地内存，在本地回收内存时，可以将文件页中的脏页写回硬盘，以回收内存。
• 4：只回收本地内存，在本地回收内存时，可以用 swap 方式回收内存。

在使用 NUMA 架构的服务器，如果系统出现还有一半内存的时候，却发现系统频繁触发「直接内 存回收」，导致了影响了系统性能，那么大概率是因为 zone_reclaim_mode 没有设置为 0 ，导致 当本地内存不足的时候，只选择回收本地内存的方式，而不去使用其他 Node 的空闲内存。

虽然说访问远端 Node 的内存比访问本地内存要耗时很多，但是相比内存回收的危害而言，访问 远端 Node 的内存带来的性能影响还是比较小的。因此，zone_reclaim_mode 一般建议设置为 0。

如何保护一个进程不被 OOM 杀掉呢？

在系统空闲内存不足的情况，进程申请了一个很大的内存，如果直接内存回收都无法回收出足够 大的空闲内存，那么就会触发 OOM 机制，内核就会根据算法选择一个进程杀掉。

Linux 到底是根据什么标准来选择被杀的进程呢？这就要提到一个在 Linux 内核里有一个oom_badness() 函数，它会把系统中可以被杀掉的进程扫描一遍，并对每个进程打分，得分最高 的进程就会被首先杀掉。 进程得分的结果受下面这两个方面影响：

• 第一，进程已经使用的物理内存页面数。
• 第二，每个进程的 OOM 校准值 oom_score_adj。

它是可以通过 /proc/[pid]/oom_score_adj 来配置的。我们可以在设置 -1000 到 1000 之间的任意一个数值，调整进程被 OOM Kill 的几率。

函数 oom_badness() 里的最终计算方法是这样的：

用「系统总的可用页面数」乘以 「OOM 校准值 oom_score_adj」再除以 1000，最后再加上进程 已经使用的物理页面数，计算出来的值越大，那么这个进程被 OOM Kill 的几率也就越大。 每个进程的 oom_score_adj 默认值都为 0，所以最终得分跟进程自身消耗的内存有关，消耗的内存越大越容易被杀掉。我们可以通过调整 oom_score_adj 的数值，来改成进程的得分结果：

• 如果你不想某个进程被首先杀掉，那你可以调整该进程的 oom_score_adj，从而改变这个进程 的得分结果，降低该进程被 OOM 杀死的概率。
• 如果你想某个进程无论如何都不能被杀掉，那你可以将 oom_score_adj 配置为 -1000。

但是，不建议将我们自己的业务程序的 oom_score_adj 设置为 -1000，因为业务程序一旦发生了内存泄漏，而它又不能被杀掉，这就会导致随着它的内存开销变大，OOM killer 不停地被唤醒，从 而把其他进程一个个给杀掉。

总结

内核在给应用程序分配物理内存的时候，如果空闲物理内存不够，那么就会进行内存回收的工 作，主要有两种方式：

• 后台内存回收：在物理内存紧张的时候，会唤醒 kswapd 内核线程来回收内存，这个回收内存 的过程异步的，不会阻塞进程的执行。
• 直接内存回收：如果后台异步回收跟不上进程内存申请的速度，就会开始直接回收，这个回收 内存的过程是同步的，会阻塞进程的执行。

可被回收的内存类型有文件页和匿名页：

• 文件页的回收：对于干净页是直接释放内存，这个操作不会影响性能，而对于脏页会先写回到 磁盘再释放内存，这个操作会发生磁盘 I/O 的，这个操作是会影响系统性能的。
• 匿名页的回收：如果开启了 Swap 机制，那么 Swap 机制会将不常访问的匿名页换出到磁盘 中，下次访问时，再从磁盘换入到内存中，这个操作是会影响系统性能的。

文件页和匿名页的回收都是基于 LRU 算法，也就是优先回收不常访问的内存。回收内存的操作基 本都会发生磁盘 I/O 的，如果回收内存的操作很频繁，意味着磁盘 I/O 次数会很多，这个过程势必 会影响系统的性能。

针对回收内存导致的性能影响，常见的解决方式。

• 设置 /proc/sys/vm/swappiness，调整文件页和匿名页的回收倾向，尽量倾向于回收文件页；
• 设置 /proc/sys/vm/min_free_kbytes，调整 kswapd 内核线程异步回收内存的时机；
• 设置 /proc/sys/vm/zone_reclaim_mode，调整 NUMA 架构下内存回收策略，建议设置为 0，这 样在回收本地内存之前，会在其他 Node 寻找空闲内存，从而避免在系统还有很多空闲内存的 情况下，因本地 Node 的本地内存不足，发生频繁直接内存回收导致性能下降的问题；

在经历完直接内存回收后，空闲的物理内存大小依然不够，那么就会触发 OOM 机制，OOM killer 就会根据每个进程的内存占用情况和 oom_score_adj 的值进行打分，得分最高的进程就会被首先杀掉。

我们可以通过调整进程的 /proc/[pid]/oom_score_adj 值，来降低被 OOM killer 杀掉的概率。

在 4GB 物理内存的机器上，申请 8G 内存会怎么样？

「在 4GB 物理内存的机器上，申请 8G 内存会怎么样？」存在比较大的争议， 有人说会申请失败，有的人说可以申请成功。

这个问题在没有前置条件下，就说出答案就是耍流氓。这个问题要考虑三个前置条件：

• 操作系统是 32 位的，还是 64 位的？
• 申请完 8G 内存后会不会被使用？
• 操作系统有没有使用 Swap 机制？

所以，我们要分场景讨论。

操作系统虚拟内存大小

应用程序通过 malloc 函数申请内存的时候，实际上申请的是虚拟内存，此时并不会分配物理内 存。

当应用程序读写了这块虚拟内存，CPU 就会去访问这个虚拟内存， 这时会发现这个虚拟内存没有 映射到物理内存， CPU 就会产生缺页中断，进程会从用户态切换到内核态，并将缺页中断交给内 核的 Page Fault Handler （缺页中断函数）处理。

缺页中断处理函数会看是否有空闲的物理内存：

• 如果有，就直接分配物理内存，并建立虚拟内存与物理内存之间的映射关系。
• 如果没有空闲的物理内存，那么内核就会开始进行回收内存 的工作，如果回收内存工作结束 后，空闲的物理内存仍然无法满足此次物理内存的申请，那么内核就会放最后的大招了触发 OOM （Out of Memory）机制。

32 位操作系统和 64 位操作系统的虚拟地址空间大小是不同的，在 Linux 操作系统中，虚拟地址空 间的内部又被分为内核空间和用户空间两部分，如下所示：

通过这里可以看出：

• 32 位系统的内核空间占用 1G ，位于最高处，剩下的 3G 是用户空间；
• 64 位系统的内核空间和用户空间都是 128T ，分别占据整个内存空间的最高和最低处，剩下的中间部分是未定义的。

32位系统场景

现在可以回答这个问题了：在 32 位操作系统、4GB 物理内存的机器上，申请 8GB 内存，会怎么样？

因为 32 位操作系统，进程最多只能申请 3 GB 大小的虚拟内存空间，所以进程申请 8GB 内存的 话，在申请虚拟内存阶段就会失败（我手上没有 32 位操作系统测试，我估计失败的错误是 cannot allocate memory，也就是无法申请内存失败）。

64位系统场景

在 64 位操作系统、4GB 物理内存的机器上，申请 8G 内存，会怎么样？

64 位操作系统，进程可以使用 128 TB 大小的虚拟内存空间，所以进程申请 8GB 内存是没问题 的，因为进程申请内存是申请虚拟内存，只要不读写这个虚拟内存，操作系统就不会分配物理内 存。

我们可以简单做个测试，我的服务器是 64 位操作系统，但是物理内存只有 2 GB：

现在，我在机器上，连续申请 4 次 1 GB 内存，也就是一共申请了 4 GB 内存，注意下面代码只是 单纯分配了虚拟内存，并没有使用该虚拟内存：

然后运行这个代码，可以看到，我的物理内存虽然只有 2GB，但是程序正常分配了 4GB 大小的虚 拟内存：

我们可以通过下面这条命令查看进程（test）的虚拟内存大小：

其中，VSZ 就代表进程使用的虚拟内存大小，RSS 代表进程使用的物理内存大小。可以看到，VSZ 大小为 4198540，也就是 4GB 的虚拟内存。

之前有读者跟我反馈，说他自己也做了这个实验，然后发现 64 位操作系统，在申请 4GB 虚 拟内存的时候失败了，这是为什么呢？

失败的错误：

我当时帮他排查了下，发现跟 Linux 中的 overcommit_memory 参数有关，可以使用 cat /proc/sys/vm/overcommit_memory 来查看这个参数，这个参数接受三个值：

• 如果值为 0（默认值），代表：Heuristic overcommit handling，它允许overcommit，但过于明 目张胆的overcommit会被拒绝，比如malloc一次性申请的内存大小就超过了系统总内存。 Heuristic的意思是“试探式的”，内核利用某种算法猜测你的内存申请是否合理，大概可以理解为单次申请不能超过free memory + free swap + pagecache的大小 + SLAB中可回收的部分 ，超过了就会拒绝overcommit。
• 如果值为 1，代表：Always overcommit. 允许overcommit，对内存申请来者不拒。
• 如果值为 2，代表：Don’t overcommit. 禁止overcommit。

当时那位读者的 overcommit_memory 参数是默认值 0 ，所以申请失败的原因可能是内核认为我 们申请的内存太大了，它认为不合理，所以 malloc() 返回了 Cannot allocate memory 错误，这里 申请 4GB 虚拟内存失败的同学可以将这个 overcommit_memory 设置为1，就可以 overcommit 了。

设置完为 1 后，读者的机子就可以正常申请 4GB 虚拟内存了。

不过我的环境 overcommit_memory 是 0，在 64 系统、2 G 物理内存场景下，也是可以成功申请 4 G 内存的，我怀疑可能是不同版本的内核在 overcommit_memory 为 0 时，检测内存申请是否合理的算法可能是不同的。

总之，如果你申请大内存的时候，不想被内核检测内存申请是否合理的算法干扰的话，将 overcommit_memory 设置为 1 就行。

那么将这个 overcommit_memory 设置为 1 之后，64 位的主机就可以申请接近 128T 虚拟内 存了吗？

不一定，还得看你服务器的物理内存大小。 读者的服务器物理内存是 2 GB，实验后发现，进程还没有申请到 128T 虚拟内存的时候就被杀死了。

注意，这次是 killed，而不是 Cannot Allocate Memory，说明并不是内存申请有问题，而是触发 OOM 了。

但是为什么会触发 OOM 呢？

那得看你的主机的「物理内存」够不够大了，即使 malloc 申请的是虚拟内存，只要不去访问就不 会映射到物理内存，但是申请虚拟内存的过程中，还是使用到了物理内存（比如内核保存虚拟内 存的数据结构，也是占用物理内存的），如果你的主机是只有 2GB 的物理内存的话，大概率会触 发 OOM。

可以使用 top 命令，点击两下 m，通过进度条观察物理内存使用情况。

可以看到申请虚拟内存的过程中物理内存使用量一直在增长。

直到直接内存回收之后，也无法回收出一块空间供这个进程使用，这个时候就会触发 OOM，给所 有能杀死的进程打分，分数越高的进程越容易被杀死。

在这里当然是这个进程得分最高，那么操作系统就会将这个进程杀死，所以最后会出现 killed，而 不是Cannot allocate memory。

那么 2GB 的物理内存的 64 位操作系统，就不能申请128T的虚拟内存了吗？

其实可以，上面的情况是还没开启 swap 的情况。 使用 swapfile 的方式开启了 1GB 的 swap 空间之后再做实验：

发现出现了 Cannot allocate memory，但是其实到这里已经成功了， 打开计算器计算一下，发现已经申请了 127.998T 虚拟内存了。

实际上我们是不可能申请完整个 128T 的用户空间的，因为程序运行本身也需要申请虚拟空间

申请 127T 虚拟内存试试：

发现进程没有被杀死，也没有 Cannot allocate memory，也正好是 127T 虚拟内存空间。 在 top 中我们可以看到这个申请了127T虚拟内存的进程。

Swap机制的作用

前面讨论在 32 位/64 位操作系统环境下，申请的虚拟内存超过物理内存后会怎么样？

• 在 32 位操作系统，因为进程最大只能申请 3 GB 大小的虚拟内存，所以直接申请 8G 内存，会申请失败。
• 在 64 位操作系统，因为进程最大只能申请 128 TB 大 小的虚拟内存，即使物理内存只有 4GB， 申请 8G 内存也是没问题，因为申请的内存是虚拟内存。

程序申请的虚拟内存，如果没有被使用，它是不会占用物理空间的。当访问这块虚拟内存后，操 作系统才会进行物理内存分配。

如果申请物理内存大小超过了空闲物理内存大小，就要看操作系统有没有开启 Swap 机制：

• 如果没有开启 Swap 机制，程序就会直接 OOM
• 如果有开启 Swap 机制，程序可以正常运行。

什么是 Swap 机制？

当系统的物理内存不够用的时候，就需要将物理内存中的一部分空间释放出来，以供当前运行的 程序使用。那些被释放的空间可能来自一些很长时间没有什么操作的程序，这些被释放的空间会 被临时保存到磁盘，等到那些程序要运行时，再从磁盘中恢复保存的数据到内存中。

另外，当内存使用存在压力的时候，会开始触发内存回收行为，会把这些不常访问的内存先写到 磁盘中，然后释放这些内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入 内存就可以了。

这种，将内存数据换出磁盘，又从磁盘中恢复数据到内存的过程，就是 Swap 机制负责的。

Swap 就是把一块磁盘空间或者本地文件，当成内存来使用，它包含换出和换入两个过程：

• 换出（Swap Out） ，是把进程暂时不用的内存数据存储到磁盘中，并释放这些数据占用的内存；
• 换入（Swap In），是在进程再次访问这些内存的时候，把它们从磁盘读到内存中来；

Swap 换入换出的过程如下图：

使用 Swap 机制优点是，应用程序实际可以使用的内存空间将远远超过系统的物理内存。由于硬盘 空间的价格远比内存要低，因此这种方式无疑是经济实惠的。当然，频繁地读写硬盘，会显著降 低操作系统的运行速率，这也是 Swap 的弊端。

Linux 中的 Swap 机制会在内存不足和内存闲置的场景下触发：

• 内存不足：当系统需要的内存超过了可用的物理内存时，内核会将内存中不常使用的内存页交换到磁盘上为当前进程让出内存，保证正在执行的进程的可用性，这个内存回收的过程是强制地直接内存回收（Direct Page Reclaim）。直接内存回收是同步的过程，会阻塞当前申请内存的进程。
• 内存闲置：应用程序在启动阶段使用的大量内存在启动后往往都不会使用，通过后台运行的守 护进程（kSwapd），我们可以将这部分只使用一次的内存交换到磁盘上为其他内存的申请预留空间。kSwapd 是 Linux 负责页面置换（Page replacement）的守护进程，它也是负责交换闲置 内存的主要进程，它会在空闲内存低于一定水位时，回收内存页中的空闲内存保证系统中的 其他进程可以尽快获得申请的内存。kSwapd 是后台进程，所以回收内存的过程是异步的，不会阻塞当前申请内存的进程。

Linux 提供了两种不同的方法启用 Swap，分别是 Swap 分区（Swap Partition）和 Swap 文件 （Swapfile），开启方法可以看这个资料 ：

• Swap 分区是硬盘上的独立区域，该区域只会用于交换分区，其他的文件不能存储在该区域上， 我们可以使用 swapon -s 命令查看当前系统上的交换分区；
• Swap 文件是文件系统中的特殊文件，它与文件系统中的其他文件也没有太多的区别；

Swap 换入换出的是什么类型的内存？

内核缓存的文件数据，因为都有对应的磁盘文件，所以在回收文件数据的时候， 直接写回到对应 的文件就可以了。

但是像进程的堆、栈数据等，它们是没有实际载体，这部分内存被称为匿名页。而且这部分内存 很可能还要再次被访问，所以不能直接释放内存，于是就需要有一个能保存匿名页的磁盘载体， 这个载体就是 Swap 分区。

匿名页回收的方式是通过 Linux 的 Swap 机制，Swap 会把不常访问的内存先写到磁盘中，然后释 放这些内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入内存就可以了。

接下来，通过两个实验，看看申请的物理内存超过物理内存会怎样？

• 实验一：没有开启 Swap 机制
• 实验二：有开启 Swap 机制

实验一：没有开启Swap机制

我的服务器是 64 位操作系统，但是物理内存只有 2 GB，而且没有 Swap 分区：

我们改一下前面的代码，使得在申请完 4GB 虚拟内存后，通过 memset 函数访问这个虚拟内存， 看看在没有 Swap 分区的情况下，会发生什么？

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#define MEM_SIZE 1024 * 1024 * 1024
int main() {
char* addr[4];
int i = 0;
for(i = 0; i < 4; ++i) {
addr[i] = (char*) malloc(MEM_SIZE);
if(!addr[i]) {
printf("执行 malloc 失败, 错误：%s\n",strerror(errno));
return -1;
}
printf("主线程调用malloc后，申请1gb大小得内存，此内存起始地址：0X%p\n", addr[i]);
}
for(i = 0; i < 4; ++i) {
printf("开始访问第 %d 块虚拟内存(每一块虚拟内存为 1 GB)\n", i + 1);
memset(addr[i], 0, MEM_SIZE);
}
//输入任意字符后，才结束
getchar();
return 0;
}

运行结果：

可以看到，在访问第 2 块虚拟内存（每一块虚拟内存是 1 GB）的时候，因为超过了机器的物理内 存（2GB），进程（test）被操作系统杀掉了。

通过查看 message 系统日志，可以发现该进程是被操作系统 OOM killer 机制杀掉了，日志里报错 了 Out of memory，也就是发生 OOM（内存溢出错误）。

实验二：有开启Swap机制

我用我的 mac book pro 笔记本做测试，我的笔记本是 64 位操作系统，物理内存是 8 GB， 目前 Swap 分区大小为 1 GB（注意这个大小不是固定不变的，Swap 分区总大小是会动态变化的，当没 有使用 Swap 分区时，Swap 分区总大小是 0；当使用了 Swap 分区，Swap 分区总大小会增加至 1 GB；当 Swap 分区已使用的大小超过 1 GB 时；Swap 分区总大小就会增加到至 2 GB；当 Swap 分 区已使用的大小超过 2 GB 时；Swap 分区总大小就增加至 3GB，如此往复。这个估计是 macos 自 己实现的，Linux 的分区则是固定大小的，Swap 分区不会根据使用情况而自动增长）。

为了方便观察磁盘 I/O 情况，我们改进一下前面的代码，分配完 32 GB虚拟内存后（笔记本物理内存是 8 GB），通过一个 while 循环频繁访问虚拟内存，代码如下：

运行结果如下：

可以看到，在有 Swap 分区的情况下，即使笔记本物理内存是 8 GB，申请并使用 32 GB 内存是没 问题，程序正常运行了，并没有发生 OOM。

从下图可以看到，进程的内存显示 32 GB（这个不要理解为占用的物理内存，理解为已被访问的虚拟内存大小，也就是在物理内存呆过的内存大小），系统已使用的 Swap 分区达到 2.3 GB。

此时我的笔记本电脑的磁盘开始出现“沙沙”的声音,通过查看磁盘的 I/O 情况，可以看到磁盘 I/O 达到了一个峰值，非常高：

有了 Swap 分区，是不是意味着进程可以使用的内存是无上限的？

当然不是，我把上面的代码改成了申请 64GB 内存后，当进程申请完 64GB 虚拟内存后，使用到 56 GB （这个不要理解为占用的物理内存，理解为已被访问的虚拟内存大小，也就是在物理内存呆 过的内存大小）的时候，进程就被系统 kill 掉了，如下图

当系统多次尝试回收内存，还是无法满足所需使用的内存大小，进程就会被系统 kill 掉了，意味着发生了OOM

总结

至此， 验证完成了。简单总结下：

• 在 32 位操作系统，因为进程理论上最大能申请 3 GB 大小的虚拟内存，所以直接申请 8G 内 存，会申请失败。
• 在 64位 位操作系统，因为进程理论上最大能申请 128 TB 大小的虚拟内存，即使物理内存只有 4GB，申请 8G 内存也是没问题，因为申请的内存是虚拟内存。如果这块虚拟内存被访问了，要 看系统有没有 Swap 分区：

1. 如果没有 Swap 分区，因为物理空间不够，进程会被操作系统杀掉，原因是 OOM（内存溢 出）；
2. 如果有 Swap 分区，即使物理内存只有 4GB，程序也能正常使用 8GB 的内存，进程可以正常 运行；

如何避免预读失效和缓存污染的问题？

面试问题：

咋一看，以为是在问操作系统的问题，其实这两个题目都是在问如何改进 LRU 算法。 因为传统的 LRU 算法存在这两个问题： 「预读失效」导致缓存命中率下降（对应第一个题目） 「缓存污染」导致缓存命中率下降（对应第二个题目） Redis 的缓存淘汰算法则是通过实现 LFU 算法来避免「缓存污染」而导致缓存命中率下降的 问题（Redis 没有预读机制）。 MySQL 和 Linux 操作系统是通过改进 LRU 算法来避免「预读失效和缓存污染」而导致缓存 命中率下降的问题。 这次，就重点讲讲 MySQL 和 Linux 操作系统是如何改进 LRU 算法的？ 好了，开始发车，坐稳了！

Linux和MySQL的缓存

Linux操作系统的缓存

在应用程序读取文件的数据的时候，Linux 操作系统是会对读取的文件数据进行缓存的，会缓存在文件系统中的 Page Cache（如下图中的页缓存）。

Page Cache 属于内存空间里的数据，由于内存访问比磁盘访问快很多，在下一次访问相同的数据 就不需要通过磁盘 I/O 了，命中缓存就直接返回数据即可。

因此，Page Cache 起到了加速访问数据的作用。

MySQL的缓存

MySQL 的数据是存储在磁盘里的，为了提升数据库的读写性能，Innodb 存储引擎设计了一个缓冲 池（Buffer Pool），Buffer Pool 属于内存空间里的数据。

有了缓冲池后：

• 当读取数据时，如果数据存在于 Buffer Pool 中，客户端就会直接读取 Buffer Pool 中的数据， 否则再去磁盘中读取。
• 当修改数据时，首先是修改 Buffer Pool 中数据所在的页，然后将其页设置为脏页，最后由后台 线程将脏页写入到磁盘。

传统LRU是如何管理内存数据

Linux 的 Page Cache 和 MySQL 的 Buffer Pool 的大小是有限的，并不能无限的缓存数据，对于一 些频繁访问的数据我们希望可以一直留在内存中，而一些很少访问的数据希望可以在某些时机可 以淘汰掉，从而保证内存不会因为满了而导致无法再缓存新的数据，同时还能保证常用数据留在 内存中。

要实现这个，最容易想到的就是 LRU（Least recently used）算法。

LRU 算法一般是用「链表」作为数据结构来实现的，链表头部的数据是最近使用的，而链表末尾 的数据是最久没被使用的。那么，当空间不够了，就淘汰最久没被使用的节点，也就是链表末尾 的数据，从而腾出内存空间。

因为 Linux 的 Page Cache 和 MySQL 的 Buffer Pool 缓存的基本数据单位都是页（Page）单位，所以后续以「页」名称代替「数据」。

传统的 LRU 算法的实现思路是这样的：

• 当访问的页在内存里，就直接把该页对应的 LRU 链表节点移动到链表的头部。
• 当访问的页不在内存里，除了要把该页放入到 LRU 链表的头部，还要淘汰 LRU 链表末尾的页。

比如下图，假设 LRU 链表长度为 5，LRU 链表从左到右有编号为 1，2，3，4，5 的页。

如果访问了 3 号页，因为 3 号页已经在内存了，所以把 3 号页移动到链表头部即可，表示最近被 访问了。

而如果接下来，访问了 8 号页，因为 8 号页不在内存里，且 LRU 链表长度为 5，所以必须要淘汰数据，以腾出内存空间来缓存 8 号页，于是就会淘汰末尾的 5 号页，然后再将 8 号页加入到头部。

传统的 LRU 算法并没有被 Linux 和 MySQL 使用，因为传统的 LRU 算法无法避免下面这两个问 题：

• 预读失效导致缓存命中率下降；
• 缓存污染导致缓存命中率下降；

预读失效，怎么办？

什么是预读机制？

Linux 操作系统为基于 Page Cache 的读缓存机制提供预读机制，一个例子是：

• 应用程序只想读取磁盘上文件 A 的 offset 为 0-3KB 范围内的数据，由于磁盘的基本读写单位为 block（4KB），于是操作系统至少会读 0-4KB 的内容，这恰好可以在一个 page 中装下。
• 但是操作系统出于空间局部性原理（靠近当前被访问数据的数据，在未来很大概率会被访问 到），会选择将磁盘块 offset [4KB,8KB)、[8KB,12KB) 以及 [12KB,16KB) 都加载到内存，于是额外在内存中申请了 3 个 page；

下图代表了操作系统的预读机制：

上图中，应用程序利用 read 系统调动读取 4KB 数据，实际上内核使用预读机制（ReadaHead） 机制完成了 16KB 数据的读取，也就是通过一次磁盘顺序读将多个 Page 数据装入 Page Cache。

这样下次读取 4KB 数据后面的数据的时候，就不用从磁盘读取了，直接在 Page Cache 即可命中数 据。因此，预读机制带来的好处就是减少了 磁盘 I/O 次数，提高系统磁盘 I/O 吞吐量。

MySQL Innodb 存储引擎的 Buffer Pool 也有类似的预读机制，MySQL 从磁盘加载页时，会提前把 它相邻的页一并加载进来，目的是为了减少磁盘 IO。

预读失效会带来什么问题？

如果这些被提前加载进来的页，并没有被访问，相当于这个预读工作是白做了，这个就是预读失 效。

如果使用传统的 LRU 算法，就会把「预读页」放到 LRU 链表头部，而当内存空间不够的时候，还 需要把末尾的页淘汰掉。

如果这些「预读页」如果一直不会被访问到，就会出现一个很奇怪的问题，不会被访问的预读页 却占用了 LRU 链表前排的位置，而末尾淘汰的页，可能是热点数据，这样就大大降低了缓存命中 率 。

如何避免预读失效造成的影响？

我们不能因为害怕预读失效，而将预读机制去掉，大部分情况下，空间局部性原理还是成立的。

要避免预读失效带来影响，最好就是让预读页停留在内存里的时间要尽可能的短，让真正被访问 的页才移动到 LRU 链表的头部，从而保证真正被读取的热数据留在内存里的时间尽可能长。

那到底怎么才能避免呢？

Linux 操作系统和 MySQL Innodb 通过改进传统 LRU 链表来避免预读失效带来的影响，具体的改 进分别如下：

• Linux 操作系统实现两个了 LRU 链表：活跃 LRU 链表（active_list）和非活跃 LRU 链表 （inactive_list）；
• MySQL 的 Innodb 存储引擎是在一个 LRU 链表上划分来 2 个区域：young 区域 和 old 区域。

这两个改进方式，设计思想都是类似的，都是将数据分为了冷数据和热数据，然后分别进行 LRU 算法。不再像传统的 LRU 算法那样，所有数据都只用一个 LRU 算法管理。

接下来，具体聊聊 Linux 和 MySQL 是如何避免预读失效带来的影响？

Linux 是如何避免预读失效带来的影响？

Linux 操作系统实现两个了 LRU 链表：活跃 LRU 链表（active_list）和非活跃 LRU 链表 （inactive_list）。

• active list 活跃内存页链表，这里存放的是最近被访问过（活跃）的内存页；
• inactive list 不活跃内存页链表，这里存放的是很少被访问（非活跃）的内存页；

有了这两个 LRU 链表后，预读页就只需要加入到 inactive list 区域的头部，当页被真正访问的时 候，才将页插入 active list 的头部。如果预读的页一直没有被访问，就会从 inactive list 移除，这 样就不会影响 active list 中的热点数据。

接下来，给大家举个例子。

假设 active list 和 inactive list 的长度为 5，目前内存中已经有如下 10 个页：

现在有个编号为 20 的页被预读了，这个页只会被插入到 inactive list 的头部，而 inactive list 末尾 的页（10号）会被淘汰掉。

即使编号为 20 的预读页一直不会被访问，它也没有占用到 active list 的位置，而且还会比 active list 中的页更早被淘汰出去。

如果 20 号页被预读后，立刻被访问了，那么就会将它插入到 active list 的头部， active list 末尾的 页（5号），会被降级到 inactive list ，作为 inactive list 的头部，这个过程并不会有数据被淘汰。

MySQL 是如何避免预读失效带来的影响？

MySQL 的 Innodb 存储引擎是在一个 LRU 链表上划分来 2 个区域，young 区域 和 old 区域。

young 区域在 LRU 链表的前半部分，old 区域则是在后半部分，这两个区域都有各自的头和尾节 点，如下图：

young 区域与 old 区域在 LRU 链表中的占比关系并不是一比一的关系，而是 63:37（默认比例） 的关系。

划分这两个区域后，预读的页就只需要加入到 old 区域的头部，当页被真正访问的时候，才将页 插入 young 区域的头部。如果预读的页一直没有被访问，就会从 old 区域移除，这样就不会影响 young 区域中的热点数据。

接下来，给大家举个例子。

假设有一个长度为 10 的 LRU 链表，其中 young 区域占比 70 %，old 区域占比 30 %。

现在有个编号为 20 的页被预读了，这个页只会被插入到 old 区域头部，而 old 区域末尾的页（10 号）会被淘汰掉。

如果 20 号页一直不会被访问，它也没有占用到 young 区域的位置，而且还会比 young 区域的数 据更早被淘汰出去。

如果 20 号页被预读后，立刻被访问了，那么就会将它插入到 young 区域的头部，young 区域末 尾的页（7号），会被挤到 old 区域，作为 old 区域的头部，这个过程并不会有页被淘汰。

缓存污染，怎么办？

什么是缓存污染？

虽然 Linux （实现两个 LRU 链表）和 MySQL （划分两个区域）通过改进传统的 LRU 数据结构， 避免了预读失效带来的影响。

但是如果还是使用「只要数据被访问一次，就将数据加入到活跃 LRU 链表头部（或者 young 区 域）」这种方式的话，那么还存在缓存污染的问题。

当我们在批量读取数据的时候，由于数据被访问了一次，这些大量数据都会被加入到「活跃 LRU 链表」里，然后之前缓存在活跃 LRU 链表（或者 young 区域）里的热点数据全部都被淘汰了，如 果这些大量的数据在很长一段时间都不会被访问的话，那么整个活跃 LRU 链表（或者 young 区 域）就被污染了。

缓存污染会带来什么问题？

缓存污染带来的影响就是很致命的，等这些热数据又被再次访问的时候，由于缓存未命中，就会 产生大量的磁盘 I/O，系统性能就会急剧下降。

我以 MySQL 举例子，Linux 发生缓存污染的现象也是类似。

当某一个 SQL 语句扫描了大量的数据时，在 Buffer Pool 空间比较有限的情况下，可能会将 Buffer Pool 里的所有页都替换出去，导致大量热数据被淘汰了，等这些热数据又被再次访问的时候，由 于缓存未命中，就会产生大量的磁盘 I/O，MySQL 性能就会急剧下降。

注意， 缓存污染并不只是查询语句查询出了大量的数据才出现的问题，即使查询出来的结果集很 小，也会造成缓存污染。

比如，在一个数据量非常大的表，执行了这条语句：

select * from t_user where name like "%xiaolin%"

可能这个查询出来的结果就几条记录，但是由于这条语句会发生索引失效，所以这个查询过程是 全表扫描的，接着会发生如下的过程：

1. 从磁盘读到的页加入到 LRU 链表的 old 区域头部；
2. 当从页里读取行记录时，也就是页被访问的时候，就要将该页放到 young 区域头部；
3. 接下来拿行记录的 name 字段和字符串 xiaolin 进行模糊匹配，如果符合条件，就加入到结果集里；
4. 如此往复，直到扫描完表中的所有记录。

经过这一番折腾，由于这条 SQL 语句访问的页非常多，每访问一个页，都会将其加入 young 区域 头部，那么原本 young 区域的热点数据都会被替换掉，导致缓存命中率下降。那些在批量扫描 时，而被加入到 young 区域的页，如果在很长一段时间都不会再被访问的话，那么就污染了 young 区域。

举个例子，假设需要批量扫描：21，22，23，24，25 这五个页，这些页都会被逐一访问（读取页 里的记录）。

在批量访问这些页的时候，会被逐一插入到 young 区域头部。

可以看到，原本在 young 区域的 6 和 7 号页都被淘汰了，而批量扫描的页基本占满了 young 区 域，如果这些页在很长一段时间都不会被访问，那么就对 young 区域造成了污染。

如果 6 和 7 号页是热点数据，那么在被淘汰后，后续有 SQL 再次读取 6 和 7 号页时，由于缓存未 命中，就要从磁盘中读取了，降低了 MySQL 的性能，这就是缓存污染带来的影响。

怎么避免缓存污染造成的影响？

前面的 LRU 算法只要数据被访问一次，就将数据加入活跃 LRU 链表（或者 young 区域），这种 LRU 算法进入活跃 LRU 链表的门槛太低了！正式因为门槛太低，才导致在发生缓存污染的时候， 很容就将原本在活跃 LRU 链表里的热点数据淘汰了。

所以，只要我们提高进入到活跃 LRU 链表（或者 young 区域）的门槛，就能有效地保证活跃 LRU 链表（或者 young 区域）里的热点数据不会被轻易替换掉。

Linux 操作系统和 MySQL Innodb 存储引擎分别是这样提高门槛的：

• Linux 操作系统：在内存页被访问第二次的时候，才将页从 inactive list 升级到 active list 里。
• MySQL Innodb：在内存页被访问第二次的时候，并不会马上将该页从 old 区域升级到 young 区域，因为还要进行停留在 old 区域的时间判断：

1. 如果第二次的访问时间与第一次访问的时间在 1 秒内（默认值），那么该页就不会被从 old 区域升级到 young 区域；
2. 如果第二次的访问时间与第一次访问的时间超过 1 秒，那么该页就会从 old 区域升级到 young 区域；

提高了进入活跃 LRU 链表（或者 young 区域）的门槛后，就很好了避免缓存污染带来的影响。

在批量读取数据时候，如果这些大量数据只会被访问一次，那么它们就不会进入到活跃 LRU 链表 （或者 young 区域），也就不会把热点数据淘汰，只会待在非活跃 LRU 链表（或者 old 区域） 中，后续很快也会被淘汰。

总结

传统的 LRU 算法法无法避免下面这两个问题：

• 预读失效导致缓存命中率下降；
• 缓存污染导致缓存命中率下降；

为了避免「预读失效」造成的影响，Linux 和 MySQL 对传统的 LRU 链表做了改进：

Linux 操作系统实现两个了 LRU 链表：活跃 LRU 链表（active list）和非活跃 LRU 链表 （inactive list）。

MySQL Innodb 存储引擎是在一个 LRU 链表上划分来 2 个区域：young 区域 和 old 区域。

但是如果还是使用「只要数据被访问一次，就将数据加入到活跃 LRU 链表头部（或者 young 区 域）」这种方式的话，那么还存在缓存污染的问题。

为了避免「缓存污染」造成的影响，Linux 操作系统和 MySQL Innodb 存储引擎分别提高了升级为 热点数据的门槛：

• Linux 操作系统：在内存页被访问第二次的时候，才将页从 inactive list 升级到 active list 里。
• MySQL Innodb：在内存页被访问第二次的时候，并不会马上将该页从 old 区域升级到 young 区域，因为还要进行停留在 old 区域的时间判断：

1. 如果第二次的访问时间与第一次访问的时间在 1 秒内（默认值），那么该页就不会被从 old 区域升级到 young 区域；
2. 如果第二次的访问时间与第一次访问的时间超过 1 秒，那么该页就会从 old 区域升级到 young 区域；

通过提高了进入 active list （或者 young 区域）的门槛后，就很好了避免缓存污染带来的影响。 完！