玻尔百科mmap）等特性统一了文件 I/O 和内存管理，允许应用程序如同访问内存一样与文件交互。sendfile()）、直接 I/O（O_DIRECT）和内存建议（MADV_DONTNEED）等高级技术允许应用程序针对特定工作负载微调 I/O 行为。在现代计算领域，快如闪电的 CPU、RAM 与相对迟缓的存储设备之间存在着巨大的性能鸿沟。弥合这一鸿沟对系统性能至关重要，而主要的解决方案是由操作系统管理的一个复杂的缓存层。许多开发者每天都在与文件打交道，却常常对这个过程中最重要的组件——页缓存（page cache）——浑然不觉。这个无形的中间层决定了几乎所有文件操作的速度和效率，是所有 I/O 的“中央枢纽”。理解其行为不仅是一项学术操练，更是编写高性能、资源高效软件的先决条件。
本文将层层揭开这一基本操作系统概念的神秘面纱。首先，在“原理与机制”一章中，我们将探讨页缓存是什么，它如何将缓慢的磁盘读取转变为快速的内存访问，以及它通过内存映射文件和共享代码在统一文件 I/O 与内存管理方面所扮演的优雅角色。随后，“应用与跨领域关联”一章将展示这些原理的实际应用，审视页缓存如何影响高速 Web 服务器的设计、海量数据集的处理以及虚拟化系统的架构。读完本文，您将对这个计算世界的无名英雄产生深刻的认同，并掌握在自己的工作中有效利用它的知识。
任何现代操作系统的核心都在进行着一场持续而急促的协商——一场关于速度的协商。您的计算机处理器及其主内存（RAM）就像一辆 F1 赛车——快得令人难以置信，每秒能执行数十亿次操作。相比之下，您的存储设备，无论是旋转式硬盘还是高速固态硬盘（SSD），都像一艘货轮——容量巨大，但启动却异常缓慢。如果处理器每次需要一点数据都必须等待货轮，那么我们所知的计算将会陷入停滞。解决这种不匹配的方案是缓存，而整个系统中最重要的缓存就是页缓存（page cache）。
想象一下，您计算机的主内存是一位能工巧匠的工作台，而磁盘驱动器是街对面一个庞大的仓库。如果您需要一个特定的螺母或螺栓（一块数据），您可以走到仓库，找到正确的货架和货箱，挑出您需要的那一件，然后走回来。这样做效率极低。一个更好的策略是预判您的需求。如果您正在做一个项目，您会把整盘常用零件——螺丝、螺栓、支架——都拿到您的工作台上摆好。现在，当您需要一个零件时，它就在您的指尖。
页缓存正是这个工作台。它是您计算机 RAM 的一大部分，由操作系统征用，以存放最近从文件中使用过的数据。当您的应用程序请求读取文件时，操作系统不会立即去访问磁盘，而是首先检查页缓存。
这导致了两种截然不同的情景，正如一项经典性能测试所揭示的。
操作系统也是一个聪明的助手。如果它看到您正在顺序读取一个文件，它会假设您很快就需要下一部分。因此，它会执行预读（readahead）：当它去仓库为您取回第 100 号块时，它也会一并取回 101、102 和 103 号块，因为它知道您接下来很可能会需要它们。这种智能的预取操作正是流式传输大型视频文件如此流畅的原因；操作系统始终领先一步，确保在视频播放器需要数据时，数据已经摆在工作台上了。
一个简单读取请求的整个过程是一支层次分明、优美协作的舞蹈：您的应用程序发出的 read() 调用被递交给虚拟文件系统（VFS），这是一个通用接口，它抽象了 ext4 或 NTFS 等具体文件系统的细节。VFS 将请求传递给特定文件系统的代码，后者则会查询至关重要的页缓存。只有在未命中时，请求才会继续下传到块层（block layer），由块层为设备调度 I/O 请求，最后到达设备驱动程序，由驱动程序使用硬件的本地语言进行通信。
页缓存真正的优雅之处由此开始显现。它不仅仅是 read() 调用的一个简单加速技巧，而是操作系统核心中一个深刻的、统一的原则。
设想一下，如果您可以直接在主工作台上工作，而不是请求操作系统将数据从它的工作台复制到您的私人工作区，会怎样？这就是内存映射 I/O（memory-mapped I/O）或 mmap() 背后的思想。通过这个系统调用，您可以请求操作系统将一个文件直接映射到您应用程序的虚拟地址空间。现在，磁盘上的文件看起来就像内存中的一个巨大数组。
当您第一次触碰这个“数组”中的一个字节时，CPU 会触发一个页错误（page fault）。操作系统介入，发现这个内存区域对应一个文件，于是从该文件加载相关的页面到页缓存中。然后，它更新您进程的页表，使其直接指向缓存中的那个物理页帧。从那一刻起，访问该数据就和访问内存中任何其他变量一样快。
最美妙的部分在于：页缓存是一个统一缓存（unified cache）。支持您的内存映射区域的页帧与用于服务同一文件偏移量的 read() 调用的页帧是完全相同的。无论您使用 read() 还是 mmap()，您都在与同一个工作台交互。这种设计避免了冗余并确保了一致性。对于需要反复扫描相同数据的应用程序来说，mmap() 的效率要高得多。在建立映射的初始阶段产生一些次要页错误（minor page faults）之后，所有后续的遍历都是纯粹、极速的内存访问，无需任何系统调用和数据复制。
这个统一原则甚至延伸到您执行的代码本身。一个程序的可执行文件——其机器码指令——也只是一个文件。当您运行一个应用程序时，操作系统使用其内存映射功能将代码加载到内存中。现在，如果您和您的同事都运行同一个程序，比如说，一个文本编辑器，会怎样？如果操作系统将两个完全相同的文本编辑器代码副本加载到内存中，那将是极大的浪费。
取而代之的是，操作系统只将代码页加载到页缓存中一次。然后，它将这同一组物理页映射到你们两个进程的虚拟地址空间中。这是内存共享的典范。只读代码（“代码段”）被所有人共享。当然，你们每个人都需要自己的私有数据（“数据段”）来进行工作。在这里，操作系统运用了另一个聪明的技巧：写时复制（Copy-on-Write, COW）。最初，两个进程也共享包含初始数据的页面。但是，一旦您试图写入其中一个页面，操作系统就会立即介入，透明地为您创建该页面的一个私有副本，并更新您的映射以指向新的副本。您获得了自己可以修改的私有版本，而所有未修改页面的共享状态则保持不变。页缓存是实现所有这一切无缝高效的核心角色。
在当今的多核世界中，页缓存作为统一者的角色变得更加关键。想象一下，两个进程在两个不同的 CPU 核心上运行，它们都以共享权限 mmap 同一个文件。进程 1 将值 42 写入文件中的某个位置。进程 2 何时能看到这个变化？
答案是：立即。但这里的魔力并非由操作系统完成。页缓存确保两个进程都看着同一个物理内存页面。剩下的则由 CPU 硬件本身处理。现代处理器拥有复杂的缓存一致性协议（cache coherence protocols），确保一个核心对内存位置所做的任何更改都能迅速对所有其他核心可见。这是操作系统软件（提供共享舞台）和 CPU 硬件（执行可见性规则）之间的一曲美妙交响乐。
然而，这种即时共享突显了缓存的一个关键特性：它是易失性的（volatile）。工作台是临时的。如果断电，上面的所有东西都会丢失。当应用程序写入数据时，最初它只被写入页缓存。相应的页面被标记为脏页（dirty）。它尚未被存回磁盘这个永久的仓库。
为了实现持久性（durability）——保证数据在断电后依然存在——数据必须完成一次穿越多层缓存的危险旅程 [@problem_-id:3690179]。
只有当数据完成第 5 步时，它才真正安全。这就是为什么像数据库这样非常关心数据完整性的应用程序必须使用像 [fsync](/sciencepedia/feynman/keyword/fsync)() 这样的特殊系统调用。这个调用是对操作系统的一个明确指令：“处理这个文件的数据，并且在得到仓库确认其已安全存储在非易失性货架上之前不要返回，沿途刷新每一个易失性缓存。”
页缓存尽管才华横溢，却并非万能灵药。它的存在有时反而会制造问题。最经典的例子是双重缓存（double caching）。像数据库引擎这样的高性能应用程序通常会在用户空间的“缓冲池”（buffer pool）中实现自己高度专业化的缓存逻辑，因为它们比通用目的的操作系统更了解自己的数据访问模式。
如果这样的数据库使用标准的缓冲 I/O（buffered I/O），一块数据会首先被读入操作系统页缓存，然后被复制到数据库自己的缓冲池中。同样的数据现在在 RAM 中存在两份！这是对宝贵内存的巨大浪费。更糟糕的是，操作系统和数据库现在各自独立且无协调地管理着相同的数据，这可能导致低效的驱逐决策。解决方案是直接 I/O（Direct I/O）（例如，使用 [O_DIRECT](/sciencepedia/feynman/keyword/o_direct) 标志打开文件）。这告诉操作系统：“请让开。我将自己管理缓存。”直接 I/O 完全绕过页缓存，允许应用程序直接在磁盘和它自己的缓冲区之间移动数据。
然而，这种权力伴随着责任。如果一个依赖操作系统预读机制的简单应用程序使用了 [O_DIRECT](/sciencepedia/feynman/keyword/o_direct)，性能可能会急剧下降。通过绕过页缓存，它也绕过了操作系统巧妙的预取功能，将原本几次大型、高效的磁盘读取变成了成千上万次微小、缓慢的读取。天下没有免费的午餐。
最后的挑战是压力。工作台的大小是有限的。当它变得太满，或者当系统 просто空闲内存不足时，会发生什么？操作系统必须施加反压。如果一个应用程序产生脏页的速度超过了磁盘写出的速度，操作系统最终会强制该应用程序休眠——这个过程称为回写节流（writeback throttling）——直到磁盘赶上进度。同样，如果空闲内存低于一个临界水位，操作系统可能会让一个应用程序原地暂停，并强制它参与直接回收（direct reclaim）——在允许它分配更多内存之前，同步地释放内存。
这引出了一个终极问题：当必须释放内存时，应该驱逐哪个页面？是丢弃一个文件缓存中的干净页面（这样做成本低，但可能很快又需要），还是驱逐一个正在运行进程的匿名内存页（这必须先写入交换空间，是一个缓慢的操作）？这种复杂的权衡是操作系统页面替换策略的范畴，是在 I/O 成本和未来使用概率之间持续进行的平衡艺术。在 Linux 中，用户甚至可以调整这个决策，这揭示了内存管理核心深邃而有趣的策略选择。
页缓存远不止一个简单的缓冲区。它是一个核心的、统一的抽象，优雅地连接了文件和内存的世界，实现了进程间资源的高效共享，并主动管理着高性能系统带来的持续压力。它是现代计算领域中一位默默无闻的英雄。
既然我们已经熟悉了页缓存的原理，让我们踏上一段旅程，去看看它在真实世界中的表现。您会发现，它不仅仅是操作系统内部一个巧妙的工程设计，而是计算这幕宏大戏剧中的一个核心角色。从您网页浏览器的速度，到海量数据库的设计，再到云的架构，它的影响无处不在。要理解页缓存的自然生境，就是要理解让计算机真正变得快速高效的微妙艺术。
想象一下，您是一名程序员，任务是编写一个高性能的 Web 服务器。它的主要工作是将文件从磁盘发送到网络上的客户端。我们如何才能尽可能快地完成这项工作？通往极致速度的旅程，是一个与操作系统协同工作的美好例证，而页缓存是我们的主要伙伴。
一种简单的方法可能是使用 read() 系统调用将文件从内核复制到我们应用程序的缓冲区中，然后用 write() 系统调用将数据从我们的缓冲区复制到网络套接字。这样做是可行的，但这就像是请图书管理员取来一本书，然后费力地将一个章节手抄到笔记本上，再对着笔记本通过电话口述文本。您亲自动手移动了两次数据。read() 调用促使数据从页缓存复制到您的应用程序缓冲区，而 write() 又促使数据从您的缓冲区复制到内核的套接字缓冲区。这期间，CPU 策划了两次完整的数据复制。
我们能做得更好吗？当然！我们可以使用 mmap() 创建内存映射文件。我们不再请求数据的副本，而是请求内核将文件的页面直接映射到我们应用程序的地址空间。这就像在书页上放一张透明纸，然后直接从中读取。当我们对这个映射区域调用 write() 时，内核直接将数据从页缓存复制到套接字缓冲区。我们消除了一次完整的复制——即复制到我们应用程序临时缓冲区的那一次。这个简单的改变通过减轻 CPU 和内存总线的负担，可以带来显著的性能提升。
但故事并未就此结束。对于这种将文件发送到套接字的常见任务，一些操作系统提供了一个优雅的大师之作：sendfile() 系统调用。这是“不挡路”哲学的终极体现。您只需告诉内核：“请将这个文件的这么多字节发送到那个套接字。”内核会完全接管。CPU 不再是复制数据的劳工，而成了一位指挥家。它指示网络接口控制器（NIC），利用一种称为直接内存访问（DMA）的能力，直接从页缓存中获取文件数据并将其发送到网络上。数据本身从未被 CPU 复制过。这就是“零拷贝”（zero-copy）I/O 的精髓，是 CPU、页缓存和硬件之间为以最小的代价实现最大吞吐量而进行的美妙协作。
页缓存是一个很棒的工具，但它是有限的。当我们必须处理一个远大于可用内存的文件时，会发生什么？想象一下，在一台只有 48 GiB 内存的机器上扫描一个 800 GiB 的日志文件。这就像试图在一张只能放下一卷书的桌子上阅读整套百科全书。
如果我们的访问模式是随机的，我们就会陷入一种被称为页缓存颠簸（page cache thrashing）的陷阱。我们请求 ‘A’ 卷中的一个页面，操作系统很乐意地取来它，放在我们的桌子上。然后我们请求 ‘Z’ 卷中的一个页面。为了腾出空间，操作系统遵循其最近最少使用（LRU）策略，可能会丢弃来自 ‘A’ 卷的页面。如果我们之后又需要 ‘A’ 卷的那个页面，操作系统必须再次从磁盘中获取它。我们所有的时间都花在了交换书卷上，而真正阅读的时间却很少。
草率地并行化工作甚至会使情况变得更糟。如果我们指派几个线程以交错的、跨步的模式（线程 0 读取页面 ）扫描文件，我们会破坏任何顺序访问的迹象。这种模式完全挫败了操作系统的预读机制，该机制依赖于检测顺序读取来预取后续页面。结果是一场随机 I/O 请求的风暴。
解决方案在于合作。应用程序知道自己的意图，并且可以与操作系统分享。对于顺序扫描，我们可以给内核一个像 MADV_SEQUENTIAL 这样的提示，鼓励它进行积极的预读。更强大的是，当我们处理完文件的一个块后，我们可以使用像 MADV_DONTNEED 这样的提示说：“我用完这些页面了，你可以收回它们。”这个简单的建议性调用具有变革性的作用。它防止页缓存被陈旧无用的数据填满，并有效地将其转变为一个大小恰好、高效的流式缓冲区。这使我们能够用有限的内存处理几乎无限大小的数据集，从而避免了颠簸陷阱。
然而，有时候，最复杂的举动是礼貌地拒绝操作系统的帮助。考虑一个数据库正在执行大规模的外部归并排序，它需要不断地从数千个已排序的临时文件中读取小块数据。这种访问模式对于 LRU 缓存来说是已知的最坏情况。应用程序知道这一点，但通用的操作系统却不知道。在这种情况下，专业的应用程序可以使用直接 I/O（Direct I/O）（例如 [O_DIRECT](/sciencepedia/feynman/keyword/o_direct)）来完全绕过页缓存。它承担起管理自己的 I/O 缓冲区和预取的重任。这避免了用那些没有希望被重用的数据污染页缓存，并防止操作系统的缓存策略干扰应用程序的专门化工作负载。这是一个深刻的教训：虽然页缓存是一个出色的通用工具，但有些问题需要专家的手法来解决。
页缓存并非在真空中运行。其有效性与应用程序数据的结构以及底层硬件的架构紧密相连。
想象一个存储了大量记录的数据库。我们可以使用面向文档的布局（document-oriented layout），即单个记录的所有属性都存储在一起，就像传统的电话簿。或者我们可以使用列式布局（columnar layout），即单个属性的所有值都分组在一起——一本书存放所有的名字，另一本存放所有的电话号码。现在，考虑一个工作负载，它首先扫描所有名字，然后扫描所有电话号码。
对于列式布局，第一次扫描会将整个“名字”之书读入页缓存。第二次扫描随后请求“电话号码”之书，它由一组完全不同的页面组成。第一次扫描缓存的数据是无用的；缓存重用率为零。而对于文档布局，第一次扫描必须读取整本电话簿来提取名字。当第二次扫描开始时，它发现整本电话簿已经因为第一次扫描而存在于页缓存中。第二次扫描几乎完全从内存中得到服务。这个简单的数据布局选择对 I/O 性能产生了巨大影响，而这一切都是因为它与页缓存的交互方式。
硬件的物理现实也扮演着关键角色。在大型多插槽服务器中，我们会遇到非统一内存访问（Non-Uniform Memory Access, NUMA）。这意味着机器由多个节点组成，每个节点都有自己的本地内存。访问本地节点上的内存速度快；访问远程节点上的内存则明显较慢。那么，页缓存的页面物理上驻留在哪里呢？大多数操作系统遵循首次接触策略（first-touch policy）：页面的物理内存被分配在首次请求它的 CPU 所在的 NUMA 节点上。
考虑两个线程，分别固定在节点 0 和节点 1 上，各自处理一个大文件的一半。如果我们首先让节点 0 上的一个辅助线程读取整个文件来“预热”缓存，那么所有文件的页面都将被分配在节点 0 的内存中。当我们的工作线程开始时，节点 0 上的线程将享受到快速的本地内存访问。但是节点 1 上的线程将不得不在处理其负责的文件半部分时，进行缓慢的远程内存访问。一个更聪明的策略是让每个工作线程对其自己分区的文件执行“首次接触”。这样，页缓存页面就被分配在使用它们的本地位置，从而最大化内存带宽并将处理时间减半。在一个 NUMA 世界中，真正的局部性不仅仅是存在于内存中；而是存在于正确的内存中。
页缓存是一个共享的、内核级的资源，这在现代多租户环境中引发了有趣的行为。
在Linux 容器的世界里，多个隔离的应用程序在单个共享的内核上运行。这意味着它们也共享一个单一的页缓存。想象一下，容器 A 和容器 B 都需要读取同一个大型库文件。容器 A 首先读取它，页面被加载到缓存中，内存使用量被“计费”到容器 A 的资源限制下。当容器 B 读取同一个文件时，它发现每个页面都已在内存中。它以闪电般的内存速度获取数据，并且值得注意的是，它自己的内存使用量并没有增加。费用仍然由最初的访问者承担。页缓存作为一种自然而然的自动数据去重器，在高密度系统中节省了大量的 RAM。
在完整的虚拟机（VM）中，情况就不同了，因为它们运行自己独立的操作系统内核。在这里，我们遇到了“语义鸿沟”（"semantic gap"）。想象一下，一个托管 VM 的 hypervisor 物理内存不足。为了回收一些内存，它可能会选择 VM 的一个内存页面并将其写出到缓慢的交换设备上。但如果从 VM 内部的客户机操作系统看来，那个页面只是一个干净的页缓存页面呢？客户机知道这只是其虚拟磁盘上已存在数据的一个临时副本；它本可以被立即丢弃，无需任何 I/O。而 hypervisor 由于对该页面的含义一无所知，执行了一次完全不必要且代价高昂的换出操作。这就是为什么像气球（ballooning）这样的协作机制如此智能。Hypervisor 在客户机内部“吹起一个气球”，制造人为的内存压力。客户机操作系统感受到压力后，会以它所知最智能的方式做出响应：它首先丢弃其价值最低的页面——通常是其缓存中的干净页面。它以最小的开销解决了内存压力，弥合了语义鸿沟。
最后，让我们思考页缓存的在实现最终目标——使数据持久化（durable）——中的角色。几十年来，契约一直很明确。应用程序调用 write()，将数据放入易失性的页缓存中。然后它调用 [fsync](/sciencepedia/feynman/keyword/fsync)()，这是操作系统的一个庄严承诺，即在数据从页缓存安全写入物理磁盘之前，它不会返回。页缓存是通往持久化漫长道路上的一个回写缓冲区。
但是，当内存本身变得持久，比如非易失性内存（Non-Volatile RAM, NVRAM）时，会发生什么？游戏规则改变了。通过直接访问（Direct Access, DAX），应用程序可以映射一个文件，并使其内存操作直接作用于持久性 NVRAM，完全绕过页缓存。突然之间，熟悉的安全网消失了。持久化的责任转移到了应用程序身上。在执行一次存储操作后，数据可能仍然停留在 CPU 自己的易失性缓存中。程序员现在必须执行一套新的仪式：使用像 CLWB 这样的指令显式地刷新被修改的缓存行，然后发出一个内存屏障（SFENCE）来保证数据已真正到达 NVRAM 的持久化领域。页缓存是一个宏伟的抽象层。随着现代硬件的发展，我们有时可以为了性能而剥离这一层，但这样做，我们必须承担起它曾经为我们优雅处理的复杂责任。
从一个简单的文件服务器到云的架构，页缓存是一股沉默而强大的力量。它是软硬件协同工作时所产生的优雅解决方案的证明，是一项美妙的工程杰作，其原理以对数字世界更深刻的理解回报着好奇的心灵。