Linux进程地址空间深度解析：从mm_struct到缺页机制

做内核相关开发这些年，我几乎每天都要跟进程地址空间打交道。不管是排查程序崩溃、分析内存泄漏，还是研究某个性能瓶颈，最后往往都会落到“这个地址属于哪个区域、这块内存是怎么映射进来的、页表为什么是这个样子”这类问题上。很多同学把进程地址空间理解成一张内存分布图——text段、data段、堆、栈、mmap区各就各位——这没错，但它远远不够。这张图只是结果，真正重要的是它背后的那套机制：内核用什么数据结构记录这些区域，缺页异常怎么把虚拟地址变成物理内存，写时复制怎么在fork之后把开销压到最低。这些问题搞清楚了，很多“玄学”问题都会变得非常朴素。

这篇文章就从我的实际经验出发，把进程地址空间这一章拆开揉碎来讲。我会先讲清楚它到底在解决什么问题，再带着你完整过一遍用户空间的地址布局，然后用源码级别的视角看内核的mm_struct和vm_area_struct，接着用一组可以自己动手做的实验把mmap、mprotect、缺页这些机制验证一遍，最后是几年下来积累的排查技巧和常见问题速查。适合正在读内核源码、做底层性能优化、或者被段错误和内存问题折磨得够呛的朋友。

1. 进程地址空间到底在解决什么问题

1.1 从“裸内存”到“虚拟地址”的跳跃

先退一步想一个基础问题：如果没有地址空间，程序会怎样？每个程序都直接操作物理内存，那么两个程序同时运行，它们对同一个物理地址的读写就会互相踩踏。更麻烦的是，程序在编译链接时根本不知道自己会被加载到哪个物理地址上——今天加载在0x100000，明天也许就变成0x200000了，链接器没法干活，程序的全局变量地址也会漂移不定。

所以操作系统引入了虚拟内存这一层抽象。每个进程拥有独立的虚拟地址空间，进程看到的地址不是真正的物理地址，而是由内核通过页表动态翻译的虚拟地址。进程A的0x7fff...和进程B的0x7fff...虽然数字一样，翻译到物理内存后可能完全是两回事。这样隔离性就有了，安全性也有了——进程A不能通过猜测地址去读进程B的数据，因为那块虚拟地址在进程A的页表里压根不存在映射。

这个抽象的载体就是“进程地址空间”。它是内核视角下一个进程所有虚拟地址区域的集合，从0开始一直到用户空间最高地址，每一段连续的区域都有各自的属性：可读、可写、可执行、私有、共享、文件映射、匿名映射。内核不需要为整个地址空间逐个字节建立映射——那是天文数字的页表项——它只需要管理“哪些区间是有效的，这些区间各是什么性质”，等进程真正访问到某个地址时，再通过缺页异常去补上物理页。这种懒加载机制就是需求分页（demand paging），它让一个进程可以拥有很大的虚拟空间，却只占用很少的物理内存。

1.2 内核视角和进程视角完全不同

学习地址空间时最需要转换的一个思维是：进程看到的“连续”和内核管理的“连续”不是一回事。进程的堆从0x55555555a000到0x555555557000，这段虚拟地址在进程看来是连续的，但背后对应的物理页可以分散在物理内存的各个角落。页表完成的是虚拟页号到物理页号的映射，而VMA（虚拟内存区域）完成的是“这个虚拟区间属于谁、什么权限”的记录。

还有一个特别容易混淆的点：地址空间里有很多“空洞”。比如你查看一个进程的maps文件，会看到很多区间之间夹着一大片没有记录的地址范围。这些空洞对用户程序是透明的——你要是真去访问，只会收到一个段错误。但对内核来说，空洞意味着“没有VMA、页表为空、无需管理”，这是好事。地址空间管理的艺术就是尽量让VMA数量少、让空洞可用、让缺页次数合理。理想情况下，一个进程几十个VMA就能覆盖所有的动态内存区域。

2. 用户空间地址布局：一张图看懂所有区域

2.1 自底向上的经典布局

以64位Linux为例，用户空间虚拟地址一般从0x0000000000000000向上到0x00007fffffffffff。经典的用户空间布局从低到高大致是：

• 代码段（text）：从某个入口地址开始，包含程序的机器指令，只读可执行。
• 数据段（data）：已初始化的全局变量和静态变量，可读写。
• BSS段（bss）：未初始化的全局变量和静态变量，运行时初始化为零。
• 堆（heap）：动态分配的内存，向高地址方向增长，通过brk系统调用调整堆顶。
• mmap区域：文件映射和匿名映射，一般从堆顶上方开始向低地址方向增长，但实际布局内核会留出合适的间隙。
• 栈（stack）：局部变量、函数调用栈帧，向下（低地址）增长。
• 共享库、vdso、vsyscall等映射：通常分布在栈附近或mmap区域的高位。

有不少同学会问，为什么mmap区放在堆和栈之间？主要原因是这个区域的大小不确定，可高可低，夹在中间最灵活。堆向上走，mmap区向下走，二者在一定约束下互不干扰，理论上可以各占半壁江山。但实际使用中mmap区的分配量往往远超堆，所以内核在创建地址空间时会根据架构配置一个默认布局。

如果你现在就在Linux上，最简单的验证方式就是执行：

cat /proc/self/maps

shell自身也是一个进程，你会发现输出的第一行通常是类似：

55a2c5360000-55a2c5382000 r-xp 00000000 00:37 1874 /usr/bin/demo 55a2c5382000-55a2c538b000 r--p 00022000 00:37 1874 /usr/bin/demo 55a2c538b000-55a2c5390000 rw-p 0002b000 00:37 1874 /usr/bin/demo

这里第一列是虚拟地址区间，第二列是权限和映射类型，第三列是文件偏移，后面是设备号、inode和路径。整个maps文件读下来，你就能直观看到进程的地址空间长什么样了。多执行几次cat /proc/self/maps，你会发现起始地址在变化，这就是ASLR（地址空间布局随机化）在起作用。

2.2 各区域的权限差异是硬约束

地址空间中的每一个区域都有自己的权限组合，rwx一套标志下来，决定了这块虚拟内存能怎么访问。代码段是 r-xp，可读可执行但不可写，所以程序不能修改自己的指令；数据段是 rw-p，可读可写，但不能执行；堆和栈也是 rw-p；mmap出来的文件映射可以根据你传入的prot参数决定，PROT_READ | PROT_WRITE就是rw，如果加上PROT_EXEC就会变成rwx。

这个权限不是摆设，而是由硬件和内核共同强制的。x86页表项的U/S位和R/W位、NX bit，配合VMA中的vm_flags，在缺页异常和权限检查时会层层把关。任何违反权限的访问都会触发保护错误，也就是我们常说的Segmentation Fault。常见的踩坑场景是：某个程序把字符串常量区（通常是.rodata，属于r-xp或r--p的区域）用指针强行写入，一写就崩，因为那块VMA根本不带写权限。

还有一点值得注意：同一个文件可以被多次映射，每次映射的权限和区间都独立记录。内核不会去合并两个权限不同的映射，哪怕它们在地址上紧挨着。VMA合并的前提是多个条件同时满足，这在后面第3节我会详细讲。

2.3 地址空间里的“隐藏居民”

除了常见的text/data/heap/stack这些区域，地址空间里还住着不少容易忽略的居民。

第一个是vdso。你可以在maps里看到类似[vdso]的条目，它像一个微型共享库，被内核映射到用户空间，主要作用是让glibc里的某些系统调用（比如gettimeofday、clock_gettime）不需要陷入内核就能拿到结果。因为它直接做内核的一部分数据映射，但用的是用户态可读的权限。

第二个是vsyscall。这是老式机制的残留，在64位系统上固定映射在一个固定的虚拟地址（0xffffffffff600000附近），现在主要为了兼容旧程序存在。因为固定地址且有安全风险，新代码基本都走vdso了。

第三个是各种[heap]、[stack]、[anon]标记。maps里那些没有路径、中括号内部署名的映射通常是匿名映射。你调用mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)产生的那块内存，maps里就会以[anon]的形式出现。

第四个是线程栈。用pthread创建线程时，glibc会为每个线程mmap一块区域作为栈。这些映射在maps里通常显示为/usr/lib/.../libc.so附近的匿名映射，或者直接显示为[stack:线程编号]。线程多了，这类VMA数量会暴涨，这也是VMA数量上限（vm.max_map_count）经常被触顶的原因之一。

3. 内核数据结构：mm_struct与vm_area_struct

3.1 mm_struct：整个进程内存家庭的总管

每个进程在内核中都有一个mm_struct结构，它就是这个进程地址空间的全部家底。你在linux/mm_types.h里可以看到它的定义，字段非常多，但核心就那么几个：

• mmap：指向第一个VMA，所有VMA通过链表串起来。
• mm_rb：VMA红黑树的根节点。链表方便遍历，红黑树方便查找。
• pgd：进程页表顶级页目录的物理地址。进程切换时，CPU就是通过把CR3寄存器切换成这个值来换页表的。
• start_code/end_code/start_data/end_data/start_brk/brk/start_stack等：记录各重要区域的边界，内核可以通过这些变量快速知道某个地址大概落在哪个区域。
• mm_users和mm_count：引用计数。前者统计“有多少个进程正在使用这个mm”，后者统计“这个mm结构本身被引用多少次”。fork之后父子进程共享同一个mm，所以mm_users会是2，但写时复制会让它们很快分家。
• map_count：当前VMA的数量。

mm_struct还包含mmlist，把系统中的所有mm连成一个链表，方便内核做全局遍历——比如计算系统总内存、做OOM扫描时都要用到它。

还要注意的是，内核线程没有用户地址空间，它的mm字段是空的，或者说它借用的是一个特殊的active_mm。这个细节在进程调度和内存上下文切换时非常重要，因为内核线程不需要也不应该拥有用户态页表。你如果看到系统里某个进程的maps文件是空的，别慌，可能它压根就是个内核线程。

3.2 vm_area_struct：一块连续区间的身份证

struct vm_area_struct描述一段连续、属性一致的虚拟地址区间。它的关键字段：

• vm_start和vm_end：区间开始和结束地址。注意vm_start包含、vm_end不包含，所以区间大小是vm_end - vm_start。
• vm_mm：反向指向所属的mm_struct。
• vm_page_prot：该区间页表项设置的硬件权限，即每个页的权限位。
• vm_flags：区间属性标志，包括VM_READ、VM_WRITE、VM_EXEC、VM_SHARED、VM_GROWSDOWN、VM_DONTCOPY等。
• vm_ops：这一段的特殊操作函数集，比如文件映射的fault、open、close等回调。匿名映射的vm_ops通常是空的。
• vm_file：映射的文件对象。如果是匿名映射，这个字段为NULL。
• vm_private_data：给驱动或子系统挂私有数据用的。

VMA的数量直接关系到系统性能。每个VMA在内核里会占用一块内存，同时当你访问一个地址时，内核需要在这个进程的VMA里找到“这个地址属于哪一段”。最早的内核是线性扫描链表，那在VMA很多时性能等于是灾难级的。现在的内核把VMA同时维护成红黑树，查找操作可以用find_vma()以O(log n)的复杂度完成——原则是找到第一个vm_end > addr的VMA。这是理解地址空间搜索机制的核心。

3.3 VMA的合并、分裂与查找

VMA不是一成不变的。mmap新映射一个区域时，如果它跟前后的VMA刚好能在地址上衔接，权限完全一致，映射类型一致，没有vm_ops的特殊要求，内核会把它们合并成一个更大的VMA。反之，如果你munmap掉一个VMA的中间部分，原来那个VMA会像切香肠一样被分裂成两个VMA，分布在空洞的两侧。

合并的好处是减少VMA数量，提高查找效率。所以你会看到，频繁地用mmap和munmap操作小内存块，会让进程的VMA数量快速上涨。而VMA数量有上限vm.max_map_count，默认值在很多系统上是65530。超过这个值，mmap就会返回ENOMEM。我见过一个真实案例：某服务因为频繁创建线程栈加映射临时文件，最终线程数还没到极限，先撞上了这个VMA上限，程序疯狂报“cannot allocate memory”。排查了半天，不是物理内存不足，而是VMA配额用光了。

分裂逻辑同样重要。比如某个区间原来权限是rw，你用mprotect把它的一部分改成r，那内核就把原VMA一分为二，分成两段，其中一段权限为r。每一次这样的操作都会增加VMA数量。

3.4 页表与CPU如何“翻译”地址

VMA只管“段级别”的划分，真正地址翻译靠的是页表。现代x86-64 Linux通常使用4级或5级页表：PGD、P4D、PUD、PMD、PTE（5级时多一层P4D；我们一般接触的应用地址空间用4级就覆盖了）。一次虚拟地址翻译，CPU把虚拟地址拆成几段索引，逐级查表，最后找到物理页框号，再加上页内偏移得到物理地址。

每张页表项里除了物理页框号，还有权限位、存在位、脏位、访问位等。当页表项的存在位为0时，CPU访问这个虚拟地址就会触发缺页异常（page fault），内核接管后在异常处理里做真正的工作——分配物理页、建立映射、把数据从磁盘读进来等等。

这里我特别想说一下TLB。页表在内存里，每次地址翻译都要查好几级内存，太慢了。所以CPU有TLB（快表），缓存最近用过的虚拟地址到物理地址的映射。TLB命中了，地址翻译几乎零成本；没命中，就要走完整的页表查询，开销大得多。进程切换时，由于每个进程页表不同，TLB中的旧映射全部失效，这就是为什么进程切换是操作系统的性能敏感操作。

有一次我在优化一个大量进程频繁切换的服务，发现TLB miss率非常高。后来把进程间通信从共享内存拆成另一种方式后，TLB miss率明显下降，延迟也好看了不少。这让我意识到，地址空间的布局不光是内核的事，也会深刻影响硬件TLB的命中率。比如用mmap分配大块内存，如果访问模式是随机小范围，那还凑合；如果是遍历几十GB的稀疏数组，TLB就会成为瓶颈。这种情况下，可以试试大页（HugePage）和THP（透明大页）来降低TLB miss。

3.5 fork、exec与地址空间的命运

fork()一个进程时，内核会复制父进程的mm_struct和所有VMA。但这里有个著名的优化——写时复制（Copy-on-Write，COW）：父子进程一开始共享同一套物理页，页表项被标记为只读。任何一个进程尝试写入某个共享页时，触发保护缺页，内核才真正复制物理页，并把各自的页表项更新为可写。这种机制让fork的代价非常低，创建出的子进程可以立刻exec一个全新程序——exec会把整个地址空间几乎清空重建，之前费劲复制的物理页大部分都浪费了，所以COW的意义就格外大。

exec建立新地址空间时，内核先释放旧mm，然后为新程序重新创建VMA序列。load_elf_binary会解析ELF文件，根据PT_LOAD段创建代码段、数据段、堆、栈的初始区间，并设置好argc/argv/envp等参数的布局。这个阶段还要设置栈顶的起始值，通常位于一个由ASLR决定的随机偏移处。思考一下：为什么每个进程的栈起始地址都不一样？因为ASLR在背景里悄悄作妖。你不想要随机化时，可以用setarch -R运行程序，或者调试时让调试器自动关闭ASLR。

4. 动手实验：用mmap、mprotect和缺页验证一切

4.1 实验环境准备

理论说得再多，不如一个实验有说服力。我建议你准备一台Linux机器，普通用户权限就够，安装好gcc、gdb、procps（提供pmap命令）。然后写一个简单的C程序，分别验证映射创建、权限修改和缺页行为。下面这个程序是我常用的模板，把mmap、mprotect、写入触发缺页三个动作都测了一遍：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/mman.h> #include <string.h> #include <fcntl.h> int main(void) { size_t len = 4096 * 4; void *addr = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (addr == MAP_FAILED) { perror("mmap"); exit(1); } printf("mapped at %p\n", addr); printf("before write, sleeping...\n"); sleep(5); memset(addr, 0xAB, len); printf("after write, sleeping...\n"); sleep(5); if (mprotect(addr, len, PROT_READ) != 0) { perror("mprotect"); exit(1); } printf("now readonly, sleeping...\n"); sleep(5); munmap(addr, len); return 0; }

编译运行：

gcc -o memtest memtest.c ./memtest & PID=$! echo "PID=$PID"

在它睡眠期间的几个关键节点，分别去看看/proc/$PID/maps和/proc/$PID/smaps。

4.2 看maps和smaps理解映射状态

运行起来后，先看映射之前和之后。比如执行：

cat /proc/$PID/maps

你会看到在原来没有记录的那段地址上，多了一行匿名映射。maps里的这行是这样的：

7f1b5c400000-7f1b5c404000 rw-p 00000000 00:00 0

注意，mmap传入的长度是4096*4，也就是16384字节，但输出中区间是0x1000（4096）的整数倍，且结束地址比起始地址多出0x4000（16384），说明映射长度本身就是页对齐的。而且虽然实际只用了4页，但VMA的vm_end - vm_start就是16384。这块区域还没有写入，smaps里对应项的Rss可能为0——因为尚未触发缺页，物理页一个都没分配。

再看smaps，它比maps信息更细。每段VMA下会列出Rss、Pss、Private_Clean、Private_Dirty、Shared_Clean、Shared_Dirty等指标。其中Pss尤其重要——它是把共享页按映射进程数量分摊后的估算值。判断一个进程真正占用多少物理内存，不要只看RSS，要结合PSS。比如两个进程共享同一个1MB的文件映射，各自RSS都是1MB，但PSS是0.5MB。用pmap -x $PID看到的RSS列其实统计的是总RSS。

4.3 缺页现场：从Rss为0到Rss增长

我们在程序睡眠期间执行cat /proc/$PID/smaps | grep -A10 '7f1b5c400000'，会看到VMA下面初始Rss是0。等到memset执行完再查看，Rss涨到了16KB。这个过程的本质就是：第一次访问这些虚拟地址时，页表项里不存在对应的物理页，CPU触发缺页异常，内核在缺页处理中分配4个物理页框并填好页表项。

为了进一步区分major fault和minor fault，可以在程序里加入文件映射，比如映射一个几MB的文件，然后读取。第一次访问某页时如果数据不在页缓存里，就会发生major fault，进程会被阻塞直到磁盘I/O完成。而前面那种匿名页的缺页通常只有minor fault，因为只是分配物理页，没有磁盘I/O。你可以对比/proc/$PID/stat中的minflt和majflt字段在操作前后的变化。这是理解“内存在使用时才真正分配”的最直观证明。

4.4 mprotect如何改变VMA属性

程序里调用mprotect后，这块VMA的权限从rw-p变成了r--p。如果你在变成只读后再尝试memset，会触发段错误——因为VMA的vm_flags里已经没有VM_WRITE了，页表项也被标记成不可写。内核在权限检查时会根据VMA中的vm_flags判断。这个例子解释了为什么mprotect可以用于实现内存保护，也解释了为什么一些JIT编译器和沙箱会用mprotect把代码页先置为可写写代码、再置为可执行防止篡改。

另外注意mmap和mprotect修改的只是VMA属性，不会立刻改写页表。页表项会在访问时重新建立。但mprotect确实会把现有页表项的权限位同步更新一遍，毕竟如果页表项还保留旧的可写权限，后续写操作就直接过去了，不会经过VMA检查，那就失控了。实际的内核处理方式是在mprotect调用里进行change_protection操作，遍历相关页表、更新权限位并冲刷TLB。

4.5 用系统限制观察地址空间

最后再做一个有意思的实验：把它包装成异常失败。用ulimit -v 65536限制虚拟地址空间为64MB，然后运行一个分配大内存的程序。你会发现即便物理内存充足，malloc或者mmap都会失败，返回ENOMEM。因为RLIMIT_AS限制的就是进程地址空间总大小，VMA区域加总不能超过这个值。这提醒我们：地址空间不是无限的，它受制于内核参数、处理器位数、还有进程自身的rlimit。

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

5.1 段错误：先分清是地址越界还是权限违规

段错误（SIGSEGV）大概是大家遇到最多的内存问题。排查时我一般按这个顺序来：

1. 看dmesg里的输出。内核会把触发段错误的进程名、访问的地址、指令指针都记下来。例如segfault at 0 ip 0x000055c2a2b3c12d sp 0x00007ffce1b2d9c0 error 6，error 6表示用户态写入、页不存在。这个信息有时直接就能告诉你访问的是不是一个空地址。
2. 用gdb复现，执行run后再bt看调用栈。配合info proc mappings查看进程的映射布局。
3. 分析访问的地址是否位于某个VMA之外。比如栈越界、堆越界、野指针、strcpy溢出等。这类问题和地址空间边界强相关，所以掌握maps就特别有用。

我踩过一个印象很深的坑：某个模块用alloca在栈上分配了一个很大的临时缓冲区，编译时优化一开，局部变量区域布局变了，导致栈溢出直接踩到栈顶之上的guard区域。内核在栈区域会设置一个向下增长的特殊VMA，带VM_GROWSDOWN标志，同时保留一定的guard gap。一旦访问越过guard gap，直接段错误。这类问题单纯看代码很难发现，用gdb配合寄存器值看栈指针偏移才能快速定位。

5.2 VMA数量触顶：别只知道加内存

vm.max_map_count是一个非常容易被忽视的内核参数。默认值很多系统是65530。当一个进程的VMA数量超过这个值，mmap开始返回ENOMEM。典型症状是线程一多就报内存分配失败，但free -m显示内存还多得很。

排查方法很简单：

wc -l /proc/$PID/maps

或者更直接：

cat /proc/$PID/status | grep VmPeak

看到VmPeak那行附近有map_count相关的条目。如果VMA数量很高，就去找哪里在疯狂产生VMA。常见原因包括：

• 每次读写某个小文件都用open+mmap+munmap，反复映射同一个文件片段。
• 线程数量大，线程栈每个都有独立VMA。
• 动态加载/卸载大量共享库。
• JIT类程序频繁申请并释放可执行内存。

缓解手段不只是调sysctl vm.max_map_count那样粗暴，而是优化程序：把细粒度mmap改成复用映射，或者用堆内存替代，或者聚合大块映射。我见过一个项目把每消息映射一个文件的做法改成预映射后，VMA数量从几万降到几百，性能也上来了。

5.3 内存“泄漏”其实可能是VMA不释放

有些同学看top发现RES越来越大就喊内存泄漏。但真实原因可能只是glibc把释放的小块内存放回malloc的缓存里，并没有把堆顶降回去。堆的VMA边界（brk）是不改变的，或者mmap区域释放了，但内核不会立刻把映射区间还给地址空间，而是保留一段空闲区间以便复用。所以从上往下看，进程的虚拟地址空间总量会保持一个高位。判断是否真泄漏，更可靠的办法是看smaps里Private_Dirty有没有持续增长，配合valgrind或mtrace去分析。

一个很常见的案例是频繁分配大于MMAP_THRESHOLD（默认128KB）的内存块，glibc会改用mmap分配，释放时也直接munmap。如果程序频繁做这种大块分配释放，mmap/munmap的系统调用量会很大，性能下降，而且地址空间会变得碎片化。解决办法是调低或调高malloc阈值，或者用内存池。

5.4 透明大页和TLB的日常纠缠

透明大页（THP）是把普通4KB页透明合并成2MB大页，从而减少页表项数量、提高TLB命中率。听起来很美好，但实际生产中经常带来延迟尖刺——因为分配大页需要找连续物理内存，缺页处理时间比4KB页长不少。尤其是数据库、搜索索引这类延迟敏感型应用，很可能因此出现rt抖动。

排查方法就是看/proc/$PID/smaps里是否存在AnonHugePages字段，数值大于0就说明有透明大页映射。如果业务场景不需要，可以针对进程关闭THP，或者在运行程序时设置madvise策略。内核参数/sys/kernel/mm/transparent_hugepage/enabled控制全局策略，never、madvise、always三选一。我个人的经验是：通用服务不要轻易开always，保持madvise让应用自己选择更安全。

5.5 地址空间随机化与调试的相爱相杀

ASLR让程序每次运行时的映射地址不同。这对安全是好事，但对调试不友好——你gdb断点打在某个地址，关掉再开地址就变了。因此gdb默认会关闭ASLR，调试时映射是稳定的。如果你想在非调试环境复现某个地址相关的bug，可以用：

setarch -R ./program

这样进程地址空间就是固定的。反过来，如果你要测试程序是否依赖固定地址，可以临时调大ASLR随机化强度，看看行为是否有变化。

5.6 OOM与overcommit

Linux内核对malloc的超额承诺（overcommit）非常宽容。你malloc一个1GB的虚拟内存，内核可能秒回一个指针，但物理内存完全没分配。只有当真正写这块内存时才慢慢吃物理页。如果这时物理内存加交换空间都不够了，内核会启动OOM Killer，挑一个进程杀掉。

排查OOM时，除了看dmesg里OOM Killer的日志，还可以关注/proc/sys/vm/overcommit_memory的设置。0是启发式，1是永远允许，2是严格禁止超过commit limit的映射。在数据库等对稳定性要求高的场景，有时会设置overcommit_memory=2并配合合理的overcommit_ratio，减少进程被OOM Killer在高峰时杀掉的概率。但这会改变malloc的语义，有些程序会因为一次大分配失败而崩得更快，所以改这个参数要谨慎。

5.7 问题速查表

6. 我的几点实操心得

最后说几个几年下来积累的小技巧，不算什么高深东西，但很实用。

一个是排查任何内存问题，先把/proc/$PID/status里VmSize、VmRSS、VmData、VmStk、VmExe这些字段过一遍。VmData是数据段+堆的大小，VmStk是栈的大小，VmExe是代码段大小。这些字段能帮你快速判断问题大概在哪一侧。比如VmData超高但RSS不高，说明虚拟分配极多但没真正使用，可能是程序申请了大量内存却没写，或者是内核对空闲VMA的回收不及时。

第二个技巧是善用smaps_rollup。现代内核提供了/proc/$PID/smaps_rollup，一条读出来就是整个进程的汇总，不用再自己grep加总了。脚本统计内存时会方便得多。

第三个是关于mmap的偏移对齐。文件映射的offset参数必须是页大小的整数倍，否则mmap直接返回EINVAL。但文件长度不需要页对齐，最后一个不完整页会被零填充。你如果在做文件映射IO，好好利用这个特性，可以省掉很多“手动处理尾部不足一页”的代码。

第四个建议：阅读内核源码时不要按顺序啃。就地址空间这一章，优先看mm/mmap.c里的do_mmap、find_vma、vma_merge，再看mm/memory.c里的handle_mm_fault、do_anonymous_page，最后看mm/rmap.c里的反向映射逻辑。等你有几百行源码量的积累后，很多概念就自然串起来了。

地址空间这个主题，说到底是“虚拟性”和“惰性”的完美结合。它让进程拥有一整片看似连续、实则隔离的虚拟内存，又通过缺页机制把物理内存的使用推迟到最后一刻。掌握了它，你就掌握了理解几乎所有内存问题的钥匙。至少在接口和机制这个层面，不论调优、排查还是写代码，你都不会再觉得内存是个玄学了。