前两年带团队做性能优化遇到一个特别诡异的问题某服务的内存占用曲线像心电图一样一会儿飙到十几个G一会儿又跌回几百M但实际业务流量根本没波动。当时我们查了物理内存分配、slab缓存、page cache一路排查下来最后才发现问题出在进程地址空间本身——某个模块疯了一样地mmap和munmapVMA数量暴涨又暴跌。从那时候起我才算真正意识到不懂进程地址空间搞Linux内存管理就永远是隔着一层纱。很多人刚开始学内核内存管理都是先看伙伴系统、slab分配器这些物理内存管理的部分觉得懂了物理页怎么分配就算入门了。但真正常态化运行的进程它访问的都是虚拟内存。内核给每个进程画了一张巨大的“虚拟地图”进程看到的地址空间是连续、干净、按需分配的而背后物理内存可能零散分布在各个zone里。进程地址空间这一章就是讲这张虚拟地图是怎么画出来、怎么用、怎么销毁的也是理解缺页异常、写时复制、内存映射、OOM这些后续内容的地基。这篇文章没有按照教科书式的模块罗列来写我会尽量用做项目、踩坑的视角把进程地址空间的核心设计、数据结构、系统调用背后的逻辑和常见问题排查串起来。适合已经大概了解内核入门知识、想深入内存管理这块的开发者也适合做性能调优时被虚拟内存指标搞晕的运维同学。1. 先从整体设计聊起为什么进程需要一块“假”的地址空间1.1 没有虚拟地址会怎样先看一个最简单的场景。你写了一个C程序声明了一个全局数组然后按索引访问它。如果系统只有物理地址那么每次编译出来的程序访问的都是固定的物理内存区域。两个程序同时跑的时候要么你提前给它们划分好互不重叠的内存区域要么干脆只能跑一个。这种直接操作物理内存的模型叫“实地址模式”它的问题是致命的第一多个进程无法安全地共享内存因为没法保证各自申请的区域不重叠第二内存碎片化没法解决程序运行中申请和释放堆内存物理内存会迅速碎片化时间一长就没有足够大的连续区域给新程序用第三安全性完全不存在任何一个进程都可以通过指针越界读到别的进程的数据甚至改写内核的数据。所以现代操作系统普遍引入了虚拟地址空间抽象。每个进程都认为自己拥有一整块从0到TASK_SIZE的连续内存这对进程来说是“假”的内核负责在这张虚拟地图和真实物理内存之间建立动态映射。1.2 地址翻译是怎么完成的MMU、页表与TLB虚拟地址到物理地址的翻译硬件上主要靠MMUMemory Management Unit完成。CPU每次访问某个虚拟地址MMU就会去查页表。页表是内核维护的一种多级数据结构记录了虚拟页到物理页的映射关系。由于页表查询涉及多次内存访问性能损耗太大会影响整体速度所以CPU内部还有一个叫TLBTranslation Lookaside Buffer的高速缓存专门缓存最近用过的地址翻译结果。这个过程可以用一个不太严谨但好懂的类比页表相当于一本字典虚拟地址是你要查的单词物理地址是单词的解释TLB就相当于你大脑里临时记下的常用单词大部分时候不用翻字典直接就能说出来。命中TLB是高性能的关键一旦频繁触发TLB missCPU就不得不一遍遍翻页表延迟会成倍增加。一个大页HugePage之所以能提升某些场景性能本质就是减少了页表层级、扩大了单个TLB条目能覆盖的内存范围让同样的TLB容量能映射更多内存。这个问题在后面排查性能时还会碰到。1.3 虚拟地址空间的两半划分用户态与内核态在x86-64架构上虚拟地址空间通常被划分为两大部分较低地址区域给用户态进程使用较高地址区域给内核使用。以常见的4级页表配置为例用户空间一般是从0x0000000000000000到0x00007fffffffffff约128TB内核空间从0xffff880000000000往上。用户态进程无法直接访问内核地址区域只有通过系统调用陷入内核后才能访问。用户空间内部的布局也不是随意的经典的内存布局从低地址到高地址依次是代码段、数据段、BSS段、堆、内存映射区、栈、以及各种环境变量和参数区。其中堆向上增长栈向下增长中间留出巨大的空闲区域给mmap映射区。这种布局设计不是拍脑袋决定的主要是为了让堆和mmap区有充足的生长空间也避免栈向下增长时很快撞到其他区域。有个点值得注意虽然用户空间看起来有128TB这么大但真正能用多少还取决于内核的overcommit策略和物理内存、swap的大小。也就是说虚拟地址空间大不等于能随便申请这是很多新人在看VSZ和RSS差距时最容易误解的地方。2. 核心数据结构mm_struct、vm_area_struct与页表2.1 mm_struct地址空间的总管家每个进程都对应一个内存描述符mm_struct记录了这个进程整个地址空间的全局信息。比如代码段的起始地址、堆的起始地址、栈顶位置、页表基址、未锁内存量、地址空间总大小、以及维护VMA链表和红黑树的根节点。一个进程无论有多少个线程它们共享同一个mm_struct这也是为什么多线程之间可以方便地访问彼此的堆内存。mm_struct里有两个引用计数这个细节让很多人栽过跟头。mm_users记录的是有多少个“用户”也就是有多少个线程正在使用这个地址空间mm_count则是这个mm_struct本身被引用的次数。区别在于mm_users归零说明地址空间已经没有用户线程了可以被清理mm_count归零才说明这个mm_struct结构体本身可以被释放。内核里经常看到类似“mm_users是几、mm_count是几”的检查就是在这两者的语义上做判断。还有一点容易忽略内核线程是没有用户地址空间的它们的mm字段是null。如果你在内核线程里不小心解引用了current-mm会直接空指针崩溃。正确的做法是访问current-active_mm这个字段指向了内核线程上一次切换时借用的用户进程地址空间。2.2 vm_area_struct地址空间的基本街区一个进程的地址空间并不是一整块连续内存内核会把不同属性的区域拆分成一个个VMAVirtual Memory Area虚拟内存区域。每个VMA用vm_area_struct来描述包含该区域的起始地址、结束地址、访问权限读、写、执行、标志位、以及对应的文件映射信息或匿名内存信息。VMA同时挂在两个数据结构上一个双向链表用来按顺序遍历整个地址空间一棵红黑树用来快速按地址查找某个VMA。为什么要两个链表适合从头到尾遍历比如fork时复制所有VMA红黑树适合精确查找比如缺页异常时要知道当前地址落在哪个VMA里。缺页异常是高频路径所以查找必须快红黑树的O(log n)查找是必须的。VMA合并是一个很影响性能的细节。当你连续mmap两次相邻的内存然后munmap掉中间一小块内核会实时检查相邻VMA是否可以合并比如权限相同、映射类型相同、文件偏移连续。合并之后VMA数量减少查找效率更高。反之如果程序频繁用不同权限、不同大小去mmap和munmap地址空间会被切得特别碎VMA数量暴涨性能就会明显劣化。2.3 页表虚拟地址到物理地址的翻译官VMA只是记录了地址空间的属性并不代表已经分配了物理内存。真正把虚拟地址“落地”到物理页的是页表。x86-64架构下常规的4级页表分为PGD、PUD、PMD、PTE四层每一层都有自己的页表项。虚拟地址就是按照约定的位数拆成4个索引和1个偏移量逐级查找到最终的物理页帧号再加上页内偏移就得到物理地址。这种多级页表的设计核心目的是节省内存。如果只有一张扁平的大页表每个进程就得为整个地址空间的每个页维护一个页表项哪怕大部分地址空间压根没有分配过内存。多级页表的好处是高层级没有对应的子页表时可以放空指针只有真正被访问到的区域才逐级建立页表项未使用的内存区域完全不占页表内存。注意进程地址空间大并不代表页表也大。一个进程映射了1TB的虚拟地址空间但只要实际访问过的内存只有几百MB页表占用的内存也是跟着实际访问规模走的。这也是为什么mm_struct里专门记录页表内存占用排查内存泄漏时一个被忽略的坑就是页表内存吃满。2.4 缺页异常真正的“按需分配”由这里触发虚拟地址空间之所以能做到“申请时轻描淡写、访问时才真正分配物理内存”靠的就是缺页异常机制。进程访问一个尚未建立映射的虚拟地址时MMU发现页表项为空触发缺页异常内核在异常处理路径中进行判断和补救。缺页异常分为两类major fault需要从磁盘或swap换取数据耗时极长minor fault说明物理页已经存在只需要建立映射关系比如共享内存首次访问、代码段映射这类延迟很低。性能排查时如果major fault数量异常多意味着大量内存内容需要从磁盘读取基本可以判断是内存不足或访问模式不合理。缺页异常里最经典的路径是写时复制Copy-On-WriteCOW。fork一个子进程时内核并不真正复制父进程的物理内存而是把父子进程的页表都标记为只读同时把这些页指向同一批物理页。等到某一边尝试写操作时触发缺页异常内核才分配新的物理页把原内容拷贝过去再更新页表。这个机制极大地降低了fork成本也解释了为什么fork之后父子进程各自修改自己内存时进程的实际物理内存消耗才会开始上升。3. 地址空间的创建、扩张与回收读懂系统调用背后的逻辑3.1 fork和exec地址空间是复制还是重建fork一个进程时内核要做的是“浅复制”父进程的地址空间。这里的浅复制体现在整个mm_struct会被拷贝所有VMA也会逐个复制但物理内存页并不会复制而是通过COW机制共享。你可以在代码里尝试fork之后立刻让父进程和子进程分别修改自己栈上的某个变量然后用工具观察物理内存变化你会发现只有被修改的页才产生了新的物理页。VMA逐个复制听起来简单但实际操作很讲究。如果父进程有非常多的VMAfork的耗时和锁竞争会很明显。这也是为什么某些服务在高并发fork场景下性能很差的原因之一。一个常用的优化是在程序启动后、真正对外服务前预先分配好需要的映射区域减少运行中的VMA动态变化。exec和fork正好相反。exec加载一个新程序时并不会复用旧程序的地址空间而是先释放掉当前的mm_struct然后根据新程序的ELF文件重新构建一整套地址空间。代码段和数据段通过文件映射的方式建立VMABSS段和堆通过匿名映射建立。这个“推倒重建”的语义很重要。用exec族函数时原来的堆、栈、全局变量全部消失代码从头开始跑只有文件描述符和某些进程属性被保留。3.2 mmap与brk堆和映射区的扩张用户态程序员最熟悉的内存分配函数malloc底层最终无非两个手段对于小块内存用brk系统调用扩大堆顶对于大块内存用mmap做匿名映射。这里存在一个典型阈值有些实现默认超过128KB的分配直接走mmap。原因很简单brk扩展的堆是一段连续区域释放时如果堆顶又被占用就没法把这块内存还给内核容易造成堆内碎片而mmap分配的区域在munmap时可以整体释放。mmap的本质是创建一个新的VMA并建立虚拟地址到文件或匿名页的映射关系。如果是文件映射就是内存映射文件I/O读写文件变成直接访问内存配合page cache能极大提高文件访问效率。匿名映射则用于动态内存分配。理解mmap时要记住一点mmap本身只是“布置地图”并不分配物理内存只有真正访问到相关地址才会通过缺页异常把物理页准备好。brk调整堆的边界时内核会检查前后VMA的权限和类型能合并就合并能扩展就扩展。这意味着频繁的小块malloc/free由于堆顶不能及时收缩进程的虚拟地址空间会被撑大。这体现在top里就是VSZ很高但RSS可能并不高因为那些虚拟地址从未被真正访问过。3.3 munmap与exit地址空间的回收有分配就有释放。munmap将一个VMA区间从地址空间摘除同时会检查摘除后的缺口是否会分裂出新的VMA并释放对应页表项。如果被解除映射的物理页没有被其他进程引用这些页最终会被释放回伙伴系统。进程退出时地址空间的回收路径是exit_mmap。它会遍历所有VMA尝试做两件事一是对文件映射做写回保证脏页不丢失二是释放所有用户页表和物理页。这里有一个值得注意的性能点如果版本较老的内核和大量VMA的进程退出遍历VMA和逐个释放页表会产生不小的延迟甚至在某些极端场景变成整个系统的瓶颈。现代内核针对这个场景做了不少批量处理优化但VMA数量本身依然是排查问题时需要关注的重要指标。另一个容易踩坑的点是写文件的时候如果依赖进程退出时的写回机制会有数据丢失风险。因为系统在进程退出时执行写回并不意味着写回一定成功也不意味着顺序一定如你预期。稳妥的做法还是在业务代码里显式调fsync。3.4 从用户态观察地址空间/proc 里的秘密排查虚拟内存问题时最常用的就是从用户态看/proc/ /下的文件。/proc/ /maps会把当前进程的每一段VMA列出来包括起始地址、结束地址、权限、偏移量、设备号、inode和映射路径。一排排读下来基本就能看出进程地址空间的大致结构。/proc/ /smaps则更进一步给出了每一段VMA的详细内存统计RSS、PSS、私有脏页、共享脏页、可回收页等。特别是PSSProportional Set Size它把共享页按共享进程数均摊到每个进程看容器和共享库内存占用时比RSS准确得多。比如一个动态库被10个进程共享它的物理页在smaps里显示为共享页单独看某个进程的RSS会显得很高但PSS会把它除以10这样看整体的内存压力就合理得多。还有个实用技巧是检查/proc/ /status里的VmPeak和VmHWM。VmPeak表示虚拟地址空间的历史峰值VmHWM表示物理内存的历史峰值。如果当前RSS并不高但VmHWM很高说明进程曾经使用过大量物理内存可能是以前有过突发性申请也可能是内存碎片导致峰值虚高。结合tsamp工具或者监控历史往往能定位到具体时间段和原因。如果你在服务器上跑的是标准Linux发行版还可以用readelf查看ELF文件的program header只看每个段的虚拟地址范围、文件偏移和对齐方式。对比/proc/ /maps里的项能直观看到代码段、数据段、BSS段是从ELF的哪些段映射出来的。4. 排查过的几个问题与避坑记录4.1 VSZ和RSS的差距为什么这么大不少人第一次看top的VSZ和RSS时都会懵进程的虚拟内存显示8G物理内存才800M是不是统计错了其实不是VSZ是进程整个虚拟地址空间的大小包括从未被访问过的堆、栈、映射区域而RSS是实际驻留在物理内存中的部分。malloc申请了巨大内存但只碰了一小部分典型就是VSZ暴增、RSS不变。还有一种常见情况是程序加载了大量共享库、或者mmap了一个超大文件但只读了一小段都会导致VSZ巨大而RSS相对较小。排查内存问题时先别急着怀疑泄漏看看VSZ与RSS的差值里到底有多少是page cache映射、多少是空闲堆空间很多“假报警”当场就破了。我见过某团队说服务内存泄漏进程RSS一直涨最后查出来是服务里有个线程每隔几秒就申请一个几十MB的匿名映射区域用完了不munmap而是等析构顺序再释放。整个虚拟地址空间被撑大之后又会触发更多缺页和更多的页表分配才让RSS也水涨船高。这类问题用smaps里的Pss和Rss逐项对比通常很快就能定位。4.2 VMA数量暴涨引起的调度与锁竞争前年做网关优化时有个模块为了提高并发设计成了每个请求创建一套内存池。结果某段时间压测时整体吞吐急剧下降排查发现进程内VMA数量达到了数万个一旦超过内核默认的max_map_count通常65530mmap直接返回ENOMEM。于是业务侧看到的表象是“内存不够”但实际物理内存还多得很。根本原因就是大量小VMA把地址空间切碎了不但红黑树查找变慢fork和exit时的遍历开销也直线上升。解决思路有两个层面业务侧把短生命周期的小mmap改成内存池复用内核侧调整max_map_count但那只适合作为临时缓解不能从根本上解决碎片化。如果你在排查自己的服务可以一边压测一边watch /proc/ /maps的行数如果行数随请求数线性增长基本就是VMA泄漏。这类问题往往指向某个库在频繁mmap和munmap或者某个线程栈创建异常值得仔细翻一遍代码路径。4.3 major fault引起的IO毛刺负载不高的机器上偶尔会出现整机卡顿几十毫秒的毛刺排查到最后经常是某进程触发了大量major fault。比如某个模块的稀疏文件访问或者启动时映射了超大文件但实际只访问其中个别页。每当一个页没有在page cache里命中就会从磁盘读一次读页的延迟再叠加缺页异常的开销高并发下就像突然卡住了一样。用perf或ftrace跟踪page fault事件时重点看major fault次数和发生地址。一旦发现大量major fault集中在某个文件映射建议考虑把这部分数据用posix_fadvise提前预读或用mincore检查哪些页在内存里再决定是否加大page cache。如果实在没办法把文件映射区域改用mmap加MAP_POPULATE提前填充也能减少运行中的突发缺页。还有个冷门但真实存在的坑某些文件系统在内存压力下会回收page cache而被mmap的文件页被回收后再次访问就是major fault。业务高峰期如果既有大文件mmap又有很强内存回收这种毛刺就会被放大。降低风险的方法是把关键访问频繁的文件映射加mlock或者调整vfs_cache_pressure这类内核参数但参数怎么调要按业务特性去实测。4.4 内存碎片与透明大页的影响进程地址空间碎不碎不只在VMA层面底层物理内存同样会有碎片问题。对用户态程序来说最直观的影响是分配需要连续物理内存的场景越来越少性能抖动越来越明显。透明大页THP默认在某些发行版是开启的它会让内核在合适时机把一组普通页合并成2MB的大页提高TLB命中率但合并过程可能引入额外的内存规整延迟。如果数据库这类延迟敏感型业务跑在开启THP的服务器上有时会出现偶发性卡顿就是因为触发了内存规整。很多团队在生产环境会直接把THP设为never或用madvise模式只在显式指定的映射上启用大页。遇到“运行稳定但偶发RT尖刺”这类问题时把/sys/kernel/mm/transparent_hugepage/enabled翻出来看看往往是第一步。关于地址空间的碎片mmap时内核默认会尽量使用现有VMA之间的空洞实在找不到合适区域才会扩展堆段或栈段。这也是为什么长时间运行的服务即使没有内存泄漏虚拟地址空间也可能出现大量空洞。处理这类碎片没有银弹核心思路还是减少运行中的动态映射数量必要的时候通过重启进程来重置地址空间。5. 写给自己的几点经验总结学进程地址空间这一节最忌讳的就是抱着源码从头啃到尾。我个人的路径是先画出一张x86-64下用户态进程的地址空间布局图把栈、堆、mmap区、代码段、数据段的位置固定下来然后再去读mm_struct和vm_area_struct的字段定义最后再配合/proc/ /maps去做实际观察。画图这一步看似简单但能帮你把“虚拟地址”和“物理地址”这两个容易混淆的概念彻底分开。这章节的内容和后续好几个主题是强相关的缺页异常、写时复制、共享内存、OOM Kill、用户态与内核态的数据拷贝全都绕不开mm_struct和VMA。如果只记结论不看机制后面遇到疑难杂症还是没法定位。反过来如果你能把进程地址空间这条线摸透了再回头去看内存压缩、内存规整、内存热插拔这些话题很多疑问都会迎刃而解。学习过程中不妨自己动手写几个小实验在程序里做各种大小、各种权限的mmap然后用/proc/ /maps观察VMA的变化fork一个进程用smaps看父子进程共享页的变化故意制造大量munmap留出空洞看新mmap会不会复用这些空洞。操作系统这种知识光看不动手永远差着一大截。