重学操作系统(5)

笔记整理来自拉钩教育

24 | 虚拟内存 ：一个程序最多能使用多少内存？

这个模块我们开始学习操作系统的内存管理，接下来我会先用 3 节课讲解操作系统对内存管理的原理。因为内存资源总是稀缺的，即便在拥有百 G 内存的机器上，我们都可以轻易把内存填满。为了解决这个问题，就需要用到虚拟化技术。

因此，本模块前面 3 讲将围绕虚拟化技术展开：第 24 讲介绍设计思想；第 25 讲介绍优化手段；第 26 讲挑选了对你工作比较有帮助的缓存置换算法深入讲解。

后面的第 27、28 讲将围绕内存回收（GC）讲解，GC 是面试的高频重点知识，同时也是程序员日常开发需要理解的部分。学习 GC 有助于你优化你开发应用的性能，特别是遇到内存不够用不会束手无策。

今天我们先学习内存的虚拟化技术。

内存是稀缺的，随着应用使用内存也在膨胀。当程序越来复杂，进程对内存的需求会越来越大。从安全角度考虑，进程间使用内存需要隔离。另外还有一些特殊场景，比如说，我在“模块四加餐”中提到的内存一致性问题，存在不希望 CPU 进行缓存的场景。 这个时候，有一个虚拟化层承接各种各样的诉求，统一进行处理，就会有很大的优势。

还有一个大家普遍关心的问题，也是这节课我给大家带来的面试题：一个程序最多能使用多少内存?

要回答这个问题，就需要对内存的虚拟化有一定的认识。接下来就请你带着问题，和我一起学习“内存的虚拟化技术”。

为什么内存不够用？

要理解一个技术，就必须理解它为何而存在。总体来说，虚拟化技术是为了解决内存不够用的问题，那么内存为何不够用呢？

主要是因为程序越来越复杂。比如说我现在给你录音的机器上就有 200 个进程，目前内存的消耗是 21G，我的内存是 64G 的，但是多开一些程序还是会被占满。 另外，如果一个程序需要使用大的内存，比如 1T，是不是应该报错？如果报错，那么程序就会不好写，程序员必须小心翼翼地处理内存的使用，避免超过允许的内存使用阈值。以上提到的这些都是需要解决的问题，也是虚拟化技术存在的价值和意义。

那么如何来解决这些问题呢？ 历史上有过不少的解决方案，但最终沉淀下的是虚拟化技术。接下来我为你介绍一种历史上存在过的 Swap 技术以及虚拟化技术。

交换（Swap）技术

Swap 技术允许一部分进程使用内存，不使用内存的进程数据先保存在磁盘上。注意，这里提到的数据，是完整的进程数据，包括正文段（程序指令）、数据段、堆栈段等。轮到某个进程执行的时候，尝试为这个进程在内存中找到一块空闲的区域。如果空间不足，就考虑把没有在执行的进程交换（Swap）到磁盘上，把空间腾挪出来给需要的进程。

上图中，内存被拆分成多个区域。 内核作为一个程序也需要自己的内存。另外每个进程独立得到一个空间——我们称为地址空间（Address Space）。你可以认为地址空间是一块连续分配的内存块。每个进程在不同地址空间中工作，构成了一个原始的虚拟化技术。

比如：当进程 A 想访问地址 100 的时候，实际上访问的地址是基于地址空间本身位置（首字节地址）计算出来的。另外，当进程 A 执行时，CPU 中会保存它地址空间的开始位置和结束位置，当它想访问超过地址空间容量的地址时，CPU 会检查然后报错。

上图描述的这种方法，是一种比较原始的虚拟化技术，进程使用的是基于地址空间的虚拟地址。但是这种方案有很多明显的缺陷，比如：

1. 碎片问题：上图中我们看到进程来回分配、回收交换，内存之间会产生很多缝隙。经过反反复复使用，内存的情况会变得十分复杂，导致整体性能下降。
2. 频繁切换问题：如果进程过多，内存较小，会频繁触发交换。

你可以先思考这两个问题的解决方案，接下来我会带你进行一些更深入地思考——首先重新 Review 下我们的设计目标。

1. 隔离：每个应用有自己的地址空间，互不影响。
2. 性能：高频使用的数据保留在内存中、低频使用的数据持久化到磁盘上。
3. 程序好写（降低程序员心智负担）：让程序员不用关心底层设施。

现阶段，Swap 技术已经初步解决了问题 1。关于问题 2，Swap 技术在性能上存在着碎片、频繁切换等明显劣势。关于问题 3，使用 Swap 技术，程序员需要清楚地知道自己的应用用多少内存，并且小心翼翼地使用内存，避免需要重新申请，或者研发不断扩容的算法——这让程序心智负担较大。

经过以上分析，需要更好的解决方案，就是我们接下来要学习的虚拟化技术。

虚拟内存

虚拟化技术中，操作系统设计了虚拟内存（理论上可以无限大的空间），受限于 CPU 的处理能力，通常 64bit CPU，就是 2^64 个地址。

虚拟化技术中，应用使用的是虚拟内存，操作系统管理虚拟内存和真实内存之间的映射。操作系统将虚拟内存分成整齐小块，每个小块称为一个页（Page）。之所以这样做，原因主要有以下两个方面。

• 一方面应用使用内存是以页为单位，整齐的页能够避免内存碎片问题。
• 另一方面，每个应用都有高频使用的数据和低频使用的数据。这样做，操作系统就不必从应用角度去思考哪个进程是高频的，仅需思考哪些页被高频使用、哪些页被低频使用。如果是低频使用，就将它们保存到硬盘上；如果是高频使用，就让它们保留在真实内存中。

如果一个应用需要非常大的内存，应用申请的是虚拟内存中的很多个页，真实内存不一定需要够用。

页（Page）和页表

接下来，我们详细讨论下这个设计。操作系统将虚拟内存分块，每个小块称为一个页（Page）；真实内存也需要分块，每个小块我们称为一个 Frame。Page 到 Frame 的映射，需要一种叫作页表的结构。

上图展示了 Page、Frame 和页表 （PageTable）三者之间的关系。 Page 大小和 Frame 大小通常相等，页表中记录的某个 Page 对应的 Frame 编号。页表也需要存储空间，比如虚拟内存大小为 10G， Page 大小是 4K，那么需要 10G/4K = 2621440 个条目。如果每个条目是 64bit，那么一共需要 20480K = 20M 页表。操作系统在内存中划分出小块区域给页表，并负责维护页表。

页表维护了虚拟地址到真实地址的映射。每次程序使用内存时，需要把虚拟内存地址换算成物理内存地址，换算过程分为以下 3 个步骤：

1. 通过虚拟地址计算 Page 编号；
2. 查页表，根据 Page 编号，找到 Frame 编号；
3. 将虚拟地址换算成物理地址。

下面我通过一个例子给你讲解上面这个换算的过程：如果页大小是 4K，假设程序要访问地址：100,000。那么计算过程如下。

1. 页编号（Page Number） = 100,000/4096 = 24 余1619。 24 是页编号，1619 是地址偏移量（Offset）。
2. 查询页表，得到 24 关联的 Frame 编号（假设查到 Frame 编号 = 10）。
3. 换算：通常 Frame 和 Page 大小相等，替换 Page Number 为 Frame Number 物理地址 = 4096 * 10 + 1619 = 42579。

MMU

上面的过程发生在 CPU 中一个小型的设备——内存管理单元（Memory Management Unit， MMU）中。如下图所示：

当 CPU 需要执行一条指令时，如果指令中涉及内存读写操作，CPU 会把虚拟地址给 MMU，MMU 自动完成虚拟地址到真实地址的计算；然后，MMU 连接了地址总线，帮助 CPU 操作真实地址。

这样的设计，就不需要在编写应用程序的时候担心虚拟地址到物理地址映射的问题。我们把全部难题都丢给了操作系统——操作系统要确定MMU 可以读懂自己的页表格式。所以，操作系统的设计者要看 MMU 的说明书完成工作。

难点在于不同 CPU 的 MMU 可能是不同的，因此这里会遇到很多跨平台的问题。解决跨平台问题不但有繁重的工作量，更需要高超的编程技巧，Unix 最初期的移植性（跨平台）是 C 语言作者丹尼斯·里奇实现的。

学到这里，细心的同学可能会有疑问：MMU 需要查询页表（这是内存操作），而 CPU 执行一条指令通过 MMU 获取内存数据，难道可以容忍在执行一条指令的过程中，发生多次内存读取（查询）操作？难道一次普通的读取操作，还要附加几次查询页表的开销吗？当然不是，这里还有一些高速缓存的设计，这部分我们放到“25 讲”中详细讨论。

页表条目

上面我们笼统介绍了页表将 Page 映射到 Frame。那么，页表中的每一项（页表条目）长什么样子呢？下图是一个页表格式的一个演示。

页表条目本身的编号可以不存在页表中，而是通过偏移量计算。 比如地址 100,000 的编号，可以用 100,000 除以页大小确定。

• Absent（“在”）位，是一个 bit。0 表示页的数据在磁盘中（不再内存中），1 表示在内存中。如果读取页表发现 Absent = 0，那么会触发缺页中断，去磁盘读取数据。
• Protection（保护）字段可以实现成 3 个 bit，它决定页表用于读、写、执行。比如 000 代表什么都不能做，100 代表只读等。
• Reference（访问）位，代表这个页被读写过，这个记录对回收内存有帮助。
• Dirty（“脏”）位，代表页的内容被修改过，如果 Dirty =1，那么意味着页面必须回写到磁盘上才能置换（Swap)。如果 Dirty = 0，如果需要回收这个页，可以考虑直接丢弃它（什么也不做，其他程序可以直接覆盖）。
• Caching（缓存位），描述页可不可以被 CPU 缓存。CPU 缓存会造成内存不一致问题，在上个模块的加餐中我们讨论了内存一致性问题，具体你可以参考“模块四”的加餐内容。
• Frame Number（Frame 编号），这个是真实内存的位置。用 Frame 编号乘以页大小，就可以得到 Frame 的基地址。

在 64bit 的系统中，考虑到 Absent、Protection 等字段需要占用一定的位，因此不能将 64bit 都用来描述真实地址。但是 64bit 可以寻址的空间已经远远超过了 EB 的级别（1EB = 220TB），这已经足够了。在真实世界，我们还造不出这么大的内存呢。

大页面问题

最后，我们讨论一下大页面的问题。假设有一个应用，初始化后需要 12M 内存，操作系统页大小是 4K。那么应该如何设计呢？

为了简化模型，下图中，假设这个应用只有 3 个区域（3 个段）——正文段（程序）、数据段（常量、全局变量）、堆栈段。一开始我们 3 个段都分配了 4M 的空间。随着程序执行，堆栈段的空间会继续增加，上不封顶。

上图中，进程内部需要一个页表存储进程的数据。如果进程的内存上不封顶，那么页表有多少个条目合适呢？ 进程分配多少空间合适呢？ 如果页表大小为 1024 个条目，那么可以支持 1024*4K = 4M 空间。按照这个计算，如果进程需要 1G 空间，则需要 256K 个条目。我们预先为进程分配这 256K 个条目吗？ 创建一个进程就划分这么多条目是不是成本太高了？

为了减少条目的创建，可以考虑进程内部用一个更大的页表（比如 4M），操作系统继续用 4K 的页表。这就形成了一个二级页表的结构，如下图所示：

这样 MMU 会先查询 1 级页表，再查询 2 级页表。在这个模型下，进程如果需要 1G 空间，也只需要 1024 个条目。比如 1 级页编号是 2， 那么对应 2 级页表中 [2* 1024, 3*1024-1] 的部分条目。而访问一个地址，需要同时给出一级页编号和二级页编号。整个地址，还可以用 64bit 组装，如下图所示：

MMU 根据 1 级编号找到 1 级页表条目，1 级页表条目中记录了对应 2 级页表的位置。然后 MMU 再查询 2 级页表，找到 Frame。最后通过地址偏移量和 Frame 编号计算最终的物理地址。这种设计是一个递归的过程，因此还可增加 3 级、4 级……每增加 1 级，对空间的利用都会提高——当然也会带来一定的开销。这对于大应用非常划算，比如需要 1T 空间，那么使用 2 级页表，页表的空间就节省得多了。而且，这种多级页表，顶级页表在进程中可以先只创建需要用到的部分，就这个例子而言，一开始只需要 3 个条目，从 256K 个条目到 3 个，这就大大减少了进程创建的成本。

总结

那么通过这节课的学习，你现在可以尝试来回答本节关联的面试题目：一个程序最多能使用多少内存？

【解析】 目前我们主要都是在用 64bit 的机器。因为 2^64 数字过于大，即便是虚拟内存都不需要这么大的空间。因此通常操作系统会允许进程使用非常大，但是不到 2^64 的地址空间。通常是几十到几百 EB（1EB = 106TB = 109GB)。

思考题

最后我再给你出一道需要查资料的思考题：可不可以利用哈希表直接将页编号映射到 Frame 编号？

25 | 内存管理单元： 什么情况下使用大内存分页？

今天我们的学习目标是：了解如何通过内存，提升你的程序性能。这一讲我带来了一道和内存优化相关的面试题：什么情况下使用大内存分页？

这道题目属于一个实用技巧，可以作为你积累高并发处理技能的一个小小的组成部分。要理解和解决这个问题，我们还需要在上一讲的基础上，继续挖掘虚拟内存和内存管理单元更底层的工作原理，以及了解转置检测缓冲区（TLB）的作用。

那么接下来就请你带着这个优化问题，和我一起开始学习今天的内容。

内存管理单元

上一讲我们学习了虚拟地址到物理地址的转换过程。如下图所示：

你可以把虚拟地址看成由页号和偏移量组成，把物理地址看成由 Frame Number 和偏移量组成。在 CPU 中有一个完成虚拟地址到物理地址转换的小型设备，叫作内存管理单元（Memory Management Unit(MMU）。

在程序执行的时候，指令中的地址都是虚拟地址，虚拟地址会通过 MMU，MMU 会查询页表，计算出对应的 Frame Number，然后偏移量不变，组装成真实地址。然后 MMU 通过地址总线直接去访问内存。所以 MMU 承担了虚拟地址到物理地址的转换以及 CPU 对内存的操作这两件事情。

如下图所示，从结构上 MMU 在 CPU 内部，并且直接和地址总线连接。因此 MMU 承担了 CPU 和内存之间的代理。对操作系统而言，MMU 是一类设备，有多种型号，就好比显卡有很多型号一样。操作系统需要理解这些型号，会使用 MMU。

TLB 和 MMU 的性能问题

上面的过程，会产生一个问题：指令的执行速度非常快，而 MMU 还需要从内存中查询页表。最快的内存查询页需要从 CPU 的缓存中读取，假设缓存有 95% 的命中率，比如读取到 L2 缓存，那么每次操作也需要几个 CPU 周期。你可以回顾一下 CPU 的指令周期，如下图所示，有 fetch/decode/execute 和 store。

在 fetch、execute 和 store 这 3 个环节中都有可能发生内存操作，因此内存操作最好能在非常短的时间内完成，尤其是 Page Number 到 Frame Number 的映射，我们希望尽快可以完成，最好不到 0.2 个 CPU 周期，这样就不会因为地址换算而增加指令的 CPU 周期。

因此，在 MMU 中往往还有一个微型的设备，叫作转置检测缓冲区（Translation Lookaside Buffer，TLB）。

缓存的设计，通常是一张表，所以 TLB 也称作快表。TLB 中最主要的信息就是 Page Number到 Frame Number 的映射关系。

Page Number	Frame Number

如上表所示，最简单的表达就是一个二维表格，每一行是一个 Page Number 和一个 Frame Number。我们把这样的每一行称为一个缓存行（Cache Line），或者缓存条目（Entry）。

TLB 的作用就是根据输入的 Page Number，找到 Frame Number。TLB 是硬件实现的，因此速度很快。因为用户的局部程序，往往会反复利用相同的内存地址。比如说 for 循环会反复利用循环变量，因此哪怕是只有几十个缓存行的 TLB，也会有非常高的命中率。而且现在的多核 CPU，会为每个核心提供单独的 TLB。这样，相当于减少了 TLB 的冲突。比如酷睿 i7 CPU 当中，每个核心都有自己的 TLB，而且 TLB 还进行了类似 CPU 缓存的分级策略。在 i7 CPU 中，L1 级 TLB 一共 64 个，L2 级 TLB 一共 1024 个。通过这样的设计，绝大多数的页表查询就可以用 TLB 实现了。

TLB Miss 问题

如果 Page Number 在 TLB 总没有找到，我们称为TLB 失效（Miss）。这种情况，分成两种。

一种是软失效（Soft Miss），这种情况 Frame 还在内存中，只不过 TLB 缓存中没有。那么这个时候需要刷新 TLB 缓存。如果 TLB 缓存已经满了，就需要选择一个已经存在的缓存条目进行覆盖。具体选择哪个条目进行覆盖，我们称为缓存置换（缓存不够用了，需要置换）。缓存置换时，通常希望高频使用的数据保留，低频使用的数据被替换。比如常用的 LRU（Least Recently Used）算法就是基于这种考虑，每次置换最早使用的条目。

另一种情况是硬失效（Hard Miss)，这种情况下对应的 Frame 没有在内存中，需要从磁盘加载。这种情况非常麻烦，首先操作系统要触发一个缺页中断（原有需要读取内存的线程被休眠），然后中断响应程序开始从磁盘读取对应的 Frame 到内存中，读取完成后，再次触发中断通知更新 TLB，并且唤醒被休眠的线程去排队。注意，线程不可能从休眠态不排队就进入执行态，因此 Hard Miss 是相对耗时的。

无论是软失效、还是硬失效，都会带来性能损失，这是我们不希望看到的。因此缓存的设计，就非常重要了。

TLB 缓存的设计

每个缓存行可以看作一个映射，TLB 的缓存行将 Page Number 映射到 Frame Number，通常我们设计这种基于缓存行（Cache Line）的缓存有 3 种映射方案：

• 全相联映射（Fully Associative Mapping）
• 直接映射（Direct Mapping）
• n 路组相联映射（n-way Set-Associative Mapping）

所谓相联（Associative），讲的是缓存条目和缓存数据之间的映射范围。如果是全相联，那么一个数据，可能在任何条目。如果是组相联（Set-Associative），意味对于一个数据，只能在一部分缓存条目中出现（比如前 4 个条目）。

方案一：全相联映射（Fully Associative Mapping）

如果 TLB 用全相联映射实现，那么一个 Frame，可能在任何缓存行中。虽然名词有点复杂，但是通常新人设计缓存时，会本能地想到全相联。因为在给定的空间下，最容易想到的就是把缓存数据都放进一个数组里。

对于 TLB 而言，如果是全相联映射，给定一个具体的 Page Number，想要查找 Frame，需要遍历整个缓存。当然作为硬件实现的缓存，如果缓存条目少的情况下，可以并行查找所有行。这种行为在软件设计中是不存在的，软件设计通常需要循环遍历才能查找行，但是利用硬件电路可以实现这种并行查找到过程。可是如果条目过多，比如几百个上千个，硬件查询速度也会下降。所以，全相联映射，有着明显性能上的缺陷。我们不考虑采用。

方案二：直接映射（Direct Mapping）

对于水平更高一些的同学，马上会想到直接映射。直接映射类似一种哈希函数的形式，给定一个内存地址，可以通过类似于哈希函数计算的形式，去计算它在哪一个缓存条目。假设我们有 64 个条目，那么可以考虑这个计算方法：缓存行号 = Page Number % 64。

当然在这个方法中，假如实际的虚拟地址空间大小是 1G，页面大小是 4K，那么一共有 1G/4K = 262144 个页，平均每 262144/64 = 4096 个页共享一个条目。这样的共享行为是很正常的，本身缓存大小就不可能太大，之前我们讲过，性能越高的存储离 CPU 越近，成本越高，空间越小。

上面的设计解决了全相联映射的性能缺陷，那么缓存命中率如何呢？

一种最简单的思考就是能不能基于直接映射实现 LRU 缓存。仔细思考，其实是不可能实现的。因为当我们想要置换缓存的时候（新条目进来，需要寻找一个旧条目出去），会发现每次都只有唯一的选择，因为对于一个确定的虚拟地址，它所在的条目也是确定的。这导致直接映射不支持各种缓存置换算法，因此 TLB Miss 肯定会更高。

综上，我们既要解决直接映射的缓存命中率问题，又希望解决全相联映射的性能问题。而核心就是需要能够实现类似 LRU 的算法，让高频使用的缓存留下来——最基本的要求，就是一个被缓存的值，必须可以存在于多个位置——于是人们就发明了 n 路组相联映射。

方案三：n 路组相联映射（n-way Set-Associative Mapping）

组相联映射有点像哈希表的开放寻址法，但是又有些差异。组相联映射允许一个虚拟页号（Page Number）映射到固定数量的 n 个位置。举个例子，比如现在有 64 个条目，要查找地址 100 的位置，可以先用一个固定的方法计算，比如 100%64 = 36。这样计算出应该去条目 36 获取 Frame 数据。但是取出条目 36 看到条目 36 的 Page Number 不是 100，这个时候就顺延一个位置，去查找 37,38,39……如果是 4 路组相联，那么就只看 36,37,38,39，如果是8 路组相联，就只看 36-43 位置。

这样的方式，一个 Page Number 可以在 n 个位置出现，这样就解决了 LRU 算法的问题。每次新地址需要置换进来的时候，可以从 n 个位置中选择更新时间最早的条目置换出去。至于具体 n 设置为多少，需要实战的检验。而且缓存是一个模糊、基于概率的方案，本身对 n 的要求不是很大。比如：i7 CPU 的 L1 TLB 采用 4-way 64 条目的设计；L2 TLB 采用 8-way 1024 条目的设计。Intel 选择了这样的设计，背后有大量的数据支撑。这也是缓存设计的一个要点，在做缓存设计的时候，你一定要收集数据实际验证。

以上，我们解决了 TLB 的基本设计问题，最后选择采用 n 路组相联映射。 然后还遗留了一个问题，如果一个应用（进程）对内存的需求比较大，比如 1G，而默认分页 4K 比较小。 这种情况下会有 262144 个页。考虑到 1024 个条目的 TLB，那么 262144/1024 = 256，如果 256 个地址复用 1 个缓存，很容易冲突。这个问题如何解决呢？

大内存分页

解决上面的遗留问题，可以考虑采用大内存分页（Large Page 或 Huge Page）。 这里我们先复习一下上一讲学习的多级页表。 多层页面就是进程内部维护一张页表，比如说 4M 一个页表（一级），然后每个一级页表关联 1024 个二级页表。 这样会给 MMU 带来一定的负担，因为 MMU 需要先检查一级页表，再检查二级页表。 但是 MMU 仍然可以利用 TLB 进行加速。因为 TLB 是缓存，所有根据值查找结果的逻辑，都可以用 TLB。

但是这没有解决我们提出的页表太多的问题，最终这种多级页表的设计还是需要查询大小为 4K 的页（这里请你思考上面的例子，如果是 1G 空间有 262144 个页）。如果我们操作系统能够提供大小为 4M 的页，那么是不是就减少了 1024 倍的页数呢？ ——这样就大大提高了 TLB 的查询性能。

因此 Linux 内核 2.6 版之后就开始提供大内存分页（HugeTable），默认是不开启的。如果你有应用需要使用大内存分页，可以考虑用下面的语句开启它：

sudo sysctl -w vm.nr_hugepages=2048

sysctl其实就是修改一下配置项，上面我们允许应用使用最多 2048 个大内存页。上面语句执行后，你可以按照下方截图的方式去查看自己大内存页表使用的情况。

从上图中你可以看到我总共有 2048 个大内存页，每个大小是 2048KB。具体这个大小是不可以调整的，这个和机器用的 MMU 相关。

打开大内存分页后如果有应用需要使用，就会去申请大内存分页。比如 Java 应用可以用-XX:+UseLargePages开启使用大内存分页。 下图是我通过一个 Java 程序加上 UseLargePages 参数的结果。

注意：我的 Java 应用使用的分页数 = Total-Free+Rsvd = 2048-2032+180 = 196。Total 就是总共的分页数，Free 代表空闲的（包含 Rsvd，Reserved 预留的）。因此是上面的计算关系。

总结

那么通过这节课的学习，你现在可以尝试来回答本节关联的面试题目：什么情况下使用大内存分页？

【解析】 通常应用对内存需求较大时，可以考虑开启大内存分页。比如一个搜索引擎，需要大量在内存中的索引。有时候应用对内存的需求是隐性的。比如有的机器用来抗高并发访问，虽然平时对内存使用不高，但是当高并发到来时，应用对内存的需求自然就上去了。虽然每个并发请求需要的内存都不大， 但是总量上去了，需求总量也会随之提高高。这种情况下，你也可以考虑开启大内存分页。

思考题

最后我再给你出一道需要查资料的思考题：Java 和 Go 默认需不需要开启大内存分页？

26 | 缓存置换算法： LRU 用什么数据结构实现更合理？

这一讲给你带来的面试题目是：LRU 用什么数据结构实现更合理？

LRU（最近最少使用），是一种缓存置换算法。缓存是用来存储常用的数据，加速常用数据访问的数据结构。有软件实现，比如数据库的缓存；也有硬件实现，比如我们上一讲学的 TLB。缓存设计中有一个重要的环节：当缓存满了，新的缓存条目要写入时，哪个旧条目被置换出去呢？

这就需要用到缓存置换算法（Cache Replacement Algorithm）。缓存置换应用场景非常广，比如发生缺页中断后，操作系统需要将磁盘的页导入内存，那么已经在内存中的页就需要置换出去。CDN 服务器为了提高访问速度，需要决定哪些 Web 资源在内存中，哪些在磁盘上。CPU 缓存每次写入一个条目，也就相当于一个旧的条目被覆盖。数据库要决定哪些数据在内存中，应用开发要决定哪些数据在 Redis 中，而空间是有限的，这些都关联着缓存的置换。

今天我们就以 LRU 用什么数据结构实现更合理，这道缓存设计题目为引，为你讲解缓存设计中（包括置换算法在内）的一些通用的思考方法。

理想状态

设计缓存置换算法的期望是：每次将未来使用频率最低的数据置换出去。假设只要我们知道未来的所有指令，就可以计算出哪些内存地址在未来使用频率高，哪些内存地址在未来使用频率低。这样，我们总是可以开发出理论上最高效的缓存置换算法。

再复习下缓存的基本概念，在缓存中找到数据叫作一次命中（Hit），没有找到叫作穿透（Miss）。假设穿透的概率为 M，缓存的访问时间（通常叫作延迟）是 L，穿透的代价（访问到原始数据，比如 Redis 穿透，访问到 DB）也就是穿透后获取数据的平均时间是 T，那么 M*T+L 可以看作是接近缓存的平均响应时间。L 通常是不变的，这个和我们使用了什么缓存相关。这样，如果我们知道未来访问数据的顺序，就可以把 M 降到最低，让缓存平均响应时间降到最低。

当然这只是美好的愿望，在实际工作中我们还不可能预知未来。

随机/FIFO/FILO

接下来我要和你讨论的 3 种策略，是对理想状态的一种悲观表达，或者说不好的设计。

比如说随机置换，一个新条目被写入，随机置换出去一个旧条目。这种设计，具有非常朴素的公平，但是性能会很差（穿透概率高），因为可能置换出去未来非常需要的数据。

再比如先进先出（First In First Out）。设计得不好的电商首页，每次把离现在时间最久的产品下线，让新产品有机会展示，而忽略销量、热度、好评等因素。这也是一种朴素的公平，但是和我们设计缓存算法的初衷——预估未来使用频率更高的数据保留在缓存中，相去甚远。所以，FIFO 的结构也是一种悲观的设计。

FIFO 的结构使用一个链表就能实现，如下图所示：

为了方便你理解本讲后面的内容，我在这里先做一个知识铺垫供你参考。上图中，新元素从链表头部插入，旧元素从链表尾部离开。 这样就构成了一个队列（Queue），队列是一个经典的 FIFO 模型。

还有一种策略是先进后出（First In Last Out）。但是这种策略和 FIFO、随机一样，没有太强的实际意义。因为先进来的元素、后进来的元素，还是随机的某个元素，和我们期望的未来使用频率，没有任何本质联系。

同样 FILO 的策略也可以用一个链表实现，如下图所示：

新元素从链表头部插入链表，旧元素从链表头部离开链表，就构成了一个栈（Stack），栈是一种天然的 FILO 数据结构。这里仅供参考了，我们暂时还不会用到这个方法。

当然我们不可能知道未来，但是可以考虑基于历史推测未来。经过前面的一番分析，接下来我们开始讨论一些更有价值的置换策略。

最近未使用（NRU）

一种非常简单、有效的缓存实现就是优先把最近没有使用的数据置换出去（Not Recently Used)。从概率上说，最近没有使用的数据，未来使用的概率会比最近经常使用的数据低。缓存设计本身也是基于概率的，一种方案有没有价值必须经过实践验证——在内存缺页中断后，如果采用 NRU 置换页面，可以提高后续使用内存的命中率，这是实践得到的结论。

而且 NRU 实现起来比较简单，下图是我们在“24 讲”中提到的页表条目设计。

在页表中有一个访问位，代表页表有被读取过。还有一个脏位，代表页表被写入过。无论是读还是写，我们都可以认为是访问过。 为了提升效率，一旦页表被使用，可以用硬件将读位置 1，然后再设置一个定时器，比如 100ms 后，再将读位清 0。当有内存写入时，就将写位置 1。过一段时间将有内存写入的页回写到磁盘时，再将写位清 0。这样读写位在读写后都会置为 1，过段时间，也都会回到 0。

上面这种方式，就构成了一个最基本的 NRU 算法。每次置换的时候，操作系统尽量选择读、写位都是 0 的页面。而一个页面如果在内存中停留太久，没有新的读写，读写位会回到 0，就可能会被置换。

这里多说一句，NRU 本身还可以和其他方法结合起来工作，比如我们可以利用读、写位的设计去改进 FIFO 算法。

每次 FIFO 从队列尾部找到一个条目要置换出去的时候，就检查一下这个条目的读位。如果读位是 0，就删除这个条目。如果读位中有 1，就把这个条目从队列尾部移动到队列的头部，并且把读位清 0，相当于多给这个条目一次机会，因此也被称为第二次机会算法。多给一次机会，就相当于发生访问的页面更容易存活。而且，这样的算法利用天然的数据结构优势（队列），保证了 NRU 的同时，节省了去扫描整个缓存寻找读写位是 0 的条目的时间。

第二次机会算法还有一个更巧妙的实现，就是利用循环链表。这个实现可以帮助我们节省元素从链表尾部移动到头部的开销。

如上图所示，我们可以将从尾部移动条目到头部的这个操作简化为头指针指向下一个节点。每次移动链表尾部元素到头部，只需要操作头指针指向下一个元素即可。这个方法非常巧妙，而且容易实现，你可以尝试在自己系统的缓存设计中尝试使用它。

以上，是我们学习的第一个比较有价值的缓存置换算法。基本可用，能够提高命中率。缺点是只考虑了最近用没用过的情况，没有充分考虑综合的访问情况。优点是简单有效，性能好。缺点是考虑不周，对缓存的命中率提升有限。但是因为简单，容易实现，NRU 还是成了一个被广泛使用的算法。

最近使用最少（LRU）

一种比 NRU 考虑更周密，实现成本更高的算法是最近最少使用（Least Recently Used， LRU）算法，它会置换最久没有使用的数据。和 NRU 相比，LRU 会考虑一个时间范围内的数据，对数据的参考范围更大。LRU 认为，最近一段时间最少使用到的数据应该被淘汰，把空间让给最近频繁使用的数据。这样的设计，即便数据都被使用过，还是会根据使用频次多少进行淘汰。比如：CPU 缓存利用 LUR 算法将空间留给频繁使用的内存数据，淘汰使用频率较低的内存数据。

常见实现方案

LRU 的一种常见实现是链表，如下图所示：

用双向链表维护缓存条目。如果链表中某个缓存条目被使用到，那么就将这个条目重新移动到表头。如果要置换缓存条目出去，就直接从双线链表尾部删除一个条目。

通常 LRU 缓存还要提供查询能力，这里我们可以考虑用类似 Java 中 LinkedHashMap 的数据结构，同时具备双向链表和根据 Key 查找值的能力。

以上是常见的实现方案，但是这种方案在缓存访问量非常大的情况下，需要同时维护一个链表和一个哈希表，因此开销较高。

举一个高性能场景的例子，比如页面置换算法。 如果你需要维护一个很大的链表来存储所有页，然后经常要删除大量的页面（置换缓存），并把大量的页面移动到链表头部。这对于页面置换这种高性能场景来说，是不可以接受的。

另外一个需要 LRU 高性能的场景是 CPU 的缓存，CPU 的多路组相联设计，比如 8-way 设计，需要在 8 个地址中快速找到最久未使用的数据，不可能再去内存中建立一个链表来实现。

正因为有这么多困难，才需要不断地优化迭代，让缓存设计成为一门艺术。接下来我选取了内存置换算法中数学模拟 LRU 的算法，分享给你。

如何描述最近使用次数？

设计 LRU 缓存第一个困难是描述最近使用次数。 因为“最近”是一个模糊概念，没有具体指出是多长时间？按照 CPU 周期计算还是按照时间计算？还是用其他模糊的概念替代？

比如说页面置换算法。在实际的设计中，可以考虑把页表的读位利用起来。做一个定时器，每隔一定的 ms 数，就把读位累加到一个计数器中。相当于在每个页表条目上再增加一个累计值。

例如：现在某个页表条目的累计值是 0， 接下来在多次计数中看到的读位是：1,0,0,1,1，那么累计值就会变成 3。这代表在某段时间内（5 个计数器 Tick 中）有 3 次访问操作。

通过这种方法，就解决了描述使用次数的问题。如果单纯基于使用次数最少判断置换，我们称为最少使用（Least Frequently Used,，LFU）算法。LFU 的劣势在于它不会忘记数据，累计值不会减少。比如如果有内存数据过去常常被用到，但是现在已经有很长一段时间没有被用到了，在这种情况下它并不会置换出去。那么我们该如何描述“最近”呢？

有一个很不错的策略就是利用一个叫作“老化”（Aging）的算法。比起传统的累加计数的方式，Aging 算法的累加不太一样。

比如用 8 位来描述累计数（A），那么每次当读位的值（R）到来的时候，我们都考虑将 A 的值右移，然后将 R 放到 A 的最高位。

例如 A 目前的值是00000000，在接下来的 5 个 Tick 中 R 来临的序列是11100，那么 A 的值变更顺序为：

1. 10000000
2. 11000000
3. 11100000
4. 01110000
5. 00111000

你可以看到随着 Aging 算法的执行，有访问操作的时候 A 的值上升，没有访问操作的时候，A的值逐渐减少。如果一直没有访问操作，A 的值会回到 0。

这样的方式就巧妙地用数学描述了“最近”。然后操作系统每次页面置换的时候，都从 A 值最小的集合中取出一个页面放入磁盘。这个算法是对 LRU 的一种模拟，也被称作 LFUDA（动态老化最少使用，其中 D 是 Dynamic,，A 是 Aging）。

而计算 Aging（累计值）的过程，可以由硬件实现，这样就最大程度提升了性能。

相比写入操作，查询是耗时相对较少的。这是因为有 CPU 缓存的存在，我们通常不用直接去内存中查找数据，而是在缓存中进行。对于发生缺页中断的情况，并不需要追求绝对的精确，可以在部分页中找到一个相对累计值较小的页面进行置换。不过即便是模拟的 LRU 算法，也不是硬件直接支持的，总有一部分需要软件实现，因此还是有较多的时间开销。

是否采用 LRU，一方面要看你所在场景的性能要求，有没有足够的优化措施（比如硬件提速）；另一方面，就要看最终的结果是否能够达到期望的命中率和期望的使用延迟了。

总结

本讲我们讨论的频次较高、频次较低，是基于历史的。 历史在未来并不一定重演。比如读取一个大型文件，无论如何操作都很难建立一个有效的缓存。甚至有的时候，最近使用频次最低的数据被缓存，使用频次最高的数据被置换，效率会更高。比如说有的数据库设计同时支持 LRU 缓存和 MRU（ Most Recently Used）缓存。MRU 是 LRU 的对立面，这看似茅盾，但其实是为了解决不同情况下的需求。

这并不是说缓存设计无迹可寻，而是经过思考和预判，还得以事实的命中率去衡量缓存置换算法是否合理。

那么通过这节课的学习，你现在可以尝试来回答本节关联的面试题目：LRU 用什么数据结构实现更合理？

【解析】 最原始的方式是用数组，数组的每一项中有数据最近的使用频次。数据的使用频次可以用计时器计算。每次置换的时候查询整个数组实现。

另一种更好的做法是利用双向链表实现。将使用到的数据移动到链表头部，每次置换时从链表尾部拿走数据。链表头部是最近使用的，链表尾部是最近没有被使用到的数据。

但是在应对实际的场景的时候，有时候不允许我们建立专门用于维护缓存的数据结构（内存大小限制、CPU 使用限制等），往往需要模拟 LRU。比如在内存置换场景有用“老化”技术模拟 LRU 计算的方式。

思考题

最后我再给你出一道需要查资料的思考题：在 TLB 多路组相联缓存设计中（比如 8-way），如何实现 LRU 缓存？

27 | 内存回收上篇：如何解决内存的循环引用问题？

内存泄漏一直是很多大型系统故障的根源，也是一个面试热点。那么在编程语言层面已经提供了内存回收机制，为什么还会产生内存泄漏呢？

这是因为应用的内存管理一直处于一个和应用程序执行并发的状态，如果应用程序申请内存的速度，超过内存回收的速度，内存就会被用满。当内存用满，操作系统就开始需要频繁地切换页面，进行频繁地磁盘读写。所以我们观察到的系统性能下降，往往是一种突然的崩溃，因为一旦内存被占满，系统性能就开始雪崩式下降。

特别是有时候程序员不懂内存回收的原理，错误地使用内存回收器，导致部分对象没有被回收。而在高并发场景下，每次并发都产生一点不能回收的内存，不用太长时间内存就满了，这就是泄漏通常的成因。

这一块知识点关联着很多常见的面试题，比如。

• 这一讲关联的题目：如何解决循环引用问题？
• 下节课关联的题目：三色标记-清除算法的工作原理？生代算法等。
• 还有一些题目会考察你对内存回收器整体的理解，比如如何在吞吐量、足迹和暂停时间之间选择？

接下来，我会用 27 和 28 两讲和你探讨内存回收技术，把这些问题一网打尽。

什么是 GC

通常意义上我们说的垃圾回收器（Garbage Collector，GC），和多数同学的理解会有出入。你可能认为 GC 是做内存回收用的模块，而事实上程序语言提供的 GC 往往是应用的实际内存管理者。刚刚入门咱们就遇到了一个容易出现理解偏差的问题，所以 GC 是值得花时间细学的。

如上图所示，一方面 GC 要承接操作系统虚拟内存的架构，另一方面 GC 还要为应用提供内存管理。GC 有一个含义，就是 Garbage Collection 内存回收的具体动作。无论是名词的回收器，还是动词的回收行为，在下文中我都称作 GC。

下面我们具体来看一下 GC 都需要承担哪些“工作”，这里我总结为以下 4 种。

1. GC 要和操作系统进行交互，负责申请内存，并把不用的内存还给操作系统（释放内存）。
2. 应用会向 GC 申请内存。
3. GC 要承担我们通常意义上说的垃圾回收能力，标记不用的对象，并回收他们。
4. GC 还需要针对应用特性进行动态的优化。

所以现在程序语言实现的 GC 模块通常是实际负责应用内存管理的模块。在程序语言实现 GC 的时候，会关注下面这几个指标。

• 吞吐量（Throughput）：执行程序（不包括 GC 执行的时间）和总是间的占比。注意这个吞吐量和通常意义上应用去处理作业的吞吐量是不一样的，这是从 GC 的角度去看应用。只要不在 GC，就认为是吞吐量的一部分。
• 足迹（FootPrint）： 一个程序使用了多少硬件的资源，也称作程序在硬件上的足迹。GC 里面说的足迹，通常就是应用对内存的占用情况。比如说应用运行需要 2G 内存，但是好的 GC 算法能够帮助我们减少 500MB 的内存使用，满足足迹这个指标。
• 暂停时间（Pause Time）： GC 执行的时候，通常需要停下应用（避免同步问题），这称为 Stop The World，或者暂停。不同应用对某次内存回收可以暂停的时间需求是不同的，比如说一个游戏应用，暂停了几毫秒用户都可能有很大意见；而看网页的用户，稍微慢了几毫秒是没有感觉的。

GC 目标的思考

如果单纯从让 GC 尽快把工作做完的角度来讲，其实是提升吞吐量。比如利用好多核优势就是一种最直观的方法。

因为涉及并行计算，我这里给你讲讲并行计算领域非常重要的阿姆达定律，这个定律用来衡量并行计算对原有算法的改进，公式如下：

S = 1 / (1- P)

你现在看到的是一个简化版的阿姆达定律，P 是任务中可以并发执行部分的占比，S 是并行带来的理论提速倍数的极限。比如说 P 是 0.9，代入公式可得：

S = 1 / （1 - 0.9） = 10

上面表达式代表着有 90% 的任务可以并行，只有 10% 的任务不能够并行。假设我们拥有无限多的 CPU 去分担 90% 可以并行的任务，其实就相当于并行的任务可以在非常短的时间内完成。但是还有 10% 的任务不能并行，因此理论极限是 1/0.1=10 倍。

通常我们设计 GC，都希望它能够支持并行处理任务。因为 GC 本身也有着繁重的工作量，需要扫描所有的对象，对内存进行标记清除和整理等。

经过上述分析，那么我们在设计算法的时候是不是应该尽量做到高并发呢？

很可惜并不是这样。如果算法支持的并发度非常高，那么和单线程算法相比，它也会带来更多的其他开销。比如任务拆分的开销、解决同步问题的开销，还有就是空间开销，GC 领域空间开销通常称为 FootPrint。理想情况下当然是核越多越好，但是如果考虑计算本身的成本，就需要找到折中的方案。

还有一个问题是，GC 往往不能拥有太长的暂停时间（Pause Time），因为 GC 和应用是并发的执行。如果 GC 导致应用暂停（Stop The World，STL）太久，那么对有的应用来说是灾难性的。 比如说你用鼠标的时候，如果突然卡了你会很抓狂。如果一个应用提供给百万级的用户用，假设这个应用帮每个用户每天节省了 1s 的等待时间，那么按照乔布斯的说法每天就为用户节省了 11 天的时间，每年是 11 年——5 年就相当于拯救了一条生命。

如果暂停时间只允许很短，那么 GC 和应用的交替就需要非常频繁。这对 GC 算法要求就会上升，因为每次用户程序执行后，会产生新的变化，甚至会对已有的 GC 结果产生影响。后面我们在讨论标记-清除算法的时候，你会感受到这种情况。

所以说，吞吐量高，不代表暂停时间少，也不代表空间使用（FootPrint）小。 同样的，使用空间小的 GC 算法，吞吐量反而也会下降。正因为三者之间存在类似相同成本代价下不可兼得的关系，往往编程语言会提供参数让你选择根据自己的应用特性决定 GC 行为。

引用计数算法（Reference Counter）

接下来我们说说，具体怎么去实现 GC。实现 GC 最简单的方案叫作引用计数，下图中节点的引用计数是 2，代表有两个节点都引用了它。

如果一个节点的引用计数是 0，就意味着没有任何一个节点引用它——此时，理论上这个节点应该被回收。GC 不断扫描引用计数为 0 的节点进行回收，就构成了最简单的一个内存回收算法。

但是，这个算法可能会出现下图中循环引用的问题（我们写程序的过程中经常会遇到这样的引用关系）。下图中三个节点，因为循环引用，引用计数都是 1。

引用计数是 1，因此就算这 3 个对象不会再使用了，GC 不会回收它们。

另一个考虑是在多线程环境下引用计数的算法一旦算错 1 次（比如因为没有处理好竞争条件），那么就无法再纠正了。而且处理竞争条件本身也比较耗费性能。

还有就是引用计数法回收内存会产生碎片，当然碎片不是只有引用计数法才有的问题，所有的 GC 都需要面对碎片。下图中内存回收的碎片可以通过整理的方式，清理出更多空间出来。关于内存空间的碎片，下一讲会有专门的一个小节讨论。

综上，引用计数法出错概率大，比如我们编程时会有对象的循环引用；另一方面，引用计数法容错能力差，一旦计算错了，就会导致内存永久无法被回收，因此我们需要更好的方式。

Root Tracing 算法

下面我再给你介绍一种更好的方式—— Root Tracing 算法。这是一类算法，后面我们会讲解的标记-清除算法和 3 色标记-清除算法都属于这一类。

Root Tracing 的原理是：从引用路径上，如果一个对象的引用链中包括一个根对象（Root Object），那么这个对象就是活动的。根对象是所有引用关系的源头。比如用户在栈中创建的对象指针；程序启动之初导入数据区的全局对象等。在 Java 中根对象就包括在栈上创建指向堆的对象；JVM 的一些元数据，包括 Method Area 中的对象等。

在 Root Tracing 工作过程中，如果一个对象和根对象间有连通路径，也就是从根节点开始遍历可以找到这个对象，代表有对象可以引用到这个对象，那么这个节点就不需要被回收。所以算法的本质还是引用，只不过判断条件从引用计数变成了有根对象的引用链。

如果一个对象从根对象不可达，那么这个对象就应该被回收，即便这个对象存在循环引用。可以看到，上图中红色的 3 个对象循环引用，并且到根集合没有引用链，因此需要被回收。这样就解决了循环引用的问题。

Root Tracing 的容错性很好，GC 通过不断地执行 Root Tracing 算法找到需要回收的元素。如果在这个过程中，有一些本来应该回收的元素没有被计算出（比如并发原因），也不会导致这些对象永久无法回收。因为在下次执行 Root Tracing 的时候，GC 就会通过执行 Root Tracing 算法找到这些元素。不像引用计数法，一旦算错就很难恢复。

标记-清除（Mark Sweep）算法

下面我为你具体介绍一种 Root Tracing 的算法， 就是标记清除-算法。标记-清除算法中，用白色代表一种不确定的状态：可能被回收。 黑色代表一种确定的状态：不会被回收。算法的实现，就是为所有的对象染色。算法执行结束后，所有是白色的对象就需要被回收。

算法实现过程中，假设有两个全局变量是已知的：

• heapSet 中拥有所有对象
• rootSet 中拥有所有 Root Object

算法执行的第一步，就是将所有的对象染成白色，代码如下：

for obj in heapSet {
    obj.color = white
}

接下来我们定义一个标记函数，它会递归地将一个对象的所有子对象染成黑色，代码如下：

func mark(obj) {
  if obj.color == white {
    obj.color = black
    for v in references(obj) {
      mark(v)
    }
  }
}

补充知识

上面的 mark 函数对 obj 进行了深度优先搜索。深度优先搜索，就是自然的递归序。随着递归函数执行，遇到子元素就遍历子元素，就构成了天然的深度优先搜索。还有一个相对的概念是广度优先搜索（Breadth First Serach），如果你不知道深度优先搜索和广度优先搜索，可以看下我下面的图例。

上图中，深度优先搜索优先遍历完整的子树（递归），广度优先搜索优先遍历所有的子节点（逐层）。

然后我们从所有的 Root Object 开始执行 mark 函数：

for root in rootSet {
  mark(root)
}

以上程序执行结束后，所有和 Root Object 连通的对象都已经被染成了黑色。然后我们遍历整个 heapSet 找到白色的对象进行回收，这一步开始是清除（Sweep）阶段，以上是标记（Mark）阶段。

for obj in heapSet {
  if obj.color == white {
    free(obj)
  }
}

以上算法就是一个简单的标记-清除算法。相比引用计数，这个算法不需要维护状态。算法执行开始所有节点都被标记了一遍。结束的时候，算法找到的垃圾就被清除了。 算法有两个阶段，标记阶段（Mark），还有清除阶段（Sweep），因此被称为标记-清除算法。

这里请你思考：如果上面的 GC 程序在某个时刻暂停了下来，然后开始执行用户程序。如果用户程序删除了对某个已经标记为黑色对象的所有引用，用户程序没办法通知 GC 程序。这个节点就会变成浮动垃圾（Floating Garbage），需要等待下一个 GC 程序执行。

假设用户程序和 GC 交替执行，用户程序不断进行修改（Mutation），而 GC 不断执行标记-清除算法。那么这中间会产生大量浮动垃圾影响 GC 的效果。

另一方面，考虑到 GC 是一个非常消耗性能程序，在某些情况下，我们希望 GC 能够增量回收。 比如说，用户仅仅是高频删除了一部分对象，那么是否可以考虑设计不需要从整个 Root 集合进行遍历，而是增量的只处理最近这一批变更的算法呢？答案是可以的，我们平时可以多执行增量 GC，偶尔执行一次全量 GC。具体增量的方式会在下一讲为你讲解。

总结

讨论到这里，相信你已经对 GC 有了一个大致的认识，但是具体到不同的场景如何设计 GC 算法，比如上面提到的标记-清除算法的缺陷，该如何去弥补呢？ 还有在高并发场景应该如何选择 GC 算法呢？当你拿到一个 GC 工具，又应该如何去设置参数，调整计算资源和存储资源比例呢？这些问题， 你可以先在自己脑海中思考，然后我会在下一讲为你讲解更好的方案。

另外，本讲关联的面试题：如何解决内存的循环引用问题？也请你先进行一定的思考，再来“28 讲”查看详细的分析过程。

28 | 内存回收下篇：三色标记-清除算法是怎么回事？

今天我们继续讨论内存回收问题。在上一讲，我们发现双色标记-清除算法有一个明显的问题，如下图所示：

你可以把 GC 的过程看作标记、清除及程序不断对内存进行修改的过程，分成 3 种任务：

1. 标记程序（Mark）
2. 清除程序（Sweep）
3. 变更程序（Mutation）

标记（Mark）就是找到不用的内存，清除（Sweep）就是回收不用的资源，而修改（Muation）则是指用户程序对内存进行了修改。通常情况下，在 GC 的设计中，上述 3 种程序不允许并行执行（Simultaneously）。对于 Mark、Sweep、Mutation 来说内存是共享的。如果并行执行相当于需要同时处理大量竞争条件的手段，这会增加非常多的开销。当然你可以开多个线程去 Mark、Mutation 或者 Sweep，但前提是每个过程都是独立的。

因为 Mark 和 Sweep 的过程都是 GC 管理，而 Mutation 是在执行应用程序，在实时性要求高的情况下可以允许一边 Mark，一边 Sweep 的情况； 优秀的算法设计也可能会支持一边 Mark、一边 Mutation 的情况。这种算法通常使用了 Read On Write 技术，本质就是先把内存拷贝一份去 Mark/Sweep，让 Mutation 完全和 Mark 隔离。

上图中 GC 开始后，拷贝了一份内存的原本，进行 Mark 和 Sweep，整理好内存之后，再将原本中所有的 Mutation 合并进新的内存。 这种算法设计起来会非常复杂，但是可以保证实时性 GC。

上图的这种 GC 设计比较少见，通常 GC 都会发生 STL（Stop The World）问题，Mark/Sweep/Mutation 只能够交替执行。也就是说， 一种程序执行的时候，另一种程序必须停止。

对于双色标记-清除算法，如果 Mark 和 Sweep 之间存在 Mutation，那么 Mutation 的伤害是比较大的。比如 Mutation 新增了一个白色的对象，这个白色的对象就可能会在 Sweep 启动后被清除。当然也可以考虑新增黑色的对象，这样对象就不会在 Sweep 启动时被回收。但是会发生下面这个问题，如下图所示：

如果一个新对象指向了一个已经删除的对象，一个新的黑色对象指向了一个白色对象，这个时候 GC 不会再遍历黑色对象，也就是白色的对象还是会被清除。因此，我们希望创建一个在并发环境更加稳定的程序，让 Mark/Mutation/Sweep 可以交替执行，不用特别在意它们之间的关联。

有一个非常优雅地实现就是再增加一种中间的灰色，把灰色看作可以增量处理的工作，来重新定义白色的含义。

三色标记-清除算法（Tri-Color Mark Sweep）

接下来，我会和你讨论这种有三个颜色标记的算法，通常称作三色标记-清除算法。首先，我们重新定义黑、白、灰三种颜色的含义：

• 白色代表需要 GC 的对象；
• 黑色代表确定不需要 GC 的对象；
• 灰色代表可能不需要 GC 的对象，但是还未完成标记的任务，也可以认为是增量任务。

在三色标记-清除算法中，一开始所有对象都染成白色。初始化完成后，会启动标记程序。在标记的过程中，是可以暂停标记程序执行 Mutation。

算法需要维护 3 个集合，白色集合、黑色集合、灰色集合。3 个集合是互斥的，对象只能在一个集合中。执行之初，所有对象都放入白色集合，如下图所示：

第一次执行，算法将 Root 集合能直接引用的对象加入灰色集合，如下图所示：

接下来算法会不断从灰色集合中取出元素进行标记，主体标记程序如下：

while greySet.size() > 0 {
  var item = greySet.remove();
  mark(item);
}

标记的过程主要分为 3 个步骤：

1. 如果对象在白色集合中，那么先将对象放入灰色集合；
2. 然后遍历节点的所有的引用对象，并递归所有引用对象；
3. 当一个对象的所有引用对象都在灰色集合中，就把这个节点放入为黑色集合。

伪代码如下：

func mark(obj) {
  if obj in whiteSet {
    greySet.add(obj)
    for v in refs(obj) {
      mark(v)
    }
    greySet.remove(obj)
    blackSet.add(obj)
  }
}

你可以观察下上面的程序，这是一个 DFS 的过程。如果多个线程对不同的 Root Object 并发执行这个算法，我们需要保证 3 个集合都是线程安全的，可以考虑利用 ConcurrentSet（这样性能更好），或者对临界区上锁。并发执行这个算法的时候，如果发现一个灰色节点说明其他线程正在处理这个节点，就忽略这个节点。这样，就解决了标记程序可以并发执行的问题。

当标记算法执行完成的时候，所有不需要 GC 的元素都会涂黑：

标记算法完成后，白色集合内就是需要回收的对象。

以上，是类似双色标记-清除算法的全量 GC 程序，我们从 Root 集合开始遍历，完成了对所有元素的标记（将它们放入对应的集合）。

接下来我们来考虑增加 GC（Incremental GC）的实现。首先对用户的修改进行分类，有这样 3 类修改（Mutation）需要考虑：

1. 创建新对象
2. 删除已有对象
3. 调整已有引用

如果用户程序创建了新对象，可以考虑把新对象直接标记为灰色。虽然，也可以考虑标记为黑色，但是标记为灰色可以让 GC 意识到新增了未完成的任务。比如用户创建了新对象之后，新对象引用了之前删除的对象，就需要重新标记创建的部分。

如果用户删除了已有的对象，通常做法是等待下一次全量 Mark 算法处理。下图中我们删除了 Root Object 到 A 的引用，这个时候如果把 A 标记成白色，那么还需要判断是否还有其他路径引用到 A，而且 B,C 节点的颜色也需要重新计算。关键的问题是，虽然可以实现一个基于 A 的 DFS 去解决这个问题，但实际情况是我们并不着急解决这个问题，因为内存空间往往是有富余的。

在调整已有的引用关系时，三色标记算法的表现明显更好。下图是对象 B 将对 C 的引用改成了对 F 的引用，C,F 被加入灰色集合。接下来 GC 会递归遍历 C,F，最终然后 F,E,G 都会进入灰色集合。

内存回收就好比有人在随手扔垃圾，清洁工需要不停打扫。如果清洁工能够跟上人们扔垃圾的速度，那么就不需要太多的 STL（Stop The World）。如果清洁工跟不上扔垃圾的速度，最终环境就会被全部弄乱，这个时候清洁工就会要求“Stop The World”。三色算法的优势就在于它支持多一些情况的 Mutation，这样能够提高“垃圾”被并发回收的概率。

目前的 GC 主要都是基于三色标记算法。 至于清除算法，有原地回收算法，也有把存活下来的对象（黑色对象）全部拷贝到一个新的区域的算法。

碎片整理和生代技术

三色标记-清除算法，还没有解决内存回收产生碎片的问题。通常，我们会在三色标记-清除算法之上，再构建一个整理内存（Compact）的算法。如下图所示：

Compact 算法将对象重新挤压到一起，让更多空间可以被使用。我们在设计这个算法时，观察到了一个现象：新创建出来的对象，死亡（被回收）概率会更高，而那些已经存在了一段时间的对象，往往更不容易死亡。这有点类似 LRU 缓存，其实是一个概率问题。接下来我们考虑针对这个现象进行优化。

如上图所示，你可以把新创建的对象，都先放到一个统一的区域，在 Java 中称为伊甸园（Eden）。这个区域因为频繁有新对象死亡，因此需要经常 GC。考虑整理使用中的对象成本较高，因此可以考虑将存活下来的对象拷贝到另一个区域，Java 中称为存活区（Survior）。存活区生存下来的对象再进入下一个区域，Java 中称为老生代。

上图展示的三个区域，Eden、Survior 及老生代之间的关系是对象的死亡概率逐级递减，对象的存活周期逐级增加。三个区域都采用三色标记-清除算法。每次 Eden 存活下来的对象拷贝到 Survivor 区域之后，Eden 就可以完整的回收重利用。Eden 可以考虑和 Survivor 用 1:1 的空间，老生代则可以用更大的空间。Eden 中全量 GC 可以频繁执行，也可以增量 GC 混合全量 GC 执行。老生代中的 GC 频率可以更低，偶尔执行一次全量的 GC。

GC 的选择

最后我们来聊聊 GC 的选择。通常选择 GC 会有实时性要求（最大容忍的暂停时间），需要从是否为高并发场景、内存实际需求等维度去思考。在选择 GC 的时候，复杂的算法并不一定更有效。下面是一些简单有效的思考和判断。

1. 如果你的程序内存需求较小，GC 压力小，这个时候每次用双色标记-清除算法，等彻底标记-清除完再执行应用程序，用户也不会感觉到多少延迟。双色标记-清除算法在这种场景可能会更加节省时间，因为程序简单。
2. 对于一些对暂停时间不敏感的应用，比如说数据分析类应用，那么选择一个并发执行的双色标记-清除算法的 GC 引擎，是一个非常不错的选择。因为这种应用 GC 暂停长一点时间都没有关系，关键是要最短时间内把整个 GC 执行完成。
3. 如果内存的需求大，同时对暂停时间也有要求，就需要三色标记清除算法，让部分增量工作可以并发执行。
4. 如果在高并发场景，内存被频繁迭代，这个时候就需要生代算法。将内存划分出不同的空间，用作不同的用途。
5. 如果实时性要求非常高，就需要选择专门针对实时场景的 GC 引擎，比如 Java 的 Z。

当然，并不是所有的语言都提供多款 GC 选择。但是通常每个语言都会提供很多的 GC 参数。这里也有一些最基本的思路，下面我为你介绍一下。

如果内存不够用，有两种解决方案。一种是降低吞吐量——相当于 GC 执行时间上升；另一种是增加暂停时间，暂停时间较长，GC 更容易集中资源回收内存。那么通常语言的 GC 都会提供设置吞吐量和暂停时间的 API。

如果内存够用，有的 GC 引擎甚至会选择当内存达到某个阈值之后，再启动 GC 程序。通常阈值也是可以调整的。因此如果内存够用，就建议让应用使用更多的内存，提升整体的效率。

总结

那么通过这节课的学习，你现在可以尝试来回答本节关联的 2 道面试题目：

• 如何解决内存的循环引用问题？
• 三色标记清除算法的工作原理？

【解析】 解决循环引用的问题可以考虑利用 Root Tracing 类的 GC 算法。从根集合利用 DFS 或者 BFS 遍历所有子节点，最终不能和根集合连通的节点都是需要回收的。

三色标记算法利用三种颜色进行标记。白色代表需要回收的节点；黑色代表不需要回收的节点；灰色代表会被回收，但是没有完成标记的节点。

初始化的时候所有节点都标记为白色，然后利用 DFS 从 Root 集合遍历所有节点。每遍历到一个节点就把这个节点放入灰色集合，如果这个节点所有的子节点都遍历完成，就把这个节点放入黑色的集合。最后白色集合中剩下的就是需要回收的元素。

思考题

最后我再给你出一道需要查资料的思考题：如果内存太大了，无论是标记还是清除速度都很慢，执行一次完整的 GC 速度下降该如何处理？

加餐 | 练习题详解（五）

今天我会带你把《模块五：内存管理》中涉及的课后练习题，逐一讲解，并给出每个课时练习题的解题思路和答案。

练习题详解

24 | 虚拟内存 ：一个程序最多能使用多少内存？

【问题】可不可以利用哈希表直接将页编号映射到 Frame 编号？

【解析】按照普通页表的设计，如果页大小是 4K，1G 空间内存需要 262144 个页表条目，如果每个条目用 4 个字节来存储，就需要 1M 的空间。那么创建 1T 的虚拟内存，就需要 1G 的空间。这意味着操作系统需要在启动时，就把这块需要的内存空间预留出来。

正因为我们设计的虚拟内存往往大于实际的内存，因此在历史上出现过各种各样节省页表空间的方案，其中就有用 HashTable 存储页表的设计。HashTable 是一种将键（Key）映射到值（Value）的数据结构。在页表的例子中，键是页编号，值是 Frame 编号。 你可以把这个 HashTable 看作存储了很多 <PageId, FrameId> 键值对的数据结构。

为了方便你理解下面的内容，我绘制了一张图。下图使用了一个有 1024 个条目的 HashTable。当查找页面 50000 的时候，先通过哈希函数 h 计算出 50000 对应的 HashTable 条目是 24。HashTable 的每个条目都是一个链表，链表的每个节点是一个 PageId 和 FrameId 的组合。接下来，算法会遍历条目 24 上的链表，然后找到 Page = 50000 的节点。取出 Frame 编号为 1232。

通常虚拟内存会有非常多的页，但是只有少数的页会被使用到。这种情况下，用传统的页表，会导致过多的空间被预分配。而基于 HashTable 的设计则不同，可以先分配少量的项，比如在上图中，先只分配了 1024 个项。每次查找一个页表编号发现不存在的情况，再去对应位置的链表中添加一个具体的键-值对。 这样就大大节省了内存。

当然节省空间也是有代价的，这会直接导致性能下降，因为比起传统页表我们可以直接通过页的编号知道页表条目，基于 HashTable 的做法需要先进行一次 Hash 函数的计算，然后再遍历一次链表。 最后，HashTable 的时间复杂度可以看作 O(k)，k 为 HashTable 表中总共的 <k,v> 数量除以哈希表的条目数。当 k 较小的时候 HashTable 的时间复杂度趋向于 O(1)。

25 | 内存管理单元：什么情况下使用大内存分页？

【问题】Java 和 Go 默认需不需要开启大内存分页?

【解析】在回答什么情况下使用前，我们先说说这两个语言对大内存分页的支持。

当然，两门语言能够使用大内存分页的前提条件，是通过“**25 讲”**中演示的方式，开启了操作系统的大内存分页。满足这个条件后，我们再来说说两门语言还需要做哪些配置。

Go 语言

Go 是一门编译执行的语言。在 Go 编译器的前端，源代码被转化为 AST；在 Go 编译器的后端，AST 经过若干优化步骤，转化为目标机器代码。因此 Go 的内存分配程序基本上可以直接和操作系统的 API 对应。因为 Go 没有虚拟机。

而且 Go 提供了一个底层的库 syscall，直接支持上百个系统调用。 具体请参考Go 的官方文档。其中的 syscall.madvise 系统调用，可以直接提示操作系统某个内存区间的程序是否使用大内存分页技术加速 TLB 的访问。具体可以参考 Linux 中madise 的文档，这个工具的作用主要是提示操作系统如何使用某个区域的内存，开启大内存分页是它之中的一个选项。

下面的程序通过 malloc 分配内存，然后用 madvise 提示操作系统使用大内存分页的示例：

#include <sys/mman.h>
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
madvise(mymemory, size, MADV_HUGEPAGE);

如果放到 Go 语言，那么需要用的是runtime.sysAlloc和syscall.Madvise函数。

Java 语言

JVM 是一个虚拟机，应用了Just-In-Time 在虚拟指令执行的过程中，将虚拟指令转换为机器码执行。 JVM 自己有一套完整的动态内存管理方案，而且提供了很多内存管理工具可选。在使用 JVM 时，虽然 Java 提供了 UnSafe 类帮助我们执行底层操作，但是通常情况下我们不会使用UnSafe 类。一方面 UnSafe 类功能不全，另一方面看名字就知道它过于危险。

Java 语言在“25 讲”中提到过有一个虚拟机参数：XX:+UseLargePages，开启这个参数，JVM 会开始尝试使用大内存分页。

那么到底该不该用大内存分页？

首先可以分析下你应用的特性，看看有没有大内存分页的需求。通常 OS 是 4K，思考下你有没有需要反复用到大内存分页的场景。

另外你可以使用perf指令衡量你系统的一些性能指标，其中就包括iTLB-load-miss可以用来衡量 TLB Miss。 如果发现自己系统的 TLB Miss 较高，那么可以深入分析是否需要开启大内存分页。

26 |  缓存置换算法： LRU 用什么数据结构实现更合理？

【问题】在 TLB 多路组相联缓存设计中（比如 8-way），如何实现 LRU 缓存？

【解析】TLB 是 CPU 的一个“零件”，在 TLB 的设计当中不可能再去内存中创建数据结构。因此在 8 路组相联缓存设计中，我们每次只需要从 8 个缓存条目中选择 Least Recently Used 缓存。

增加累计值

先说一种方法， 比如用硬件同时比较 8 个缓存中记录的缓存使用次数。这种方案需要做到 2 点：

1. 缓存条目中需要额外的空间记录条目的使用次数（累计位）。类似我们在页表设计中讨论的基于计时器的读位操作——每过一段时间就自动将读位累计到一个累计位上。
2. 硬件能够实现一个快速查询最小值的算法。

第 1 种方法会产生额外的空间开销，还需要定时器配合，成本较高。 注意缓存是很贵的，对于缓存空间利用自然能省则省。而第 2 种方法也需要额外的硬件设计。那么，有没有更好的方案呢？

1bit 模拟 LRU

一个更好的方案就是模拟 LRU，我们可以考虑继续采用上面的方式，但是每个缓存条目只拿出一个 LRU 位（bit）来描述缓存近期有没有被使用过。 缓存置换时只是查找 LRU 位等于 0 的条目置换。

还有一个基于这种设计更好的方案，可以考虑在所有 LRU 位都被置 1 的时候，清除 8 个条目中的 LRU 位（置零），这样可以节省一个计时器。 相当于发生内存操作，LRU 位置 1；8 个位置都被使用，LRU 都置 0。

搜索树模拟 LRU

最后我再介绍一个巧妙的方法——用搜索树模拟 LRU。

对于一个 8 路组相联缓存，这个方法需要 8-1 = 7bit 去构造一个树。如下图所示：

8 个缓存条目用 7 个节点控制，每个节点是 1 位。0 代表节点指向左边，1 代表节点指向右边。

初始化的时候，所有节点都指向左边，如下图所示：

接下来每次写入，会从根节点开始寻找，顺着箭头方向（0 向左，1 向右），找到下一个更新方向。比如现在图中下一个要更新的位置是 0。更新完成后，所有路径上的节点箭头都会反转，也就是 0 变成 1，1 变成 0。

上图是read a后的结果，之前路径上所有的箭头都被反转，现在看到下一个位置是 4，我用橘黄色进行了标记。

上图是发生操作read b之后的结果，现在橘黄色可以更新的位置是 2。

上图是读取 c 后的情况。后面我不一一绘出，假设后面的读取顺序是d,e,f,g,h，那么缓存会变成如下图所示的结果：

这个时候用户如果读取了已经存在的值，比如说c，那么指向c那路箭头会被翻转，下图是read c的结果：

这个结果并没有改变下一个更新的位置，但是翻转了指向 c 的路径。 如果要读取x，那么这个时候就会覆盖橘黄色的位置。

因此，本质上这种树状的方式，其实是在构造一种先入先出的顺序。任何一个节点箭头指向的子节点，应该被先淘汰（最早被使用）。

这是一个我个人觉得非常天才的设计，因为如果在这个地方构造一个队列，然后每次都把命中的元素的当前位置移动到队列尾部。就至少需要构造一个链表，而链表的每个节点都至少要有当前的值和 next 指针，这就需要创建复杂的数据结构。在内存中创建复杂的数据结构轻而易举，但是在 CPU 中就非常困难。 所以这种基于 bit-tree，就轻松地解决了这个问题。当然，这是一个模拟 LRU 的情况，你还是可以构造出违反 LRU 缓存的顺序。

27 | 内存回收上篇：如何解决内存的循环引用问题？

28 | 内存回收下篇：三色标记-清除算法是怎么回事？

【问题】如果内存太大了，无论是标记还是清除速度都很慢，执行一次完整的 GC 速度下降该如何处理？

【解析】当应用申请到的内存很大的时候，如果其中内部对象太多。只简单划分几个生代，每个生代占用的内存都很大，这个时候使用 GC 性能就会很糟糕。

一种参考的解决方案就是将内存划分成很多个小块，类似在应用内部再做一个虚拟内存层。 每个小块可能执行不同的内存回收策略。

上图中绿色、蓝色和橘黄色代表 3 种不同的区域。绿色区域中对象存活概率最低（类似 Java 的 Eden），蓝色生存概率上升，橘黄色最高（类似 Java 的老生代）。灰色区域代表应用从操作系统中已经申请了，但尚未使用的内存。通过这种划分方法，每个区域中进行 GC 的开销都大大减少。Java 目前默认的内存回收器 G1，就是采用上面的策略。

总结

这个模块我们学习了内存管理。通过内存管理的学习，我希望你开始理解虚拟化的价值，内存管理部分的虚拟化，是一种应对资源稀缺、增加资源流动性的手段（听起来那么像银行印的货币）。

既然内存资源可以虚拟化，那么计算资源可以虚拟化吗？用户发生大量的请求时，响应用户请求的处理程序可以虚拟化吗？当消息太大的情况下，一个队列可以虚拟化吗？当浏览的页面很大时，用户看到的可视区域可以虚拟化吗？——我觉得这些问题都是值得大家深思的，如果你对这几个问题有什么想法，也欢迎写在留言区，大家一起交流。

另外，缓存设计部分的重点在于算法的掌握。因为你可以从这些算法中获得很多处理实际问题的思路，服务端同学会反思 MySQL/Redis 的使用，前端同学会反思浏览器缓存、Native 缓存、CDN 的使用。很多时候，工具还会给你提供参数，那么你应该用哪种缓存置换算法，你的目的是什么？我们只学习了如何收集和操作系统相关的性能指标，但当你面对应用的时候，还会碰到更多的指标，这个时候就需要你在实战中继续进步和分析了。

这个模块还有一个重要的课题，就是内存回收，这块的重点在于理解内存回收器，你需要关注：暂停时间、足迹和吞吐量、实时性，还需要知道如何针对自己的业务场景，分析这几个指标的要求，学会选择不同的 GC 算法，配置不同的 GC 参数。

总之，一句话，这个模块引你入门，后续就靠你多实战和总结了。