OS丨内存管理 | 莫承潜的博客

type

Post

status

Published

date

Oct 12, 2025

slug

os3

summary

一、虚拟内存：一次优雅的“欺骗”

早期的计算机中，程序是直接操作物理内存的。这种简单粗暴的方式带来了两个致命痛点：

缺乏隔离（不安全）： 进程 A 的一个野指针，可能会不小心写到进程 B 的内存里，导致系统全盘崩溃。

容量焦虑（难扩容）： 物理内存是极其有限的，如果系统只有 4GB 内存，怎么运行一个需要 8GB 内存的大型游戏？

为了解决这两个问题，操作系统引入了虚拟内存（Virtual Memory）机制。

虚拟内存本质上是操作系统为每个进程画的一张“大饼”。它让每个进程都产生一种错觉：“我独占了整台机器的庞大连续内存”。

解决隔离痛点： 进程只能操作自己的虚拟地址，由底层的 MMU（内存管理单元）负责将其翻译成物理地址。不同进程的虚拟地址可以相同，但最终映射的物理地址是绝对隔离的。

解决扩容痛点： 操作系统可以将暂时不用的内存数据置换到硬盘（Swap 区）上，从而在逻辑上突破了物理内存的容量限制。

二、内存映射：分页与多级页表的艺术

既然有了虚拟内存，就必然需要一个“翻译官”将虚拟地址转换为物理地址，这就引出了分段（Segmentation）与分页（Paging）。

1. 分段与分页的区别

分段是按照程序的逻辑语义（如代码段、数据段、堆栈段）进行划分。它的缺点是极易产生外部碎片，导致内存利用率低下。

分页则是将虚拟内存和物理内存切分成固定大小的块（通常为 4KB，称为“页”）。因为大小固定，它完美消除了外部碎片。现代操作系统几乎全都采用了分页机制，或者段页式机制。

2. 为什么需要“多级页表”？

这是一个极高频的连环追问点。

假设在 32 位系统中，页大小为 4KB。那么虚拟内存被分为 $2^{20}$（约 100 万）个页。如果每个页表项占用 4 字节，那么仅仅为了存这张页表，每个进程就需要 $100万 \times 4B = 4MB$ 的连续物理内存。100 个进程就是 400MB，这在早期系统是不可接受的。

多级页表的精髓在于“按需分配”与“空间局部性”。

绝大多数进程其实只用了很少一部分内存。在多级页表结构中，如果某个顶级页目录项为空（代表这一大段虚拟地址完全没被使用），那么它根本不需要为下一级页表分配物理内存。通过这种层级结构的巧妙设计，操作系统极大节省了页表本身占用的空间。

三、缺页中断 (Page Fault)：虚拟与现实的交接

当 CPU 访问一个虚拟地址，但这个地址所在的页并没有被加载到物理内存中时，就会发生操作系统中最经典的异常：缺页中断。

面试中如果问到这个过程，请务必清晰地答出以下步骤：

触发异常： CPU 查页表发现该页的 Valid（有效位）为 0，触发 Page Fault，并陷入内核态。

定位数据： 操作系统内核接管，根据页表项中记录的磁盘地址，找到该页面在磁盘（Swap）中的具体位置。

寻找空闲帧： 操作系统在物理内存中寻找一个空闲的页框。

磁盘 I/O： 发起磁盘 I/O 请求，将磁盘上的页面数据读入刚刚找到的物理页框中。由于磁盘很慢，这个过程会让当前进程挂起，CPU 切换去执行其他进程。

更新页表： I/O 完成后，操作系统更新页表，将该页的物理内存地址写入页表项，并将有效位置为 1。

恢复执行： 恢复进程上下文，重新执行刚才那条触发中断的机器指令。这一次，MMU 就能成功命中物理内存了。

四、内存淘汰与手写 LRU 算法

在缺页中断的第 3 步，如果物理内存满了，操作系统必须“踢掉”一个现有的页。谁该被踢？这就是内存淘汰策略。

常见的有 FIFO（先进先出，性能差）和 OPT（最佳替换，需要预知未来，无法实现）。而在工程实践中，最常使用的是 LRU（Least Recently Used，最近最少使用）。

LRU 的核心理念是：如果一个数据在最近一段时间没有被访问到，那么在将来它被访问的可能性也很小。

Python 优雅手撕 LRU

在面试中，这几乎是必考的代码题。为了满足 O(1) 的查询和 O(1) 的插入/删除，我们必须使用「哈希表 + 双向链表」的经典组合。

下面是我平时沉淀的一套 Python 3 实现模板，建议在理解的基础上掌握：

结语

从硬件层面的 MMU，到操作系统内核层的页表管理与缺页中断，再到应用层算法手写 LRU，内存管理贯穿了整个计算机科学体系。理解这些底层机制，不仅仅是为了在面试中对答如流，更是为了在未来面对 OOM（Out Of Memory）、系统卡顿或高并发调优时，能够拥有降维打击般的排查视野。

一、 虚拟内存：一次优雅的“欺骗”

二、 内存映射：分页与多级页表的艺术