虚拟内存操作系统最精妙的设计——从分页机制到页面替换算法的完整拆解虚拟内存不是「用硬盘冒充内存」那么简单。它是现代操作系统最重要的抽象层——让每个进程以为独占整台机器让操作系统在 64KB 到 64GB 之间无缝伸缩。一、没有虚拟内存的世界是什么样假设你回到 1980 年代用 MS-DOS 写程序。你的程序直接操作物理地址// 假想的裸机代码char*video_memory(char*)0xB8000;// VGA 显存的物理地址*video_memoryA;// 直接在屏幕上写字符这带来了三个致命问题问题 1地址冲突。你写了一个程序假设自己能占用 0x1000 到 0x5000。另一个程序也假设自己能占用这个范围。两个程序怎么同时运行不可能——它们会互相覆盖。问题 2内存碎片。经过多次加载和卸载物理内存会变成这样[程序A: 4MB] [空闲: 2MB] [程序B: 8MB] [空闲: 6MB] [程序C: 3MB]总空闲 2 6 8MB但如果你要加载一个 5MB 的程序——装不下因为空闲内存不连续。问题 3安全性。程序 A 可以读写程序 B 的内存。一个恶意程序可以偷走你的密码。虚拟内存就是用来解决这三个问题的。二、虚拟内存的三层抽象2.1 第一层地址空间隔离虚拟内存的核心思想每个进程看到的不再是物理地址而是一个「虚拟地址空间」——从 0 开始连续独占。进程 A 眼中的世界 进程 B 眼中的世界 ┌─────────────┐ 0 ┌─────────────┐ 0 │ 代码段 │ │ 代码段 │ ├─────────────┤ 4KB ├─────────────┤ 4KB │ 数据段 │ │ 数据段 │ ├─────────────┤ 8KB ├─────────────┤ 8KB │ 堆 │ │ 堆 │ │ ↓ │ │ ↓ │ │ │ │ │ │ ↑ │ │ ↑ │ │ 栈 │ │ 栈 │ └─────────────┘ 4GB └─────────────┘ 4GB 实际物理内存 ┌──────┬──────┬──────┬──────┬──────────────┐ │ A代码 │ B代码 │ A堆 │ B数据 │ 空闲 │ └──────┴──────┴──────┴──────┴──────────────┘进程 A 以为自己独占 4GB 连续空间进程 B 也以为自己独占 4GB。实际上它们被打散在物理内存的各个角落。虚拟地址 → 物理地址的映射由 CPU 操作系统协作完成进程无感知。2.2 第二层分页——把连续变成稀疏不要把所有虚拟地址一次性映射到物理内存——只映射真正用到的部分。虚拟地址空间大 物理内存小 ┌──────────┐ ┌──────────┐ │ 代码页 │───────────────────────→│ 代码页 │ ├──────────┤ ├──────────┤ │ 数据页 │───────────────────────→│ 数据页 │ ├──────────┤ ├──────────┤ │ 堆 页1 │───────────────────────→│ 堆 页1 │ ├──────────┤ ✗ 未映射 ├──────────┤ │ 堆 页2 │──── 没用到 │ 空闲 │ ├──────────┤ ├──────────┤ │ 栈 页 │───────────────────────→│ 栈 页 │ └──────────┘ └──────────┘映射的单位是页page通常是 4KB。一个 4GB 的地址空间有 100 万个页但一个普通进程实际只用到其中的几百到几千页。2.3 第三层交换——当物理内存不够时如果所有进程加起来需要的物理内存超过了实际内存操作系统可以把一些不常用的页临时写到硬盘上swap把物理内存腾出来给更需要的进程。这就是大家常说的「虚拟内存 内存 硬盘」——但这只是虚拟内存的一个子功能交换不是全部。三、页表虚拟到物理的翻译官3.1 你写int x 5时发生了什么int*pmalloc(sizeof(int));// 返回 0x7fff1234这是个虚拟地址*p5;// CPU 要把 5 写到这个地址CPU 拿到0x7fff1234它不能直接去物理内存找——物理内存里根本没有「0x7fff1234」这个位置。CPU 需要先查页表找到这个虚拟地址对应的物理地址。虚拟地址 0x7fff1234 的翻译过程 虚拟地址 0x 7fff 1234 │ │ VPN虚拟页号 offset页内偏移 │ ▼ ┌─────────┐ │ 页表 │ │ VPN → PFN │ └────┬────┘ │ ▼ 物理地址 PFN物理页帧号 offset3.2 多级页表解决页表太大的问题一个 4GB 的地址空间如果每个页表项 4 字节4KB 一页总共有 100 万个页。如果用一个平坦的页表页表大小 4 字节 × 100 万 4MB每个进程100 个进程就要 400MB 内存只存放页表——这是不可接受的。解决方案多级页表。x86-64 使用四级页表虚拟地址48-bit ┌──────┬──────┬──────┬──────┬──────────┐ │PML4(9)│PDPT(9)│PD(9) │PT(9) │offset(12)│ └──────┴──────┴──────┴──────┴──────────┘ 查表过程 PML4 ──→ PDPT ──→ PD ──→ PT ──→ 物理页 offset省在哪一个进程不会用完整个 256TB 的地址空间。未使用的部分……根本不分配页表。大部分进程实际只需要 PML4 的少数几个表项整条表链的大部分节点都是空的。3.3 TLB翻译加速缓存查四级页表太慢了——每次内存访问要额外做四次内存读取查四次表才能拿到真正的数据。这相当于每次内存访问慢了 4 倍。CPU 内部有一个专门的缓存TLBTranslation Lookaside Buffer地址转换后备缓冲器。它缓存最近的翻译结果CPU 内存 ┌──────────┐ ┌──────┐ │ TLB │ │ 页表 │ │ VPN→PFN │ TLB miss │ │ │ 缓存 │◄──────────────│ │ │ (几十条) │ 才去查 │ │ └──────────┘ └──────┘TLB 命中率通常在 99% 以上。这意味着绝大多数内存访问只需要一次 TLB 查找不需要查完整的四级页表。四、页面替换算法物理内存满了怎么办当需要加载新页面但物理内存已满时操作系统必须选择一个页面踢出去可能写到 swap。选哪个这就是页面替换算法要解决的问题。4.1 最优算法OPTBelady 最优算法——也不可能实现的理论最优策略踢掉将来最远才被使用的页面。这是理论上最优的方案缺页次数最少但无法实现——你无法预知未来哪个页面会先被用到。它的价值在于给其他算法提供一个对比基准。4.2 FIFO——简单但有致命缺陷策略谁先来的先踢谁。页面访问序列1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5 物理页帧数3 初始[1] [2] [3] 缺页 3 次 访问4[4] [2] [3] 踢 1缺页 1 次 访问1[4] [1] [3] 踢 2缺页 1 次 访问2[4] [1] [2] 踢 3缺页 1 次 访问5[5] [1] [2] 踢 4缺页 1 次 ...Belady 异常FIFO 有一个著名的反直觉现象——增加物理页帧数反而可能增加缺页次数。这不是 bug是 FIFO 算法本身的性质。4.3 LRU最近最少使用——实际中最好的近似策略踢掉最长时间没有被访问的页面。直觉如果一个页面过去很久没被用过那它将来也不太可能马上被用到局部性原理。页面访问序列1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5 物理页帧数3 初始[1] [2] [3] 缺页 3 次 访问4[4] [2] [3] 踢 1最久未用缺页 1 访问1[4] [1] [3] 踢 2缺页 1 访问2[4] [1] [2] 踢 3缺页 1 访问5[5] [1] [2] 踢 4缺页 1 访问1[5] [1] [2] 命中 访问2[5] [1] [2] 命中 访问3[5] [3] [2] 踢 1缺页 1 访问4[4] [3] [2] 踢 5缺页 1 访问5[4] [3] [5] 踢 2缺页 1 总缺页10 次FIFO 相同序列约 12 次LRU 的问题实现成本高。每次内存访问都要更新「最近使用时间」——要么用硬件支持的访问位要么每次访问都产生一次时间戳写入。对于高频访问的页面这个开销不可接受。4.4 Clock 算法第二次机会——Linux 的实际选择Linux 使用 Clock 算法的变体基于 LRU 的近似。核心思想用一个**访问位reference bit**代替 LRU 的精确时间戳。循环链表Clock ┌──┐ ┌─┤B │ ref1 │ └──┘ ┌──┐ │ │A │◄─┘ │ref0│ └──┘ │ ┌──▼┐ │C │ ref1 └──┘ ...Clock 指针在循环链表上移动查看当前指向的页面如果ref0踢掉它如果ref1把ref清零给第二次机会指针移到下一个这相当于 LRU 的近似最近被访问过的ref1不会被踢长时间没被访问的ref 被清零后没再设回 1被踢掉。开销极小——只需要一个 bit。4.5 Linux 的实际做法双链表 LRULinux 使用两个 LRU 链表Active List活跃链表 Inactive List不活跃链表 ┌──┬──┬──┬──┐ ┌──┬──┬──┬──┐ │A │B │C │D │ ← 经常访问 │E │F │G │H │ ← 不常访问 └──┴──┴──┴──┘ └──┴──┴──┴──┘ ↑ ↓ ↑ ↓ └────┴────────── 晋升 ──────────┘ │ ┌────┴────────── 降级 ───────────────┘页面首次加载进入Inactive list。如果在 Inactive list 中被第二次访问晋升到Active list。内存紧张时优先从Inactive list的尾部回收页面。这套机制通过kswapd内核线程在后台持续运行不需要等到内存完全耗尽才回收。五、缺页中断当虚拟地址没有对应的物理页5.1 缺页的三种情况当 CPU 访问一个虚拟地址发现页表里没有对应的物理页帧PTE 的 present 位为 0触发缺页中断page fault。操作系统此时有三种处理情况原因处理小缺页minor fault页面在物理内存中但未映射到当前进程的页表比如共享库建立页表映射极快大缺页major fault页面不在物理内存中需要从磁盘加载从文件或 swap 读取慢ms 级段错误segfault访问了无效地址未分配、越界发送 SIGSEGV进程终止5.2 mmap 和缺页的配合——惰性分配当你调用mmap()分配大量内存时操作系统并不立即分配物理页// 分配 1GB 内存——但此时不分配任何物理页void*ptrmmap(NULL,1UL30,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);// 第一次访问时才触发缺页中断分配物理页// 1GB 空间里你只用了 10MB → 只分配了 10MB 物理内存((char*)ptr)[0]A;这是操作系统最精妙的设计之一惰性分配lazy allocation。你声明 1GB系统说「好」但其实什么都没分配。只有当你真正触碰那 1GB 中的某个字节才分配对应的物理页。这让你可以在 8GB 内存的机器上跑需要 100GB 地址空间的应用只要实际使用的超过物理内存的部分不多。六、Huge Pages——当 4KB 的页太小了一个现代数据库进程可能有几十 GB 的地址空间。按 4KB 一页算40GB / 4KB 1000 万个页表项 TLB 条目数 约 64-256 条1000 万个页 vs 256 条 TLB → TLB 命中率会急剧下降性能严重受损。解决方案大页Huge Pages。页大小覆盖同样内存需要的页表项4KB普通页1000 万个2MB大页2 万个1GB巨页40 个Linux 支持两种大页机制Transparent Huge Pages (THP)内核自动尝试使用 2MB 页应用无感知。但碎片化可能导致分配失败。Hugetlbfs应用显式申请大页更可控但不是透明的。# 查看大页使用情况grep-ihuge /proc/meminfo# 查看 TLB 大小Intelcpuid-1|grep-itlb七、动手实验# 查看进程的虚拟内存映射cat/proc/self/maps# 查看缺页统计ps-omin_flt,maj_flt,cmd-p$$# 查看某个进程的页表大小cat/proc/pid/status|grep-ivm# 查看 swap 使用swapon--showfree-h八、总结虚拟内存是一个三层抽象地址空间隔离——每个进程活在自己的世界里分页——只映射实际用到的部分交换——物理内存不够时用磁盘当后备支撑这三层抽象的关键机制多级页表——用稀疏的数据结构解决页表膨胀问题TLB——用高速缓存解决翻译性能问题缺页中断 惰性分配——用「声明不等于兑现」节省物理内存页面替换算法——用启发式规则在有限物理内存中做出最优选择Huge Pages——用更大的粒度解决大数据时代的 TLB 瓶颈理解了这套体系你就理解了一个操作系统是如何在「理想无限内存」和「现实有限物理内存」之间搭建起一座让所有应用都满意的桥梁。
虚拟内存与TLB：分页、换页算法深度解析
虚拟内存操作系统最精妙的设计——从分页机制到页面替换算法的完整拆解虚拟内存不是「用硬盘冒充内存」那么简单。它是现代操作系统最重要的抽象层——让每个进程以为独占整台机器让操作系统在 64KB 到 64GB 之间无缝伸缩。一、没有虚拟内存的世界是什么样假设你回到 1980 年代用 MS-DOS 写程序。你的程序直接操作物理地址// 假想的裸机代码char*video_memory(char*)0xB8000;// VGA 显存的物理地址*video_memoryA;// 直接在屏幕上写字符这带来了三个致命问题问题 1地址冲突。你写了一个程序假设自己能占用 0x1000 到 0x5000。另一个程序也假设自己能占用这个范围。两个程序怎么同时运行不可能——它们会互相覆盖。问题 2内存碎片。经过多次加载和卸载物理内存会变成这样[程序A: 4MB] [空闲: 2MB] [程序B: 8MB] [空闲: 6MB] [程序C: 3MB]总空闲 2 6 8MB但如果你要加载一个 5MB 的程序——装不下因为空闲内存不连续。问题 3安全性。程序 A 可以读写程序 B 的内存。一个恶意程序可以偷走你的密码。虚拟内存就是用来解决这三个问题的。二、虚拟内存的三层抽象2.1 第一层地址空间隔离虚拟内存的核心思想每个进程看到的不再是物理地址而是一个「虚拟地址空间」——从 0 开始连续独占。进程 A 眼中的世界 进程 B 眼中的世界 ┌─────────────┐ 0 ┌─────────────┐ 0 │ 代码段 │ │ 代码段 │ ├─────────────┤ 4KB ├─────────────┤ 4KB │ 数据段 │ │ 数据段 │ ├─────────────┤ 8KB ├─────────────┤ 8KB │ 堆 │ │ 堆 │ │ ↓ │ │ ↓ │ │ │ │ │ │ ↑ │ │ ↑ │ │ 栈 │ │ 栈 │ └─────────────┘ 4GB └─────────────┘ 4GB 实际物理内存 ┌──────┬──────┬──────┬──────┬──────────────┐ │ A代码 │ B代码 │ A堆 │ B数据 │ 空闲 │ └──────┴──────┴──────┴──────┴──────────────┘进程 A 以为自己独占 4GB 连续空间进程 B 也以为自己独占 4GB。实际上它们被打散在物理内存的各个角落。虚拟地址 → 物理地址的映射由 CPU 操作系统协作完成进程无感知。2.2 第二层分页——把连续变成稀疏不要把所有虚拟地址一次性映射到物理内存——只映射真正用到的部分。虚拟地址空间大 物理内存小 ┌──────────┐ ┌──────────┐ │ 代码页 │───────────────────────→│ 代码页 │ ├──────────┤ ├──────────┤ │ 数据页 │───────────────────────→│ 数据页 │ ├──────────┤ ├──────────┤ │ 堆 页1 │───────────────────────→│ 堆 页1 │ ├──────────┤ ✗ 未映射 ├──────────┤ │ 堆 页2 │──── 没用到 │ 空闲 │ ├──────────┤ ├──────────┤ │ 栈 页 │───────────────────────→│ 栈 页 │ └──────────┘ └──────────┘映射的单位是页page通常是 4KB。一个 4GB 的地址空间有 100 万个页但一个普通进程实际只用到其中的几百到几千页。2.3 第三层交换——当物理内存不够时如果所有进程加起来需要的物理内存超过了实际内存操作系统可以把一些不常用的页临时写到硬盘上swap把物理内存腾出来给更需要的进程。这就是大家常说的「虚拟内存 内存 硬盘」——但这只是虚拟内存的一个子功能交换不是全部。三、页表虚拟到物理的翻译官3.1 你写int x 5时发生了什么int*pmalloc(sizeof(int));// 返回 0x7fff1234这是个虚拟地址*p5;// CPU 要把 5 写到这个地址CPU 拿到0x7fff1234它不能直接去物理内存找——物理内存里根本没有「0x7fff1234」这个位置。CPU 需要先查页表找到这个虚拟地址对应的物理地址。虚拟地址 0x7fff1234 的翻译过程 虚拟地址 0x 7fff 1234 │ │ VPN虚拟页号 offset页内偏移 │ ▼ ┌─────────┐ │ 页表 │ │ VPN → PFN │ └────┬────┘ │ ▼ 物理地址 PFN物理页帧号 offset3.2 多级页表解决页表太大的问题一个 4GB 的地址空间如果每个页表项 4 字节4KB 一页总共有 100 万个页。如果用一个平坦的页表页表大小 4 字节 × 100 万 4MB每个进程100 个进程就要 400MB 内存只存放页表——这是不可接受的。解决方案多级页表。x86-64 使用四级页表虚拟地址48-bit ┌──────┬──────┬──────┬──────┬──────────┐ │PML4(9)│PDPT(9)│PD(9) │PT(9) │offset(12)│ └──────┴──────┴──────┴──────┴──────────┘ 查表过程 PML4 ──→ PDPT ──→ PD ──→ PT ──→ 物理页 offset省在哪一个进程不会用完整个 256TB 的地址空间。未使用的部分……根本不分配页表。大部分进程实际只需要 PML4 的少数几个表项整条表链的大部分节点都是空的。3.3 TLB翻译加速缓存查四级页表太慢了——每次内存访问要额外做四次内存读取查四次表才能拿到真正的数据。这相当于每次内存访问慢了 4 倍。CPU 内部有一个专门的缓存TLBTranslation Lookaside Buffer地址转换后备缓冲器。它缓存最近的翻译结果CPU 内存 ┌──────────┐ ┌──────┐ │ TLB │ │ 页表 │ │ VPN→PFN │ TLB miss │ │ │ 缓存 │◄──────────────│ │ │ (几十条) │ 才去查 │ │ └──────────┘ └──────┘TLB 命中率通常在 99% 以上。这意味着绝大多数内存访问只需要一次 TLB 查找不需要查完整的四级页表。四、页面替换算法物理内存满了怎么办当需要加载新页面但物理内存已满时操作系统必须选择一个页面踢出去可能写到 swap。选哪个这就是页面替换算法要解决的问题。4.1 最优算法OPTBelady 最优算法——也不可能实现的理论最优策略踢掉将来最远才被使用的页面。这是理论上最优的方案缺页次数最少但无法实现——你无法预知未来哪个页面会先被用到。它的价值在于给其他算法提供一个对比基准。4.2 FIFO——简单但有致命缺陷策略谁先来的先踢谁。页面访问序列1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5 物理页帧数3 初始[1] [2] [3] 缺页 3 次 访问4[4] [2] [3] 踢 1缺页 1 次 访问1[4] [1] [3] 踢 2缺页 1 次 访问2[4] [1] [2] 踢 3缺页 1 次 访问5[5] [1] [2] 踢 4缺页 1 次 ...Belady 异常FIFO 有一个著名的反直觉现象——增加物理页帧数反而可能增加缺页次数。这不是 bug是 FIFO 算法本身的性质。4.3 LRU最近最少使用——实际中最好的近似策略踢掉最长时间没有被访问的页面。直觉如果一个页面过去很久没被用过那它将来也不太可能马上被用到局部性原理。页面访问序列1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5 物理页帧数3 初始[1] [2] [3] 缺页 3 次 访问4[4] [2] [3] 踢 1最久未用缺页 1 访问1[4] [1] [3] 踢 2缺页 1 访问2[4] [1] [2] 踢 3缺页 1 访问5[5] [1] [2] 踢 4缺页 1 访问1[5] [1] [2] 命中 访问2[5] [1] [2] 命中 访问3[5] [3] [2] 踢 1缺页 1 访问4[4] [3] [2] 踢 5缺页 1 访问5[4] [3] [5] 踢 2缺页 1 总缺页10 次FIFO 相同序列约 12 次LRU 的问题实现成本高。每次内存访问都要更新「最近使用时间」——要么用硬件支持的访问位要么每次访问都产生一次时间戳写入。对于高频访问的页面这个开销不可接受。4.4 Clock 算法第二次机会——Linux 的实际选择Linux 使用 Clock 算法的变体基于 LRU 的近似。核心思想用一个**访问位reference bit**代替 LRU 的精确时间戳。循环链表Clock ┌──┐ ┌─┤B │ ref1 │ └──┘ ┌──┐ │ │A │◄─┘ │ref0│ └──┘ │ ┌──▼┐ │C │ ref1 └──┘ ...Clock 指针在循环链表上移动查看当前指向的页面如果ref0踢掉它如果ref1把ref清零给第二次机会指针移到下一个这相当于 LRU 的近似最近被访问过的ref1不会被踢长时间没被访问的ref 被清零后没再设回 1被踢掉。开销极小——只需要一个 bit。4.5 Linux 的实际做法双链表 LRULinux 使用两个 LRU 链表Active List活跃链表 Inactive List不活跃链表 ┌──┬──┬──┬──┐ ┌──┬──┬──┬──┐ │A │B │C │D │ ← 经常访问 │E │F │G │H │ ← 不常访问 └──┴──┴──┴──┘ └──┴──┴──┴──┘ ↑ ↓ ↑ ↓ └────┴────────── 晋升 ──────────┘ │ ┌────┴────────── 降级 ───────────────┘页面首次加载进入Inactive list。如果在 Inactive list 中被第二次访问晋升到Active list。内存紧张时优先从Inactive list的尾部回收页面。这套机制通过kswapd内核线程在后台持续运行不需要等到内存完全耗尽才回收。五、缺页中断当虚拟地址没有对应的物理页5.1 缺页的三种情况当 CPU 访问一个虚拟地址发现页表里没有对应的物理页帧PTE 的 present 位为 0触发缺页中断page fault。操作系统此时有三种处理情况原因处理小缺页minor fault页面在物理内存中但未映射到当前进程的页表比如共享库建立页表映射极快大缺页major fault页面不在物理内存中需要从磁盘加载从文件或 swap 读取慢ms 级段错误segfault访问了无效地址未分配、越界发送 SIGSEGV进程终止5.2 mmap 和缺页的配合——惰性分配当你调用mmap()分配大量内存时操作系统并不立即分配物理页// 分配 1GB 内存——但此时不分配任何物理页void*ptrmmap(NULL,1UL30,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);// 第一次访问时才触发缺页中断分配物理页// 1GB 空间里你只用了 10MB → 只分配了 10MB 物理内存((char*)ptr)[0]A;这是操作系统最精妙的设计之一惰性分配lazy allocation。你声明 1GB系统说「好」但其实什么都没分配。只有当你真正触碰那 1GB 中的某个字节才分配对应的物理页。这让你可以在 8GB 内存的机器上跑需要 100GB 地址空间的应用只要实际使用的超过物理内存的部分不多。六、Huge Pages——当 4KB 的页太小了一个现代数据库进程可能有几十 GB 的地址空间。按 4KB 一页算40GB / 4KB 1000 万个页表项 TLB 条目数 约 64-256 条1000 万个页 vs 256 条 TLB → TLB 命中率会急剧下降性能严重受损。解决方案大页Huge Pages。页大小覆盖同样内存需要的页表项4KB普通页1000 万个2MB大页2 万个1GB巨页40 个Linux 支持两种大页机制Transparent Huge Pages (THP)内核自动尝试使用 2MB 页应用无感知。但碎片化可能导致分配失败。Hugetlbfs应用显式申请大页更可控但不是透明的。# 查看大页使用情况grep-ihuge /proc/meminfo# 查看 TLB 大小Intelcpuid-1|grep-itlb七、动手实验# 查看进程的虚拟内存映射cat/proc/self/maps# 查看缺页统计ps-omin_flt,maj_flt,cmd-p$$# 查看某个进程的页表大小cat/proc/pid/status|grep-ivm# 查看 swap 使用swapon--showfree-h八、总结虚拟内存是一个三层抽象地址空间隔离——每个进程活在自己的世界里分页——只映射实际用到的部分交换——物理内存不够时用磁盘当后备支撑这三层抽象的关键机制多级页表——用稀疏的数据结构解决页表膨胀问题TLB——用高速缓存解决翻译性能问题缺页中断 惰性分配——用「声明不等于兑现」节省物理内存页面替换算法——用启发式规则在有限物理内存中做出最优选择Huge Pages——用更大的粒度解决大数据时代的 TLB 瓶颈理解了这套体系你就理解了一个操作系统是如何在「理想无限内存」和「现实有限物理内存」之间搭建起一座让所有应用都满意的桥梁。
