虚拟内存：一张页表统一了整个内存世界

引言

1961 年，英国曼彻斯特大学的 Atlas 计算机首次实现了虚拟内存。其设计动机朴素而直接：物理内存昂贵且容量有限，而程序对内存的需求却在不断增长。设计者在程序与物理内存之间引入了一层映射表，使程序不再直接操作物理地址。这一层抽象不仅解决了内存容量问题，还同时解决了地址冲突、系统稳定性、安全隔离等一系列看似无关的问题。

此后六十余年，虚拟内存的核心思想从未改变。如今每一台手机、个人电脑和服务器都在使用这一机制。它是操作系统中最重要的抽象机制之一——虚拟内存系统（Virtual Memory System）。

一、术语定义

在展开讨论之前，首先明确本文涉及的核心术语：

页表是整个虚拟内存系统的数据结构核心，全部机制围绕它运转。

二、实地址模式：没有虚拟内存的困境

要理解虚拟内存的价值，首先需要了解没有它的年代面临怎样的困境。

2.1 DOS 时代的内存模型

以 MS-DOS 为代表的早期操作系统采用实地址模式，程序直接使用物理地址访问内存：

物理内存布局（实模式，最大 1MB） ┌──────────────────────────┐ 0x00000 │ BIOS 数据 / 中断表 │ ├──────────────────────────┤ 0x00400 │ DOS 内核 │ ├──────────────────────────┤ 0x01000 │ 程序 A │ ← 直接占用物理地址 ├──────────────────────────┤ 0x20000 │ 程序 B │ ← 直接占用物理地址 ├──────────────────────────┤ 0x40000 │ 空闲区域 │ ├──────────────────────────┤ 0xA0000 │ 显存 │ └──────────────────────────┘ 0xFFFFF

2.2 四个根本性缺陷

这一模型存在四个无法回避的问题。它们看似彼此独立，但共享同一个根源：程序直接操作物理地址，缺少中间抽象层。

缺陷 1：内存容量受限 ├── 物理内存仅有数 MB ├── 程序需要更大的地址空间 └── 物理内存无法容纳时，程序无法运行 缺陷 2：地址空间冲突 ├── 程序 A 编译后占用地址 0x20000 起始 ├── 程序 B 恰好也需要同一区域 └── 二者无法同时加载，必须手动协调地址分配 缺陷 3：系统稳定性脆弱 ├── 程序 A 的一个指针越界，写入了 0x01000 ├── 该地址恰好是 DOS 内核所在位置 ├── 内核数据被覆盖 └── 整台计算机崩溃，未保存的数据全部丢失 缺陷 4：无安全隔离 ├── 程序 A 可直接读取地址 0x20000 ├── 该地址存放着程序 B 的数据 └── 任何程序均可窥探或篡改其他程序的内存内容

虚拟内存系统的引入，正是为了在程序与物理内存之间建立一层抽象，从根源上消除这四个缺陷。

三、页表：程序与物理内存之间的抽象层

3.1 核心思想

虚拟内存系统的核心可以概括为一句话：

为每个进程维护一张独立的映射表（页表），将进程使用的虚拟地址翻译为实际的物理地址。

进程不再直接接触物理内存，而是通过页表间接访问。这一层间接性，正是解决所有问题的关键。

进程 A 的虚拟地址空间 进程 B 的虚拟地址空间 ┌──────────────────┐ ┌──────────────────┐ │ 0x0000 代码段 │ │ 0x0000 代码段 │ │ 0x1000 数据段 │ │ 0x1000 数据段 │ │ 0x2000 堆 │ │ 0x2000 堆 │ │ ... │ │ ... │ │ 0xFFFF 栈 │ │ 0xFFFF 栈 │ └────────┬─────────┘ └────────┬─────────┘ │ │ "我的 0x1000" "我的 0x1000" │ │ ▼ ▼ A 的页表 B 的页表 虚拟页0 → 物理页 5 虚拟页0 → 物理页 12 虚拟页1 → 物理页 8 虚拟页1 → 物理页 20 虚拟页2 → 磁盘位置 X 虚拟页2 → 物理页 3 虚拟页3 → 未分配 虚拟页3 → 磁盘位置 Y

相同的虚拟地址，通过各自的页表映射到不同的物理位置。进程彼此感知不到对方的存在。

3.2 虚拟地址空间的容量

3.2.1 32 位架构：4GB 的由来与局限

在 32 位架构下，CPU 的地址总线宽度为 32 位，因此每个进程的虚拟地址空间上限为：

2^32 = 4,294,967,296 字节 = 4GB

这 4GB 并非全部供用户程序使用，操作系统通常将其划分为两部分：

32 位 Linux 的典型划分： ┌──────────────────────┐ 0xFFFFFFFF │ 内核空间（1GB） │ ← 所有进程共享同一份内核映射 ├──────────────────────┤ 0xC0000000 │ 用户空间（3GB） │ ← 用户程序可使用的范围 └──────────────────────┘ 0x00000000 32 位 Windows 的典型划分： ┌──────────────────────┐ 0xFFFFFFFF │ 内核空间（2GB） │ ├──────────────────────┤ 0x80000000 │ 用户空间（2GB） │ └──────────────────────┘ 0x00000000

在 32 位时代，4GB 的虚拟地址空间在多数场景下足以满足需求。然而随着应用规模的增长——大型数据库、科学计算、视频编辑等场景中，单个进程的内存需求已经远超 4GB——这一限制成为了瓶颈。

3.2.2 64 位架构：从 4GB 到 256TB

64 位架构（x86-64）从根本上解决了地址空间不足的问题。理论上，64 位地址可以寻址 2^64 = 16 EB（Exabytes），但当前硬件实现中仅使用了其中 48 位：

2^48 = 256 TB 虚拟地址空间 这一容量对于当前及可预见的未来均已充裕。 操作系统可根据硬件发展，逐步启用更多地址位， 而无需改变整体架构。 64 位 Linux 的典型划分： ┌──────────────────────┐ 0xFFFFFFFFFFFFFFFF │ 内核空间（128TB） │ ├──────────────────────┤ │ 不可用（空洞） │ ← 48位规范地址之间的间隔 ├──────────────────────┤ │ 用户空间（128TB） │ └──────────────────────┘ 0x0000000000000000

3.3 虚拟地址空间与物理内存消耗的关系

一个常见的疑问是：如果每个进程拥有 4GB（32 位）乃至 128TB（64 位）的虚拟地址空间，而实际只使用其中很小一部分，是否造成资源浪费？

答案是：不会。虚拟地址空间的大小与物理内存的实际消耗是两个完全独立的概念。

虚拟地址空间 = 一本有 128TB 页码的"目录" 物理内存消耗 = 目录中实际填写了内容的页数 一个进程拥有 128TB 的虚拟地址空间： ├── 并不意味着操作系统为其分配了 128TB 的物理内存 ├── 也不意味着页表覆盖了全部 128TB 的地址 │ ├── 实际情况： │ ├── 进程仅使用了其中 500MB 的地址范围 │ ├── 操作系统仅为这 500MB 创建页表映射 │ ├── 其中当前活跃的部分占用物理内存页框 │ ├── 不活跃的部分可能被换出到磁盘 │ └── 未使用的地址范围不消耗任何物理资源 │ └── 保障这一效率的两个关键机制： ├── 多级页表：未使用的地址范围不分配下级页表（详见第六章） └── 懒加载：即使程序申请了内存，操作系统也延迟到首次访问时 才分配物理页框（详见 5.5.4 节）

因此，虚拟地址空间的大小可以设计得远大于物理内存容量。操作系统通过页表和缺页中断机制，确保只有实际需要的部分才占用物理资源。虚拟地址空间是"能力上限"，而非"实际消耗"。

3.4 页表条目的结构

每个页表条目（Page Table Entry, PTE）仅占数字节，但其中每一个标志位都承载着明确的设计意图：

┌────────┬────────┬────────┬────────┬────────┬──────────────┐ │ 存在位 │ 读写位 │ 用户位 │ 访问位 │ 脏位 │ 物理页框号 │ │ P │ R/W │ U/S │ A │ D │ PFN │ └────────┴────────┴────────┴────────┴────────┴──────────────┘ ↑ ↑ ↑ ↑ ↑ 该页在 可读 用户态 该页是否 该页是否 物理内存 还是 能否 被访问过 被写入过 还是磁盘 可写 访问

3.5 地址翻译过程

以 32 位系统为例，当 CPU 执行一条内存访问指令时，地址翻译按以下步骤进行：

CPU 执行指令: MOV EAX, [0x00401234] 第 1 步：拆分虚拟地址 ┌────────────────────────────────────────┐ │ 虚拟地址 0x00401234 │ │ │ │ 高 20 位 → 虚拟页号: 0x00401 │ │ 低 12 位 → 页内偏移: 0x234 │ └────────────────────────────────────────┘ │ ▼ 第 2 步：查询 TLB（详见第六章 6.3 节） ┌────────────────────────────────────────┐ │ TLB 命中 → 直接获得物理页框号 │ │ 仅需数个时钟周期，完成翻译 │ │ │ │ TLB 未命中 → 进入第 3 步 │ └────────────────────────────────────────┘ │ ▼ 第 3 步：查询页表（MMU 硬件遍历多级页表） ┌────────────────────────────────────────┐ │ 读取当前进程页表中虚拟页 0x00401 的条目 │ │ │ │ 情况 A：存在位 P = 1 │ │ → 取出物理页框号，拼接页内偏移 │ │ → 得到物理地址，完成访问 │ │ │ │ 情况 B：存在位 P = 0 │ │ → 触发缺页中断，进入第 4 步 │ └────────────────────────────────────────┘ │ ▼ （仅缺页时） 第 4 步：操作系统处理缺页中断 ┌──────────────────────────────────────────┐ │ 1. 根据页表条目中记录的磁盘位置， │ │ 在交换空间中找到该页数据 │ │ 2. 在物理内存中分配一个空闲页框 │ │ （若无空闲页框，通过置换算法选择 │ │ 一个页面换出到磁盘） │ │ 3. 将数据从磁盘读入该页框 │ │ 4. 更新页表条目：P = 1，填入物理页框号 │ │ 5. 更新 TLB │ │ 6. 重新执行触发缺页的那条指令 │ │ │ │ 全过程对进程完全透明 │ └──────────────────────────────────────────┘

四、一套机制，逐层解决的问题

页表机制所解决的问题并非孤立的，它们之间存在清晰的层次关系：先满足基本需求（内存容量），再保证正确性（地址不冲突），然后实现保护（崩溃隔离），进而提供安全性（数据不泄露），最终支撑扩展应用（共享、映射、优化）。

4.1 第一层：内存扩展——解决"物理内存不足"

这是虚拟内存被发明的最初动机。

场景：物理内存 512MB，三个程序各需 256MB 没有虚拟内存： ├── 三个程序共需 768MB ├── 物理内存仅有 512MB └── 第三个程序无法运行 引入虚拟内存后： ├── 每个进程拥有独立的虚拟地址空间 ├── 操作系统仅将当前活跃的页面保留在物理内存中 ├── 暂时不活跃的页面被换出到磁盘交换空间 ├── 当被换出的页面再次被访问时，通过缺页中断重新载入 └── 物理内存与磁盘交换空间共同构成可用存储，满足所有进程的需求

起作用的机制：页表条目的存在位（P）+ 缺页中断 + 页面置换算法。

4.2 第二层：独立编址——解决"多程序地址冲突"

内存容量问题解决之后，下一个障碍是：多个程序如何共存于同一台机器而不产生地址冲突。

没有虚拟内存： ├── 编译器生成代码时，函数入口地址固定为 0x00401000 ├── 两个程序都按此地址编译 ├── 加载到内存时必须对其中一个进行地址重定位 └── 过程复杂、容易出错、运行时开销大 引入虚拟内存后： ├── 每个进程拥有独立的页表 ├── 进程 A 的 0x00401000 通过 A 的页表映射到物理页 100 ├── 进程 B 的 0x00401000 通过 B 的页表映射到物理页 200 ├── 相同的虚拟地址指向不同的物理位置 └── 编译器无需考虑其他程序的存在，始终使用固定的地址布局

起作用的机制：每个进程维护独立的页表。CPU 通过 CR3 寄存器（x86 架构）在进程切换时指向当前进程的页表。

4.3 第三层：内存保护——解决"一个程序崩溃拖垮整个系统"

地址不再冲突之后，还需要防止程序因自身缺陷破坏系统或其他程序。

进程 A 执行了一条错误指令： MOV [0xCCCCCCCC], EAX ; 向一个随机地址写入数据 地址翻译过程： ├── MMU 查询进程 A 的页表 ├── 0xCCCCCCCC 对应的页表条目不存在，或权限位标记为不可写 ├── MMU 触发保护异常（Protection Fault） ├── 操作系统捕获该异常 ├── 仅终止进程 A │ （Windows 报告 Access Violation，Linux 发送 SIGSEGV） └── 其他进程与操作系统内核不受任何影响 若没有页表保护： ├── 0xCCCCCCCC 被视为物理地址，直接写入 ├── 该地址可能存放着内核代码或其他程序的数据 └── 轻则数据损坏，重则整台计算机崩溃

内存保护的另一个重要体现是内核空间与用户空间的隔离。每个进程的虚拟地址空间分为两部分：

以 32 位 Linux 为例： ┌─────────────────────┐ 0xFFFFFFFF │ 内核空间（1GB） │ ← 页表条目 U/S = 0（仅内核态可访问） ├─────────────────────┤ 0xC0000000 │ 用户空间（3GB） │ ← 页表条目 U/S = 1（用户态可访问） └─────────────────────┘ 0x00000000 所有进程的内核空间映射到相同的物理内存区域， 使得系统调用时无需切换页表。 用户态代码若尝试访问内核空间地址， 页表的用户位（U/S = 0）将触发保护异常。

起作用的机制：页表条目的读写位（R/W）与用户位（U/S）。

4.4 第四层：安全隔离——解决"进程间数据泄露"

保护机制确保了程序不会因错误而破坏他人。但如果一个程序故意尝试读取另一个程序的数据，结果会如何？

进程 A 试图窥探进程 B 的内存： 进程 A 遍历自己的整个虚拟地址空间： ├── 0x00000000 → A 自己的数据，或未映射 ├── 0x00001000 → A 自己的数据，或未映射 ├── ... └── 0xFFFFFFFF → A 自己的数据，或未映射 结论：A 的页表中不存在任何一条映射指向 B 的物理页框。 这不是"禁止访问"，而是"在 A 的地址空间中，B 的数据根本不存在"。

在此基础上，现代操作系统进一步引入了ASLR（Address Space Layout Randomization，地址空间布局随机化）：

每次程序启动时，操作系统随机化其虚拟地址空间的布局： ├── 第一次运行：代码段从 0x7f4a2000 开始 ├── 第二次运行：代码段从 0x7f1b8000 开始 ├── 攻击者无法预测目标数据或函数的地址 └── 即使存在缓冲区溢出漏洞，利用难度也大幅提高 这一机制的前提正是虚拟内存： 虚拟地址可以任意编排，而物理地址的实际位置由页表决定。

需要指出的是，虚拟内存提供的是默认隔离，而非绝对隔离。操作系统仍然提供了受控的跨进程内存访问接口：

Windows：ReadProcessMemory / WriteProcessMemory Linux： /proc/<pid>/mem、ptrace 系统调用 这些接口需要足够的权限（如调试权限）， 且操作系统可对其施加审计与限制。 虚拟内存的意义在于：隔离是默认状态， 共享和跨进程访问是需要显式授权的例外。

起作用的机制：页表隔离（每个进程的页表互相独立）+ 虚拟地址与物理地址的解耦。

4.5 第五层：扩展应用——共享、映射与优化

前四层依次解决了容量、编址、保护与安全问题，总体方向是让进程独立运行、互不干扰。但在某些场景下，进程之间需要共享数据，或者需要高效地访问磁盘文件。页表机制同样能够支持这些需求——通过灵活控制映射关系，在隔离的基础上实现受控的共享与优化。

4.5.1 共享内存——高效的进程间通信

操作系统将同一物理页框同时映射到两个进程的页表中： 进程 A 的页表：虚拟页 10 → 物理页 50 进程 B 的页表：虚拟页 20 → 物理页 50 ↑ 同一个物理页框 效果： ├── A 写入数据后，B 立即可见 ├── 无需数据拷贝，通信效率最高 └── 动态链接库（DLL / .so）的代码段也采用此方式： 多个进程共享同一份物理副本，节省物理内存

4.5.2 内存映射文件——统一内存与文件的访问方式

// 将文件映射到进程的虚拟地址空间void*ptr=mmap(NULL,fileSize,PROT_READ,MAP_PRIVATE,fd,0);// 像访问内存一样读取文件内容charfirstByte=((char*)ptr)[0];

其背后的机制与内存扩展完全相同： ├── 操作系统在页表中建立映射：虚拟页 → 文件在磁盘上的对应位置 ├── 首次访问时触发缺页中断 ├── 操作系统从文件中读取对应的页到物理内存 ├── 更新页表条目，后续访问直接命中物理内存 └── 对程序而言，文件内容与普通内存无异

4.5.3 写时复制（Copy-on-Write）——fork 的性能保障

Linux 中 fork() 系统调用创建子进程： 朴素做法：完整复制父进程的全部内存 → 耗时且浪费 实际做法（利用页表的写权限位）： 1. 子进程获得一份父进程页表的副本 （指向相同的物理页框） 2. 所有共享页的页表条目标记为"只读" 3. 此时父子进程共享全部物理页 → fork 操作近乎瞬间完成 4. 当任意一方尝试写入某一页时： → 写操作触发保护异常（因页面标记为只读） → 操作系统此时才分配新的物理页框 → 复制原页面内容到新页框 → 更新写入方的页表条目，指向新页框并恢复可写权限 → 仅复制被实际修改的页面，其余页面继续共享

4.5.4 懒加载（Demand Paging）——按需分配物理资源

当程序申请大块内存时（如 malloc 分配 1GB）： 朴素做法：立即分配 1GB 物理内存 → 浪费 实际做法（利用页表的存在位）： 1. 操作系统仅在页表中建立映射条目 2. 但不立即分配物理页框（页表存在位 P = 0） 3. 此时物理内存零消耗 4. 当程序首次访问该地址范围中的某一页时： → 触发缺页中断 → 操作系统此时才分配物理页框 → 更新页表条目（P = 1，填入物理页框号） → 重新执行触发缺页的指令 效果：程序申请 1GB 内存但仅访问其中 10MB， 则实际仅消耗 10MB 物理内存。 起作用的机制与内存扩展相同（存在位 + 缺页中断）， 但目的不同：前者是"物理内存不足，借用磁盘"， 后者是"物理内存充足，但延迟分配以避免浪费"。

这一机制正是第 3.3 节所述"虚拟地址空间大小与物理内存消耗相互独立"的底层保障之一。

五、工程实现：多级页表与 TLB

前文阐述了页表在功能层面解决的问题。然而在工程实现中，页表本身也面临挑战：如果为整个虚拟地址空间的每一页都分配一个页表条目，页表本身将消耗大量内存。

5.1 问题：单级页表的空间开销

以 32 位系统为例： 虚拟地址空间 4GB ÷ 页大小 4KB = 1,048,576 个页表条目 每个条目 4 字节 → 单个进程的页表 = 4MB 若系统同时运行 100 个进程： 仅页表本身便占用 400MB 物理内存 而实际上，绝大多数进程不会使用完整的 4GB 虚拟地址空间， 大量页表条目为空，造成严重浪费。

5.2 解决方案：多级页表

多级页表的核心思想是：按需分配页表结构，未使用的地址范围不创建下级页表。

二级页表（32 位 x86 架构实际采用的方案）： ┌──────────────────┐ │ 页目录（4KB） │ ← 1024 个条目 │ ┌────────────┐ │ │ │ 条目 0 ─────┼──┼──→ 页表 0（4KB）→ 映射 1024 个页 │ │ 条目 1 ─────┼──┼──→ 页表 1（4KB）→ 映射 1024 个页 │ │ 条目 2: 空 │ │ 无需分配二级页表 ← 节省内存 │ │ ... │ │ │ │ 条目 1023 │ │ │ └────────────┘ │ └──────────────────┘ 一个仅使用少量内存的进程： 所需空间 = 页目录 (4KB) + 少数几张页表 (若干 × 4KB) ≈ 数十 KB 远小于单级页表的固定 4MB 开销。

64 位系统（x86-64 架构）将页表扩展为四级结构，以支撑 48 位有效虚拟地址（256TB 可寻址空间）：

PML4 → PDPT → PD → PT → 物理页框 虚拟地址结构（48 位有效）： ┌────────┬────────┬────────┬────────┬──────────┐ │ PML4 │ PDPT │ PD │ PT │ 页内偏移 │ │ 9 位 │ 9 位 │ 9 位 │ 9 位 │ 12 位 │ └────────┴────────┴────────┴────────┴──────────┘

多级页表的引入，正是第 3.3 节所述结论的另一层保障：一个进程即使拥有 128TB 的虚拟地址空间，若仅使用其中极小的一部分，其页表结构本身也只占用极少的物理内存。

5.3 TLB：页表的硬件缓存

多级页表节省了空间，但每次地址翻译都需要逐级查询，带来显著的时间开销。TLB 正是为解决这一矛盾而设计的：

┌───────────────────────────────────────────────────┐ │ CPU 访问虚拟地址 0x00401234 │ │ │ │ 第 1 步：查询 TLB（片上高速缓存） │ │ ├── 命中 → 直接获得物理地址，仅需数个时钟周期 │ │ └── 未命中 → 遍历多级页表，需要数十个时钟周期 │ │ │ │ 由于程序访问内存具有局部性（同一页面会被反复访问）， │ │ TLB 的命中率通常在 99% 以上。 │ │ 多级页表带来的性能开销在实际运行中几乎可以忽略。 │ └───────────────────────────────────────────────────┘

六、全景架构

以下架构图展示了虚拟内存系统从应用层到硬件层的完整工作流程，以及各层之间的交互关系：

┌──────────────────────────────────────────────────────────────┐ │ 应 用 层 │ │ │ │ 进程 A 进程 B 进程 C │ │ 独立虚拟地址空间 独立虚拟地址空间 独立虚拟地址空间 │ │ 0 ~ 128TB 0 ~ 128TB 0 ~ 128TB │ │ （每个进程认为自己独占完整的地址空间） │ └──────┬──────────────────┬──────────────────┬─────────────────┘ │ │ │ ▼ ▼ ▼ ┌──────────────────────────────────────────────────────────────┐ │ 操 作 系 统 内 核 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ A 的页表 │ │ B 的页表 │ │ C 的页表 │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ └────────┬────────┴────────┬─────────┘ │ │ │ │ │ │ ┌────────┴────────┐ ┌────┴──────────────┐ │ │ │ 缺页中断处理 │ │ 页面置换算法 │ │ │ │ │ │ (LRU / Clock) │ │ │ └─────────────────┘ └──────────────────┘ │ │ │ │ CR3 寄存器：指向当前运行进程的顶级页表 │ │ 进程切换时，操作系统更新 CR3，完成地址空间切换 │ └───────────────────────────┬──────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ 硬 件 层 │ │ │ │ ┌──────────────────────────────────────┐ │ │ │ MMU + TLB │ ← CPU 内部 │ │ │ 虚拟地址 → 查 TLB → 命中则直接翻译 │ │ │ │ → 未命中则查页表 │ │ │ └──────────────────────────────────────┘ │ │ │ │ │ ┌────────────┴────────────┐ │ │ ▼ ▼ │ │ ┌──────────────────┐ ┌───────────────────────┐ │ │ │ 物理内存（DDR） │ │ 磁盘交换空间 │ │ │ │ 访问延迟：纳秒级 │ │ （pagefile / swap） │ │ │ │ │ │ 访问延迟：毫秒级 │ │ │ └──────────────────┘ └───────────────────────┘ │ └──────────────────────────────────────────────────────────────┘

七、代价与权衡

虚拟内存并非没有代价。任何抽象层的引入都意味着额外的开销：

八、总结

下表汇总了虚拟内存系统解决的各类问题及其对应的页表机制：

虚拟内存系统的价值在于：它并非为解决某一个具体问题而设计，而是通过在程序与物理内存之间引入一层映射关系——页表，使得多个看似无关的问题同时得到解决。存在位支撑了内存扩展与懒加载，读写位实现了保护与写时复制，用户位隔离了内核与用户空间，访问位与脏位优化了页面置换效率。一个页表条目中的每一个比特位各自承担不同的职责，却共同构成了一个完整而自洽的体系。

从 1961 年 Atlas 计算机的首次实现，到 32 位时代的 4GB 地址空间，再到 64 位架构下 256TB 的寻址能力，虚拟内存系统的具体参数在不断演进，但其核心设计始终未变：在程序与物理世界之间建立一张映射表，让每个进程在独立的地址空间中运行，而操作系统在背后统一管理物理资源的分配、保护与调度。