进程地址空间、页表与写时拷贝：原理拆解与实验验证

聊进程地址空间这件事，我一般不喜欢从教科书上那张"代码段、数据段、堆、栈"的示意图讲起，因为那张图太干净了,干净到看不出真实系统里那些别扭的取舍。我更愿意先抛一个问题：如果一个进程拿到的地址就是物理内存里的真实地址,它敢不敢随便用？答案显然是不敢。它不仅不敢随便用,连"自己该用哪一块"都没法事先知道——因为同一时刻可能有几十上百个进程在跑,谁先来谁后到、谁大谁小,全都不确定。进程地址空间、虚拟地址、页表、写时拷贝这一整套机制,本质上就是给这个混乱场面建立秩序的工具。搞嵌入式的同学可能觉得这些东西离自己很远,但只要你的代码跑在带 MMU 的芯片上、只要你用过fork、只要你的程序莫名其妙涨过内存,这套机制就在你脚下。这篇内容我打算把"地址空间为什么存在""页表怎么把映射做成硬件能查的表""写时拷贝到底省了什么、又偷偷付出了什么"这几件事掰开讲,再配三个能直接跑的验证实验,让你不用只靠想象去理解它们。

1. 先把"地址"这件事说透：虚拟地址空间到底解决了什么问题

1.1 从一段裸机代码说起：物理地址直编的四个坑

在单片机上写程序的时候,我们经常是这么干的：*(volatile uint32_t *)0x40001000 = 1;直接把某个外设寄存器地址写进代码里。这种写法在单任务、无 MMU 的环境下毫无问题,因为整个系统只有一份地址空间,谁也不会跟你抢。但一旦把场景换成多任务操作系统,这种"物理地址直编"的思路立刻会撞上四面墙。

第一面墙是隔离。进程 A 在地址 0x1000 处存了个关键结构体,进程 B 因为指针算错也往 0x1000 写,结果 A 的数据被悄悄改掉,而且这种 bug 极难定位——A 崩溃的时候 B 早就跑完了。第二面墙是重定位。编译器在编译期根本不知道自己的代码会被加载到物理内存的哪个位置,如果按固定地址生成跳转指令,加载位置一变全盘皆输。第三面墙是稀疏使用。一个进程可能只用了 1MB 内存,但它需要一段连续的大地址区间来放栈、放堆,如果按物理地址分配,就得真的预留那么多连续物理页,浪费得离谱。第四面墙是共享与回收。多个进程跑同一个可执行文件,按理说代码段应该只有一份,但物理地址直编的模型下没法表达"两个进程的某段地址指向同一块物理内存"这个概念。

虚拟地址空间就是把这几面墙一次性推倒的方案。每个进程都拥有一份独立的、从 0 开始一直延伸到某个上限的地址空间,进程里所有指针、所有跳转、所有malloc返回的值,都是这个空间里的虚拟地址。真实物理内存在哪里、有多少、是不是连续的,进程完全不需要知道,也完全无法知道。

1.2 虚拟地址空间的本质：一层可编程的映射

我习惯把虚拟地址空间理解成一张"可编程的对照表"。表的左边是虚拟页号,右边是物理页号,中间还挂着几个权限位。CPU 每次访存,MMU 拿虚拟地址去查这张表,查到了就换成物理地址去访问内存,查不到或者权限不对就抛异常。这张表由操作系统维护,进程自己改不了,这就是隔离的物理基础。

这层抽象带来的好处是连锁反应式的。因为映射关系是可编程的,操作系统可以在进程启动时把可执行文件的代码段映射到任意物理页上,于是位置无关加载变成了默认行为。因为映射是页粒度的,一个进程的地址空间里可以有大片"没有映射"的空洞,访问到就触发缺页异常,操作系统再决定是分配一页、还是从磁盘读回来、还是干脆杀掉进程,于是按需分配成为可能。因为映射表里可以记录"这一页是只读的",多个进程可以共享同一块物理内存,谁想写就触发异常,内核再给谁单独复制一份,于是共享库和写时拷贝顺理成章。

我特别想强调一点：虚拟地址空间这套东西之所以能成立,是因为它把"进程看到的世界"和"真实的世界"彻底解耦了。进程以为自己独占了一整块连续的、从 0 开始的内存;内核知道这全是假的,物理页散落在各处,随时可以被换出、被迁移、被共享。这种"谎言"不是欺骗,而是一种极其成功的接口设计——它让上层程序员可以用最简单的心智模型写代码,把复杂性全部压到内核和硬件那一层。

1.3 进程地址空间布局：一张图背后藏着的信息

在 64 位 Linux 上,一个典型进程的虚拟地址空间大致长这样：

这张表里有两个细节是很多人忽略的。第一,堆和映射区是相向生长的。malloc小内存走brk把堆顶往高推,大内存(默认阈值 128KB 左右,由M_MMAP_THRESHOLD控制)走mmap在高地址区找一块空地,两者中间留出巨大空隙,谁先撞上谁触发扩展或失败。第二,代码段和共享库是真正共享物理页的,不是各自复制一份。你在 /proc 的 smaps 里看到共享库的Shared_Clean很大,而Private_Dirty很小,就是这个原因。

还有一个容易误解的点：64 位下用户态可用的虚拟地址并不是完整的 64 位,而是 48 位(4 级页表)或者 57 位(5 级页表,需要显式开启)。低半区属于用户进程,高半区留给内核,中间是一条不可跨越的鸿沟。所以你在 64 位程序里打印指针,看到的基本都是0x0000_7fxx_xxxx_xxxx这样开头的值,不会是0xffff_...。

2. 页表：把映射做成硬件可查表

2.1 为什么是页而不是字节

有人会问：既然要做映射,为什么不做成字节粒度的映射表,一字节虚拟地址对应一字节物理地址？原因很直接——这张表会大到无法存储。假设一个进程有 4GB 虚拟空间,字节粒度映射表每项至少 8 字节,那光映射表就要 32GB,比地址空间本身还大,荒谬。

页粒度是一个甜点。以 4KB 页为例,4GB 地址空间需要 100 万个表项,每项 8 字节,总共 8MB。勉强能接受,但还不够好——因为绝大多数进程根本用不满 4GB,为空洞付 8MB 代价太亏。这就逼出了下一层的优化：分级。而如果选更大的页,比如 2MB,表项数量降到 2048 个,表只有 16KB,但内部碎片会变严重——一个进程只用了 1 字节也得占 2MB。4KB 是历史上软硬件妥协出来的结果,和磁盘扇区、内存颗粒的行缓冲都有关系,至今仍是绝大多数体系结构的默认页大小。

这里有个数值得记住：4KB = 2^12,所以虚拟地址的低 12 位是页内偏移,永远不会被翻译,原样透传到物理地址的低 12 位。这个设计让"翻译"这件事变得极其简单——MMU 只需要处理高位,低位直接抄过去。

2.2 多级页表：用时间换空间的经典取舍

单级页表的问题是,一张表必须连续存放,而它要覆盖整个地址空间。48 位虚拟地址、4KB 页,需要 2^36 个表项,每项 8 字节,单张表就是 512GB。这显然不可能。解决办法是把这张大表切碎、分层,变成一棵树。

x86-64 的 4 级页表是这么切的：把 48 位虚拟地址拆成 5 段,[47:39] [38:30] [29:21] [20:12] [11:0],前四段各 9 位,正好每段能索引 512 个表项;最后 12 位是页内偏移。每张页表页正好 4KB,装 512 个 8 字节表项,大小严丝合缝。

这套设计的精妙之处在于"不为空洞付钱"。一个进程如果只在某个 2MB 区间里用了几页,那么 PML4、PDPT、PD 各需要一张表(各 4KB),PT 也需要一张(4KB),总共 16KB 页表就能支撑起这几页的映射;而地址空间里其他广袤的空白区域,对应的页表页根本不存在,顶级表项直接标记为"未映射"。这就是分级页表用空间效率换来的代价——查表要爬树。

爬树的成本是可以量化的。一次 TLB 未命中,MMU 要依次读 PML4、PDPT、PD、PT 四张表,每读一张都是一次内存访问(这些表都在内存里,只是被硬件缓存加速),最后才拿到物理页号,再去读真正的数据。最坏情况是 5 次内存访问才能拿到一个字节。如果每次都这样,程序会慢到没法用。所以 CPU 里专门放了一个 TLB(Translation Lookaside Buffer),缓存最近用过的"虚拟页号到物理页号"的对应关系。TLB 命中的时候翻译几乎是零成本的,这也是为什么局部性好的程序跑得快——不只是缓存命中率高,页表翻译的缓存命中率也高。

2.3 页表项里到底存了什么

一张页表项是 8 字节,但物理页号只占其中一部分,剩下的位全是标志位。理解这些位,才能理解内核的很多行为。以 x86-64 的 4KB 页表项为例：

我经常拿R/W位来讲写时拷贝,因为它是整套机制里最"四两拨千斤"的一个位。内核在fork之后把所有可写的私有页在父子两个进程的页表里都标成只读,数据本身一个字节都没动;等到某一方真的去写,硬件发现R/W=0,抛出保护异常,内核在异常处理里再决定是复制一页还是恢复可写。整个"复制"动作被推迟到了真正需要的那一刻,而且只复制真正被写的那一页。

A位和D位也有讲究。内核的页面回收算法需要知道"哪些页最近被访问过",硬件每次访问都会把A置 1,内核扫描时读一下、清一下,就能近似判断出页的热度。这不是精确统计,但足够用,而且完全不占用软件开销。这种"让硬件顺手干活"的思路在体系结构里到处都是。

2.4 TLB 与页表遍历的真实开销

很多人学完页表会有个模糊印象："查表很慢,但 TLB 救了它"。这个说法没错,但太笼统。我想给几个更具体的数,便于你判断什么时候该关心它。

TLB 通常分两级：L1 dTLB 只有几十到一百多个条目,覆盖几 MB 到几百 KB;L2 TLB 稍大,几千条,覆盖几 MB 到几十 MB。也就是说,如果一个程序的工作集(活跃页数)小于 L2 TLB 的覆盖范围,翻译开销基本可以忽略;一旦工作集超过这个范围,TLB 开始频繁未命中,每次未命中要爬 4 级页表,性能会掉一个台阶。

这就是大页存在的理由。2MB 大页只需要 PD 层一个表项,不需要 PT 层,一次 TLB 表项就能覆盖 2MB 而不是 4KB,覆盖率提升 512 倍。数据库、JVM 这类吃内存大户经常开透明大页,收益主要就在这里。代价是大页内部的碎片没法回收,内存紧张时反而会拖累系统,所以很多场景又会关掉它。这是一个很典型的"没有银弹"案例。

还有一个常被忽略的成本：切换进程要换页表基址。x86 上页表基址存在 CR3 寄存器里,进程切换时内核写 CR3 指向新进程的 PML4,这个动作会让 TLB 里大部分条目失效(除非用了 PCID 之类的机制给条目打标签)。所以高频的进程切换不仅浪费在保存寄存器上,还浪费在 TLB 冷启动上。这也是为什么线程切换比进程切换便宜——同一地址空间,CR3 不用换。

3. 写时拷贝：fork 性能的一次关键妥协

3.1 fork 为什么要拷贝,又为什么不想拷贝

fork的语义是"创建一个和自己一模一样的子进程",最直白的实现就是把父进程的所有内存逐字节复制一份给子进程。这在小进程上没问题,但一个占了几个 GB 的服务进程 fork 一次,复制几 GB 数据,耗时可能到秒级,期间父进程还得停下来配合。这在早年的 Unix 上就是个大问题。

写时拷贝的思路是：先别复制,让父子共享同一份物理页,把页表里的写权限全部收掉。如果父子俩从此只是读,那就一直共享下去,零成本;如果某一方要写,硬件抛出保护异常,内核在异常里才真正复制那一页,并且只复制被写的那一页。这样,fork的实际开销从"复制全部数据"降级成"复制页表项",通常能快一到两个数量级。

但这里有个被严重低估的事实：页表本身还是要复制的。fork的时候内核要遍历父进程的所有 VMA(虚拟内存区域),为子进程建立同样的 VMA 结构,然后遍历页表,把每一级的表页也复制一份出来——因为父子进程的页表必须各自独立,否则一方改页表项会影响到另一方。对一个映射了几十 GB 内存的进程来说,光是复制页表页就可能要几百 MB 的内存和相当可观的时间。所以"COW 让 fork 变得免费"是个错误认知,更准确的说法是"COW 把 fork 的成本从数据量级降到了页表量级"。

我给个量化的例子。假设一个进程映射了 8GB 匿名内存,页大小 4KB,那么页表项有 200 万个,PT 页有 4000 个,加上各级上层表,页表总大小约 16MB 左右。fork时这 16MB 要被复制,200 万个 PTE 的R/W位要被清掉,这个遍历本身就要几十毫秒。相比之下 8GB 的数据复制要几秒。差了将近两个数量级,但绝对不是零。

3.2 COW 的完整触发链路

想真正吃透 COW,得把从fork到"某一页被复制"的完整链路走一遍。我用 Linux 的实现做参照,其他系统的结构大同小异。

第一步,fork进入内核,走copy_process。这里会创建新的 task 结构、新的 mm 结构(地址空间描述符),然后调用copy_mm。

第二步,copy_mm判断是否共享地址空间。如果是clone带CLONE_VM标志(线程),直接共享 mm,什么都不复制;如果是fork,调用dup_mmap逐条复制 VMA。这一步会把父进程的每个 VMA 用vm_area_dup复制一份,挂到子进程的 mm 上,同时把父子双方的 VMA 都标记为VM_MAYWRITE之类的共享状态,并建立反向映射结构。

第三步,copy_page_range遍历页表。对每一个有效的 PTE,内核把对应物理页的引用计数加一,然后把父子双方的 PTE 的R/W位清零,同时保留PTE_W在软件位里的记录(_PAGE_RW的软件备份,不同内核版本用不同方式记),以便将来恢复。注意,这里改的是父子两份页表,因为页表已经各自独立了。

第四步,某一方执行写操作。CPU 发现目标页的 PTE 里R/W=0,但页是存在的,于是抛出 page fault,错误码里带上"写"和"保护违规"两个标志。

第五步,内核缺页处理。do_page_fault拿到pt_regs和错误码,判断出这是写保护导致的可恢复异常,进入handle_pte_fault分支,再走到do_wp_page。

第六步,do_wp_page做决策。它先看这个物理页当前的引用情况：如果只有当前进程在用(引用计数为 1),说明另一方早就复制走了或者根本没共享,那就直接把 PTE 改回可写,什么都不复制,这叫reuse 优化;如果还有别人在用,就分配一个新页,把旧页内容memcpy过去,新页挂到当前进程的 PTE 上,旧页引用计数减一。

第七步,更新 TLB。页表改了之后,要刷新对应的 TLB 条目,否则 CPU 还会用旧的翻译结果。这一步做漏了就会出现极难排查的数据不一致问题。

这条链路里,do_wp_page的 reuse 判断是关键的性能分水岭。很多场景下父进程 fork 完就exec,子进程立刻换掉整个地址空间,父进程这边根本不会有写冲突;或者 fork 之后只有一方活着,另一方早就退出,页的引用计数掉回 1,后续的写就能直接复用。真正需要复制的情况,往往比想象中少。

3.3 引用计数与页生命周期

COW 能成立,前提是内核精确知道"这一页现在被几个地方引用着"。Linux 用struct page里的_refcount(总引用数,包括页表引用、page cache 引用、内核内部引用)和_mapcount(被多少个用户页表映射)两个字段共同管理。

fork时,每个被共享的可写页的_mapcount加一,_refcount加一。子进程退出时,它映射的每一页都要减回去。触发 COW 复制时,新页的计数从零开始建立,旧页的计数减一。如果减到_mapcount为 1,意味着只剩一个映射者,再写就可以直接复用。

这套计数机制出问题时的表现很有迷惑性。引用计数漏加会导致页被提前释放,表现为随机的内存损坏或者莫名的段错误;引用计数多加会导致页永远回收不掉,表现为内存持续上涨但查不到泄漏点。我见过一个案例,某开发者在驱动里手工改 PTE 实现共享内存,忘了同步加_mapcount,结果系统跑几小时后必然崩,查了两天才定位到。

还有一个容易忽略的点：COW 和文件映射的交互。文件私有映射(MAP_PRIVATE)在被写时也走 COW,但它多一层语义——写完之后这页就变成了匿名页,不再和文件关联,后续的文件修改不会反映过来。这个行为很多人以为是 bug,其实是设计如此。

3.4 COW 不是银弹：坑在哪

写时拷贝用得不当会带来几个典型问题,我在实际项目里都踩过。

第一个坑是"大页 COW"。如果开了透明大页,一个 2MB 的大页被 COW,复制的是整整 2MB 而不是 4KB。一个进程如果频繁 fork 且每次都写一点点,开了大页之后内存占用和复制开销都会暴涨。这种情况要么关掉大页,要么用madvise(MADV_NOHUGEPAGE)在特定区域禁掉。

第二个坑是"内存账算不准"。父子进程共享的页,在各自的 smaps 里都会算进 RSS,于是把父子的 RSS 加起来会远大于实际物理占用。要准确看共享情况,得看Pss(按共享比例分摊)而不是Rss。做容量规划的时候如果只看 RSS,会严重高估。

第三个坑是"fork 之后立刻大改"。有些程序 fork 出子进程后马上在子进程里遍历修改一个大数组,这时候每一页都触发一次 COW,等于把复制成本从 fork 时刻挪到了运行时刻,总成本一点没省,而且还多了几百万次缺页异常的开销。这种场景不如直接vfork加exec,或者用posix_spawn。

第四个坑是"和内存回收打架"。COW 产生的匿名页在内存紧张时会被换出,但父子共享期间页被标成只读,回收路径要特殊处理。极端情况下,内存压力大时 COW 缺页会因为要先回收内存才能分配新页,导致延迟抖动明显。这个在延迟敏感的服务里很致命。

4. 动手验证：把抽象的东西量出来

4.1 环境与工具准备

光看文字容易产生"我懂了"的错觉,所以我建议你亲手跑一遍下面的实验。环境要求很简单：一台 64 位 Linux,装了 gcc,有 root 权限(读 pagemap 需要),内核版本 4.x 以上。

核心工具就三个：/proc/self/pagemap用来查虚拟页对应的物理页号;/proc/self/maps看虚拟地址区间;/proc/self/smaps看每个区间的详细内存账。pagemap 的格式是一个大文件,每 8 字节对应一个虚拟页,文件偏移 = 虚拟页号 × 8。表项里 bit 63 是"页是否存在",bit 0-54 是物理页号。注意从 4.x 某个版本开始,非特权用户读到的物理页号字段会被清零,所以必须用 root 跑。

4.2 实验一：同一虚拟地址在不同进程指向不同物理页

这个实验要验证的核心事实是：fork 之后父子进程打印出来的指针值完全一样,但通过 COW 之后它们指向的物理页不一样了。

#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/mman.h> #include <sys/wait.h> static unsigned long long pfn_of(void *addr) { unsigned long long entry = 0; int fd = open("/proc/self/pagemap", O_RDONLY); if (fd < 0) { perror("open pagemap"); return 0; } off_t off = (off_t)(((unsigned long)addr >> 12) * 8); if (pread(fd, &entry, sizeof(entry), off) != sizeof(entry)) { close(fd); return 0; } close(fd); if (!(entry & (1ULL << 63))) /* 页不在内存 */ return 0; return entry & ((1ULL << 55) - 1); } int main(void) { size_t page = (size_t)sysconf(_SC_PAGESIZE); int *p = mmap(NULL, page, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (p == MAP_FAILED) { perror("mmap"); return 1; } *p = 0x1234; printf("parent pid=%-6d va=%p pfn=%-8llu val=0x%x\n", getpid(), (void *)p, pfn_of(p), *p); pid_t pid = fork(); if (pid < 0) { perror("fork"); return 1; } if (pid == 0) { printf("child pid=%-6d va=%p pfn=%-8llu val=0x%x\n", getpid(), (void *)p, pfn_of(p), *p); *p = 0x5678; /* 触发 COW */ printf("child after-write va=%p pfn=%-8llu val=0x%x\n", (void *)p, pfn_of(p), *p); _exit(0); } waitpid(pid, NULL, 0); printf("parent after-child va=%p pfn=%-8llu val=0x%x\n", (void *)p, pfn_of(p), *p); return 0; }

编译和运行：

gcc -O0 -g -o cow_demo cow_demo.c sudo ./cow_demo

我用-O0是为了防止编译器把*p的读写优化掉。跑出来的结果应该长这样(具体页号每次不同)：

parent pid=12001 va=0x7f3a2c000000 pfn=284117 val=0x1234 child pid=12002 va=0x7f3a2c000000 pfn=284117 val=0x1234 child after-write va=0x7f3a2c000000 pfn=631842 val=0x5678 parent after-child va=0x7f3a2c000000 pfn=284117 val=0x1234

三个关键结论全在这几行里。虚拟地址完全一致,父子俩都以为自己用的是0x7f3a2c000000。fork 刚完成时物理页号也一致,说明数据确实没被复制。子进程写完之后物理页号变了,父进程的没变,而且父进程读到的值还是0x1234,说明 COW 只复制了被写的那一页,没有影响另一方。这个结果和原理对得上,你才算真的理解了。

这个实验我建议你多跑几次,把pfn_of换成查多个页,比如一次性 mmap 1MB(256 页),子进程只写第 0 页和第 100 页,看看有多少页的物理号变了。你会发现只有那两页变了,其余全部保持共享。这个"惰性复制"的直观感受,比读十遍文档都管用。

4.3 实验二：用 smaps 观察共享与私有内存的变化

pagemap 需要 root,在没有 root 的环境里可以用 smaps 观察同样的现象。思路是：fork 前记录父进程某段匿名映射的Rss和Pss,fork 后子进程写一遍,再回到父进程看这些数值怎么变。

# 在父进程里执行,先看初始状态 grep -A 25 "/dev/zero (deleted)\|\[anon\]" /proc/self/smaps | head -40

更实用的是写个小脚本,直接对某个 PID 汇总：

pid=$1 awk ' /^[0-9a-f]+-[0-9a-f]+ / { name = $0 } /^Rss:/ { rss += $2 } /^Pss:/ { pss += $2 } /^Shared_Clean:/ { sc += $2 } /^Shared_Dirty:/ { sd += $2 } /^Private_Clean:/{ pc += $2 } /^Private_Dirty:/{ pd += $2 } END { printf "Rss=%d kB Pss=%d kB\n", rss, pss printf "Shared_Clean=%d Shared_Dirty=%d\n", sc, sd printf "Private_Clean=%d Private_Dirty=%d\n", pc, pd }' /proc/$pid/smaps

关键看点在于Pss和Rss的差异。Rss是"这段区间有多少页在内存里",共享页会被每个进程各算一次;Pss是"按共享比例分摊后,这段区间实际上占了多少物理内存",两个进程共享一页,每个进程只算半页。所以如果一个进程和另一个进程大量共享内存,Rss 会虚高,Pss 才是准的。

实测下来,一个 fork 出来的子进程如果只读不写,它在父进程匿名区间上的Shared_Clean会上去,Private_Dirty保持很低；一旦开始写,Private_Dirty就一节一节往上爬,爬的速度取决于它实际写了多少页。这个增长曲线是阶梯状的,不是线性的,因为复制是按页触发的。

4.4 实验三：把页表层级也数一遍

如果你想验证多级页表"不为空洞付钱"这个说法,可以做一个简单的对比：一个进程只mmap一页并访问,和mmap一大片并全部访问,看看页表占用的差异。

从/proc/<pid>/status里的VmPTE字段能看到页表本身消耗了多少内存：

grep -E "VmSize|VmRSS|VmPTE|VmPMD" /proc/<pid>/status

VmPTE是页表页的总量(单位 kB),VmPMD是上层页表页的量。一个只映射几页的进程,VmPTE通常是 4 的倍数(每张 PT 页 4KB),VmPMD大概十几到几十 kB(因为进程总有代码段、栈、堆等若干区域,每个区域至少要挂一条通路)。当你 mmap 几百 MB 并逐页访问之后,VmPTE会明显上涨,涨幅大约等于"映射字节数 ÷ 2MB × 4KB",也就是每覆盖 2MB 就要多一张 PT 页。这个比例你可以自己算一下验证,我算过几次都对得上。

5. 常见问题与排查技巧实录

5.1 进程内存持续上涨,是泄漏还是 COW

这是我最常被问到的一类问题。表现是：服务跑着跑着 RSS 涨上去,但代码里查不到明显的泄漏点,重启就恢复。这种情况下我会按下面这个顺序排查。

先看是匿名页还是文件页。直接读 smaps,把Private_Dirty和Private_Clean分别汇总。Private_Dirty高说明是程序自己分配的内存,大概率是真正的泄漏或者缓存无界增长;Private_Clean高说明是映射的文件页,通常是代码段或者 mmap 的文件,不算问题。

再看是不是 COW 导致的双份计账。如果进程是 fork 模型(比如 Perl、Python 的多进程并发模型),父进程占的内存在 fork 后会被子进程共享,fork 出来的子进程如果写了大量页,每写一页就多出一份物理内存。这种情况Rss会涨,但Pss长得没那么快,而且父进程和子进程的Private_Dirty会同时增长。解决办法通常是改用posix_spawn或者线程模型,或者限制子进程生命周期。

最后看是不是堆碎片。malloc的 RSS 涨但VmSize不涨,说明是已释放的页没有归还给操作系统。glibc 的malloc在很多情况下不会立刻munmap,尤其是堆顶以下的空闲块。可以用malloc_trim(0)主动归还,或者配置M_MMAP_THRESHOLD让大块分配直接走mmap。

5.2 地址对齐与段错误的那些坑

虚拟地址空间相关的段错误,有一大半和对齐、权限标志有关,我把常见的几种列在下面。

mmap返回的地址一定是页对齐的,但如果你自己算偏移,很容易算出非对齐地址。比如想映射文件偏移 5000 字节的位置,mmap的offset参数必须是 4096 的倍数,因为内核是按页映射的,不支持的偏移会直接返回MAP_FAILED并置EINVAL。正确做法是把偏移向下对齐到页边界,然后拿返回值加余数。

另一个坑是PROT_WRITE和MAP_SHARED的组合。用MAP_SHARED映射一个只读文件却要求写权限,mmap会失败;但如果用MAP_PRIVATE,写权限是允许的,只是写了之后不会反映到文件。很多人在这里被卡住,以为是权限问题,其实是映射类型选错了。

还有一个隐蔽的坑是栈溢出。主线程栈默认 8MB,如果函数里开了个大数组,或者递归太深,会撞到栈底下面的保护页,触发段错误。这种错误的表现是地址接近0x7fff...的边界,和堆、映射区的错误很好区分。定位方法是看 core dump 里的rsp值和 maps 里栈区间的起止地址。

5.3 常见问题速查

我把这几年处理过的相关问题整理成一张表,方便你出问题时先对号入座。

提示：读/proc/self/pagemap拿到的物理页号在新内核上对非 root 用户是清零的。这不是 bug,是有意为之。你要是发现查出来全是 0,先确认是不是忘了sudo。

注意：/proc/<pid>/smaps的读取开销不小,尤其对大内存进程。线上环境频繁读会明显增加内核态 CPU 占用,采样间隔别低于十几秒。

5.4 几个我踩过的坑

第一个是关于pagemap的偏移计算。我一开始写成(addr / 4096) * 8,结果因为addr是void*,在 32 位编译下没问题,64 位下截断出过怪问题。后来统一改成((unsigned long)addr >> 12) * 8,再转off_t,才彻底稳定。这种小地方不注意,查起来能耗掉半天。

第二个是关于 COW 的测量时机。早期我做实验时,在 fork 之后立刻读子进程的 PFN,发现和父进程一样,还以为 COW 没生效。后来才想明白,fork 那一刻本来就不该复制,复制发生在写的时候。所以我现在的实验脚本都是"fork → 读 → 写 → 再读",分三个时间点采样,才看得到完整的变化过程。

第三个是关于大页的意外开启。有次压测一个 fork 密集型服务,发现内存比预期多用了将近一倍,查了半天代码没找到问题,最后看AnonHugePages才发现系统默认开了透明大页,每次 COW 都复制 2MB。关掉之后内存立刻回到预期水平。这件事之后我养成了习惯：凡是 fork 密集的服务,上线前必查一遍大页配置。

第四个是 TLB 刷新的问题。在做用户态共享内存的优化时,我尝试手工改页表来共享页面,结果发现改了之后另一个进程读到的还是旧数据。原因就是 TLB 没刷。后来改成走正规的mmap(MAP_SHARED)路径,虽然多一层内核调用,但省掉了所有这类心智负担。这件事让我彻底相信：能在用户态用标准接口解决的事,别去碰页表。

最后分享一个我平时做内存问题定位的顺序,不一定最优,但很省事：先用VmSize和VmRSS的差值判断是"申请了没用"还是"用了没还";再用Private_Dirty判断是匿名内存还是文件页;然后用Pss修正共享带来的误判;最后才上pagemap和 core dump 这种重武器。多数情况下前两步就能把范围缩到很小,真要读到页表一级的问题,其实一年也遇不上几次。