本文深入梳理了虚拟内存如何解决进程隔离问题并构建独立受控的地址空间视图。常见 x86-64 模式下虚拟地址可达二百五十六TiB，却仅需实际映射部分对应真实物理内存资源。

MMU 利用四级页表将虚拟地址拆解为多个字段以索引 PGD、PUD、PMD 和 PTE 实现地址翻译。TLB 作为地址转换缓存层能减少查表开销，其命中率直接影响程序访问性能与执行效率。

内核通过按需分页与写时复制机制优化内存分配，并利用 mmap 减少文件读取时的数据拷贝从而提升 I/O 速度。

这几天学习了「《Virtual Memory: A Deep Dive into Page Tables, TLBs, and Linux Internals》」里面关于虚拟内存的知识，这篇文章我们来聊聊一个操作系统里的基础概念：虚拟内存。

学过「操作系统」的小伙伴可能知道，进程运行时看到的地址，并不一定等同于真实的物理内存地址。它看到的是一套由操作系统和硬件共同维护的虚拟地址空间。CPU 访问内存时，还需要通过页表、TLB 等机制，把虚拟地址翻译成物理地址。

原文讲得很细，从虚拟地址空间、页表、TLB、缺页异常，一路讲到 mmap、写时复制和 Linux 内核行为，不太适合作为一篇简单的入门学习内容。所以这篇文章会做一个简化版梳理，帮助你先理解几个基本问题：虚拟内存解决什么问题，虚拟地址如何映射到物理内存，缺页异常为什么存在，以及这些机制如何影响我们理解程序内存和性能问题。

为什么程序不能直接使用真实内存？

我们知道日常工作中，一台电脑会经常同时开着浏览器、编辑器、终端，连着数据库，以及跑着一堆后台进程。如果每个程序都直接拿着物理内存地址读写，就会遇到两个问题：第一，程序之间如何协调。程序 A 不知道程序 B 是否占用了某块物理内存，如果两个程序直接读写同一块物理地址，就可能互相覆盖数据，导致程序异常甚至系统不稳定。第二，安全性很差。程序 A 中的普通 bug，可能直接修改甚至破坏另一个程序的数据，导致程序异常。

所以，操作系统开始给每个进程安排了一套自己的“地址空间”。在进程眼里，它好像拥有一大片独立内存；但在操作系统眼里，这些地址还需要再翻译成真正的物理内存位置。

这就是虚拟内存的核心作用：让每个进程看到一套独立、受控、可管理的内存视图。

进程看到的内存布局

一个进程的虚拟地址空间通常会被分成几个区域：代码段、数据段、BSS、堆、内存映射区域、栈，以及内核保留区域。每个区域的分工如下：

• 代码段放程序指令；

• 数据段放已初始化的全局变量和静态变量；

• BSS 放未初始化或零初始化的全局变量；

• 堆用于运行时动态分配，比如 malloc 或 new；

• 栈用于函数调用、局部变量、返回地址等；

• 中间的大块区域可以放共享库、文件映射、大块匿名内存分配。

上图就是各区域分工的直观体现，我们可以看到 Stack、Heap、BSS、Data、Text / Code、memory-mapped region 在地址空间里的位置。

在常见的 48-bit x86-64 虚拟地址模式下，虚拟地址最多可以表示 2^48 个字节位置，也就是 256 TiB 的地址空间。这里的 256 TiB 指的是“可寻址范围”，不代表机器真的有这么多物理内存。Linux 通常会把这段虚拟地址空间分成两部分：低地址区域留给用户态进程，高地址区域用于内核映射。对应到上图，就是 low address 和 high address。

这也变相地解释了一个常见疑问：为什么一台只有 16GB / 32GB 内存的机器，进程却能拥有远大于物理内存容量的虚拟地址空间。虚拟地址空间的大小和真实 RAM 容量，本就是两码事。虚拟地址的空间可以很大，但只有被进程实际使用、并且建立了有效页表映射的部分，才会进一步对应到物理内存或页缓存中的数据页。

地址翻译的基本过程

下面轮到页表出场了。

操作系统不会按“每一个字节”去管理映射关系，那样太细、太繁琐了。它通常按页来管理。常见的页面大小是 4KB。虚拟地址空间被切成一页一页的虚拟页，物理内存也被切成一块一块的页框。

当程序访问一个虚拟地址时，CPU 里的 MMU，也就是内存管理单元，会根据页表把它翻译成物理地址。在 x86-64 的四级页表结构中，虚拟地址会被拆成多个字段，分别用于索引 PGD、PUD、PMD、PTE，最后 12 位作为页内偏移。

寻址过程：

上图解释了“一个虚拟地址是怎么被拆开，并逐级查表的”。把它想成查地图的话，大概流程就是：先用第一段地址信息找到大区 PGD；再用第二段找到街区 PUD；再用第三段找到楼 PMD；最后用第四段找到房间 PTE；最后的页内偏移告诉你具体是哪一个字节。

这样做的好处是：不用为整个巨大地址空间提前准备一张完整大表。只有真正用到的区域，才需要建立相应的页表结构。页表的层级是稀疏的，只为实际使用的地址空间分配结构，避免平铺页表带来的巨大开销。

连续地址背后的物理映射

这是虚拟内存里很重要的一点。程序看到的数组可能是连续地址。但这些虚拟页映射到物理内存时，可以分散在不同位置。程序并不需要知道这些细节。它只看到一段连续空间；页表负责把这些虚拟页指向真实的物理页框。

这个图解释了什么叫“程序看到连续，物理上可以分散”。物理映射也是虚拟内存让系统更灵活的地方。操作系统可以把不同进程的物理页框交错放在 RAM 里，同时保证每个进程看到的仍然是一套干净、连续、独立的地址空间。上图就在说这一点：相邻虚拟页可以落在相距很远的物理页框中，不同进程的页框也可以交错分布在物理内存里。

TLB：地址翻译的缓存层

每次访问内存都查页表，会不会很慢？答案是：会。所以硬件还准备了一个缓存：TLB（全称：Translation Lookaside Buffer，地址转换后备缓冲器）。

TLB 可以理解成“地址翻译缓存”。如果某个虚拟页到物理页框的映射刚刚查过，MMU（全称：Memory Management Unit，内存管理单元）下次就可以先查 TLB。命中之后，不需要完整走一遍页表。TLB 会自行缓存已经完成的地址翻译；只有 TLB 未命中时，MMU 才需要进行完整的页表遍历。程序的访问模式会显著影响 TLB 命中率。小工作集、重复访问的循环、复用的缓冲区，通常更容易保持 TLB 友好。

上图展示了 CR3 和四级页表遍历的大致路径。结合 TLB 来看，它也能解释为什么内存访问模式会影响性能：同样是读数据，顺序访问、局部性好的访问，往往比到处跳着访问更友好。

内存申请背后的按需分配

可能会有人以为，程序一申请内存，操作系统就立马分配对应的物理内存。实际上，操作系统会更懒一点。

操作系统可以先给你一段合法的虚拟地址范围，等你真正访问它时，再分配物理页框。这叫 demand paging，也就是按需分页。

比如程序调用 malloc 后，可能已经拿到了一段可用的虚拟地址范围。但这不代表对应的物理内存已经全部分配好了。只有当程序第一次读写某一页时，CPU 发现页表里没有有效映射，就会自动触发 page fault，也就是缺页异常。内核接手后，先检查这个地址是否合法。如果合法，就分配一个物理页框，更新页表，然后让程序继续执行。这个过程可以概括为：page fault 发生后，内核检查 faulting address 是否落在有效 VMA 内；如果合法，就分配物理 frame、更新页表并恢复执行；如果不合法，就会变成 segmentation fault。

上图为“程序访问 → MMU 发现 present=0 → 内核处理 → 更新 PTE → 程序继续运行”整个流程是如何运作的。有时候，我们的程序会看起来申请了很多内存，但实际 RSS（全称：Resident Set Size，常驻集大小）没有立刻涨那么多。因为虚拟地址可以先被预留出来，物理页框往往等到真正访问时才会分配并建立映射。

写时复制背后的进程复制

虚拟内存还支撑了一个很经典的机制：copy-on-write，写时复制。

在 Unix/Linux 系统里，fork() 会创建一个子进程。我们可能会觉得子进程要复制父进程的整个地址空间，这应该很贵。但系统很聪明，不会一开始就把所有内存都复制一遍。

它会让父进程和子进程先共享同一批物理页，并把相关页标记成只读。等其中一个进程真的要写某一页时，CPU 再触发权限异常。然后内核来复制那一页，给写入方一份私有副本。

下图展示了这个过程：fork() 后两个页表先指向同一批物理 frame；当 Alloca 写入 page A 时，内核分配新 frame、复制内容，并只更新 Alloca 的 PTE。

这个机制让 fork() 的执行成本变低了。尤其是常见的 fork + exec 模式里，子进程马上加载新程序，很多旧页面根本没有复制的必要。

mmap 背后的文件映射

虚拟内存还有一个常见用途：mmap，一种把文件或内存区域映射到进程虚拟地址空间里的机制。普通 read() 操作读取文件时，数据通常会先进入内核的页缓存，再复制到用户态 buffer。 mmap() 会把文件的一段内容映射到进程地址空间里，程序可以像访问内存一样访问文件内容。

上图为 read() 与 mmap() 的 I/O 路径对比。使用 read() 时，数据会从磁盘读入页缓存，然后再复制到进程的用户态缓冲区。使用 mmap() 时，进程的 PTE 会映射到承载页缓存数据的物理页框上，从而省去从页缓存到用户态缓冲区的这次复制。代价是，mmap() 不再通过显式的 read 调用来完成读取，而是需要承担缺页异常和页表管理带来的开销。

小结

虚拟内存听起来很底层，但它会影响很多日常开发问题：

• 为什么空指针访问会崩？

• 为什么栈溢出会触发 segfault？

• 为什么进程虚拟内存很大，实际占用却没那么大？

• 为什么随机访问大数组可能很慢？

• 为什么 fork() 没有想象中那么贵？

• 为什么 mmap() 有时快，有时并不快？

这些问题背后都绕不开虚拟地址、页表、TLB、缺页异常和内核内存管理。

理解虚拟内存，不是为了记住一堆术语，而是为了知道：程序眼里的“内存地址”，只是操作系统和硬件共同维护出来的一层抽象。真正的数据在哪里、什么时候分配、能不能访问、访问是否高效，都要经过这一层机制来决定。

所以，下次你看到一个指针地址时，可以多想一步：这个地址看起来像真实位置，但它首先是一张地图上的坐标。真正把它带到物理内存里的，是 MMU、页表、TLB 和内核。

阅读原文：点击这里