有个同事前几天跑过来说，一个跑在服务器上的进程突然报内存分配失败，可我看机器内存明明很充裕，top 一看还有好几十G空闲。后来查下去发现，他自己没注意进程是32位编译的，虚拟地址空间被撑爆了。类似的场景我相信很多人遇到过——你对Linux虚拟地址空间的理解，决定了排查内存问题时能不能一眼看到真相。
这篇文章我来好好聊聊Linux虚拟地址空间这回事。不只讲概念，还会带你看实际进程的内存布局、讲清楚MMU和页表的协作过程，再给出一套我自己排查内存问题时的常用路数。搞开发、做运维、或者在准备Linux面试的朋友都可以看，把这块补扎实了，很多“玄学内存问题”就不再玄学了。
1. 虚拟地址空间到底是什么——先搞懂它解决的核心痛点
1.1 一个很直观的类比：酒店房间号和真实房间
我在给别人讲虚拟地址空间的时候，最喜欢用的类比是酒店。你去住酒店，前台给你一张房卡，房卡上写着“8216房”，你按照走廊里的指引牌走到8216房，刷卡进去住。你全程不需要知道这个房间在整栋楼的哪个角落、隔壁是谁、楼下是什么，你只需要保证“8216”这个房号在当前酒店是唯一的就行了。
进程和物理内存的关系就是这样。每个进程手里都有一张自己的“房卡”，也就是虚拟地址空间。它以为自己从地址0x400000开始有一整段连续的大内存，实际上这段地址可能映射到了物理内存的各个零散角落，有些甚至根本不在内存里，而是在磁盘的交换分区上。但因为有了虚拟地址空间这层“房卡机制”，进程根本不需要关心物理内存到底长什么样。
如果没有虚拟地址空间会怎样？那进程就要直接操办物理内存的每一块地盘。比如两个进程都把自己编译到0x1000这个地址，一运行就会互相踩踏；程序里写错了指针，可能一不小心就覆盖了别人的内存；物理内存碎片化严重时，明明总内存够多，但找不到一块足够大的连续区域给程序用。这一堆问题，靠虚拟地址空间基本都能化解。
1.2 进程的“我在用内存”和物理内存的真实占用
虚拟地址空间其实是操作系统的“谎言”，每个进程都以为自己在独占整台机器的内存。你在Linux里写一个简单的C程序，哪怕什么都不干，它的虚拟地址空间也有几十个映射区域。默认情况下，一个64位进程的虚拟地址空间会有128TB那么大，但真正映射到物理内存的、可能就那几MB的代码和数据。
关键点在于“映射”这两个字。虚拟地址空间里铺满了各种映射区域，但只有你真正去读写那些地址时，物理内存才会实际分配。这就像你在酒店拿了一堆房卡，但只有走到那个房间刷开门，那个房间才真正“属于你”。这个按需分配的机制，让大量进程可以共享同一台机器的物理内存，而不会互相挤爆。
当然，虚拟地址空间也不是无限资源。32位系统下整个地址空间只有4GB，一个进程最多用3GB用户空间。64位下理论空间很大，但依然有边界，而且地址空间本身还会受进程限制、文件大小限制等因素约束。这个我后面细讲。
1.3 说点理论门槛：地址空间和物理内存是两个维度
很多人刚开始接触这块时，喜欢把虚拟地址空间和物理内存混在一起看，这就会造成误解。比如看到程序占用虚拟内存很高，就以为物理内存快爆了；或者看到物理内存还剩很多，就觉得程序不可能申请不到内存。实际上它们之间是“映射”关系，不是“等于”关系。
我用一个更贴近实际的方式来说。你在Linux里用free -m看内存，会看到total、used、free这些指标，但你看不到每个进程的地址空间有多大、有多少映射是文件映射、有多少是匿名映射、有多少页被换出。想看这些，得去/proc/<pid>/maps、/proc/<pid>/status或者用pmap命令。地址空间是一个进程“能看到的世界”，物理内存是整台机器“真实的家底”，两者之间的桥梁是页表，这是后面要重点展开的内容。
2. 32位与64位：地址空间布局到底差在哪
2.1 经典3G/1G布局为什么不够用了
老一代搞Linux的人对“3G/1G”这个词肯定不陌生。32位系统地址空间总共4GB，Linux沿用了常规做法：用户态进程使用较低的3GB（0x00000000到0xBFFFFFFF），内核使用最高的1GB（0xC0000000到0xFFFFFFFF）。用户进程即使物理内存再大，自己能用的一般也就不到3GB，剩下的还得给堆、栈、动态库预留各种空隙。
这带来一个很实际的问题：你的机器哪怕装了8GB内存，一个32位进程能用的虚拟地址空间上限也就3GB左右，超过这个数，malloc就直接返回NULL，或者mmap直接失败。这个限制是体系结构级的，用户态程序很难绕过去。我见过不少老程序就是因为这个原因迁移到64位后，内存问题一下子消失了，问题的本质根本不是物理内存不够，而是虚拟地址空间被“封顶”了。
3/1G布局还有一个麻烦，就是物理内存超过1GB之后，内核那1GB地址空间没法直接映射全部物理内存，于是搞出个HIGHMEM（高端内存）机制，给内核访问高地址物理内存开了个后门。这个机制很复杂，性能也有损耗。这也是为什么服务器领域很早就抛弃32位内核，全面转向64位。
2.2 x86-64的划分：用户态和内核态各管一边
到了64位时代，地址空间宽敞得多。以x86-64为例，当前Linux使用的其实只有48位有效虚拟地址。用户空间从0x0000000000000000到0x00007fffffffffff，一共128TB；内核空间从0xffff800000000000往上，也是128TB。中间从0x0000800000000000到0xffff7fffffffffff是一大段非规范地址区，普通程序碰到这段地址基本就是非法访问。
64位下用户空间有128TB，对绝大多数程序来说，虚拟地址空间不再是瓶颈了。但这不代表你可以乱来。如果程序里写了个死循环不断申请内存但不释放，虚拟地址空间照样会被耗尽，而且因为空间大，这种问题更容易隐藏，等到爆发时往往很难收拾。
内核地址空间放在最高地址段，用户进程在用户态时根本访问不到那块区域。这种设计保证了用户程序即使恶意或者写错了指针，也不会直接篡改内核内存。这里顺便说一句，很多人在学内核模块、学提权的时候，真正要动脑筋的地方，就是如何在这套地址隔离机制下找到可乘之机。
2.3 一个64位进程从上到下都有什么
在64位Linux上，一个正常启动的进程，地址空间从低到高大体是这样的：
- 代码段（text）：程序机器码，只读可执行，一般从0x400000开始
- 数据段（data）：已初始化的全局变量、静态变量
- BSS段（bss）：未初始化的全局变量，不占磁盘但占内存
- 堆（heap）：动态分配的内存，向高地址增长
- 共享库映射区域：libc等动态库映射到的一块随机地址范围
- 栈（stack）：局部变量、函数调用帧，从高地址向低地址增长
- vDSO和vsyscall：内核提供的一些快速系统调用跳板，也在高地址处
- 内核空间：用户进程只能看到地址范围，不能访问
这些区域不是连续铺开的，中间会有很多空白区，也就是未映射区域。这些空白和随机化的偏移，一部分是安全考虑（ASLR），一部分是为了让越界访问更容易触发段错误，而不是悄悄写坏别的数据。
3. 从用户视角看真实内存布局——自己动手查
3.1 读懂/proc/ /maps，一页纸看穿进程内存地图
如果你想知道某个进程的虚拟地址空间长什么样，不需要写代码，也不需要gdb，直接看/proc/<pid>/maps就行。我先拿一个正在运行的bash举个例子：
cat /proc/$$/maps输出是一行一行“起始地址-结束地址 权限 偏移 设备 inode 路径”。其中权限部分有r、w、x、p/s这几个位，p表示私有映射，s表示共享映射。这一行行的映射，拼起来就是一个进程的完整虚拟地址空间地图。读懂了它，你就知道进程的堆在哪、栈在哪、libc被加载到哪个地址、有没有映射奇怪的文件。
注意maps里的地址是虚拟地址，不是物理地址。你在这个文件里看到7f...这种高位地址，就是动态库和堆栈常见的分布范围。很多内存排查工作，第一步就是通过maps来确认问题进程的地址空间被什么给吃掉了。
3.2 pmap命令更适合人看
/proc/<pid>/maps的信息量很大，但不够直观。我更喜欢先用pmap命令。pmap -x <pid>会显示每个映射区域的起始地址、大小、RSS、脏页数量以及映射内容。RSS表示这个映射实际占用了多少物理内存，这个比虚拟大小有意义得多。
pmap -x 12345输出里能看到每个库占了多少RSS，堆占了多少RSS，栈占了多少RSS。这比单纯看ps aux里的%MEM要精细得多。我排查内存泄漏的时候，第一眼就会看这里的RSS变化：如果某个映射区域RSS持续增长且不回落，基本上就是泄漏点。
还可以用gdb的info proc mappings来查看，效果类似。不过日常命令行快速查看，pmap足够了。
3.3 实验：malloc之后maps里到底发生了什么
为了更直观理解“虚拟地址空间会随分配变化”，我写一段极简的C代码来演示：
#include <stdio.h> #include <stdlib.h> #include <unistd.h> int main() { printf("PID=%d\n", getpid()); getchar(); char *p = malloc(64 * 1024 * 1024); printf("malloc 64MB done, address=%p\n", p); getchar(); for (int i = 0; i < 64 * 1024 * 1024; i += 4096) { p[i] = 1; } printf("touch all pages done\n"); getchar(); return 0; }编译运行后，第一次按回车前后观察/proc/<pid>/maps和/proc/<pid>/status里的VmSize和VmRSS。你很快会发现：malloc(64MB)之后，地址空间（VmSize）涨了，但物理内存（VmRSS）没怎么动；只有当程序真的去逐页写入时，VmRSS才会涨上去。这就是前面讲的按需分页。
这段小实验建议你自己跑一遍。它会帮你建立起“虚拟地址申请”和“物理内存实际占用”是两件事的直觉。很多人问为什么程序内存占用那么高，问的就是VmRSS；而报错说“内存不够”，有时候却是VmSize顶到了上限，两者完全不同。
4. 地址怎么映射：MMU、页表与缺页中断的协作
4.1 一次完整的内存访问，CPU到底经历了什么
好奇的同学会问：进程访问一个虚拟地址，比如0x7ffd12345678，计算机是怎么知道对应哪个物理内存单元的？这里面的核心角色是MMU（内存管理单元）和页表。
流程大致是：CPU执行指令，发现要访问一个虚拟地址，于是把这个虚拟地址发给MMU。MMU先查TLB（快表），TLB是页表项的高速缓存，命中的话直接在硬件层面翻译成物理地址，访问内存。TLB未命中，MMU就得去内存里查多级页表，找到对应的物理页帧号，完成翻译，同时把结果填进TLB，方便下次快速命中。
如果页表里根本没有这个虚拟地址对应的映射，或者权限不对，就会触发缺页异常或保护异常，操作系统接管，决定是给这个进程分配一个物理页、从磁盘加载文件页、还是直接判定程序违规并杀掉。整个过程高速且低调，你很难直接感知到，但它每时每刻都在发生。
4.2 多级页表为什么能省这么多内存
页表如果只做一层，一个48位地址空间、4KB页面，需要的页表项数量会是天文数字。所以x86-64用的是四层页表，从PGD、PUD、PMD到PTE，每一级只索引一部分地址位。这种层级结构最大的好处是稀疏，进程的地址空间哪怕再大，只有真正用到的那些区域才需要分配页表页。
初次接触多级页表的人，总觉得这岂不是每次访问内存都要查四五次表？其实TLB就是干这个的，命中率通常高达99%以上。再加上CPU的硬件预取机制，多级页表带来的性能代价大部分都被掩盖掉了。
4.3 缺页中断不只是“内存不够了”
缺页中断听起来像错误，其实它是Linux内存管理里最忙碌的正常流程。一个新进程启动，它的代码段并没有全部加载进物理内存，是执行到哪一页才通过缺页中断把对应页从磁盘加载进来。一个文件刚刚被mmap，你没有访问它时它可以在磁盘上待着，只有读它时才一页页进内存。这是读写文件高性能的重要支撑。
缺页还分好几种：匿名页缺页，内核直接从伙伴系统分配物理页并清零；文件映射缺页，内核把对应文件内容读进页缓存；写时复制缺页，比如fork之后父子进程共享同一个只读物理页，一旦有人要写，就会触发缺页复制出一份，实现内存隔离。理解了缺页机制，你再去看那些“运行得很慢但CPU占用不高”的程序，思路会清晰很多。
5. 开发中最常遇到的内存问题和排查办法
5.1 程序报错内存不够，但这台机器明明还有空闲内存
这种场景很多人遇到过。程序执行malloc或mmap失败，返回NULL，但用free一查物理内存还有大把。原因往往是这几个方向：
第一，进程的虚拟地址空间用完了，比如32位进程；第二，进程的RLIMIT_AS被设了限制，你可以用ulimit -v看一下，如果输出不是unlimited，虚拟内存上限就被限制了；第三，系统启用了vm.overcommit_memory=2这种严格模式，物理内存加上交换空间不足以覆盖所有进程承诺的虚拟内存时，分配也会失败。
排查这类问题，不要停在“内存是否够”的层面，要多问几个为什么。先用cat /proc/<pid>/status看VmSize和VmRSS，再看ulimit -a，然后看/proc/meminfo里的CommitLimit和Committed_AS。大多数“还有内存却分配失败”的问题，都能在这里找到答案。
5.2 段错误不一定是空指针，也可能是访问了“不属于你的地址”
段错误（segmentation fault）最常见的直接原因，是指针访问了没有映射的虚拟地址，或者映射了但权限不够。它不一定是解引用了NULL，也可能是栈溢出碰到未映射的守卫区，或者写了只读的代码段，或者用越界指针访问了映射区域之间的空洞。
用gdb调试时，你可以在崩溃点用info registers看指令地址和访问地址，再对照info proc mappings，看它落到了哪个区间。如果落在未映射区域，基本就是野指针或者越界访问；如果落在只读区域，就是写入了不该写的地方。通过这种方式定位段错误，比单纯看报错日志高效得多。
5.3 排查内存问题要用到的小工具集
我日常排查内存问题，会交替使用这几样：strace追踪系统调用，看mmap、brk是否有异常；pmap看RSS分布，/proc/<pid>/status看整体指标，gdb看调用栈和变量，valgrind查内存泄漏和越界访问。内存泄漏类问题用valgrind最稳，但性能开销极大，不适合生产环境长时间跑；生产环境更适合用pmap持续采集RSS做趋势分析。
这里分享一个我自己用得比较多的排查手法：连续采集某个进程的/proc/<pid>/maps和/proc/<pid>/status，每三秒一次，观察哪个区域的总大小在持续增长。如果堆在涨，说明是malloc没有配对free；如果某个共享库映射区域在涨，可能动态加载了什么东西；如果栈在涨，要小心是不是递归没有终结条件。这比凭空猜测高效得多。
5.4 面试中常见的几个坑
面试时聊到虚拟地址空间，考察点通常集中在：用户态和内核态的划分、虚拟地址和物理地址的映射关系、页表结构、缺页中断、以及为什么64位下虚拟地址空间依然可能成为瓶颈。有几个容易踩的坑我提一下：不要把free的空闲内存理解成“一定可以给进程用”，因为还有个overcommit策略在把关；也不要把程序的RSS理解成进程占用的全部内存，因为共享库和共享内存可能有多个进程共摊；更不要以为页表可以无限膨胀，一个进程如果映射了大量区域，页表本身也会吃掉不少物理内存。
5.5 生产环境里的“虚拟内存大但RSS小”正常吗
经常有人问：为什么我的JVM或Nginx显示虚拟内存占用好几十GB，但RSS只有几百MB，是不是内存泄漏？大多时候不是。这部分差异主要来自两类映射：一类是mmap了文件但不全部访问，另一类是内存预分配但没触碰。比如JVM用-Xmx配置堆大小，经常预留大块地址空间但只提交部分物理页。这种情况应该看RSS趋势，而不是死盯虚拟内存大小。
但也不要放松警惕。有些程序确实会不断增长虚拟地址空间且不回收，比如反复mmap不munmap。这种问题在64位系统上更容易积累，因为地址空间很大，一时半会不会崩溃，等到真的没有地址可映射时，游戏就结束了。生产环境还是要建立监控，不只盯物理内存，也要盯虚拟地址空间的增长速度。
6. 常见问题速查表与实操心得
| 问题现象 | 可能原因 | 排查思路 |
|---|---|---|
| 进程malloc返回NULL，物理内存还有空余 | 32位进程地址空间耗尽，或ulimit -v限制，或overcommit策略过严 | 查看/proc/<pid>/status的VmSize，执行ulimit -v，检查/proc/meminfo的CommitLimit |
| 程序崩溃，gdb显示访问0xffff...地址 | 访问了未映射的内核地址段或非规范地址 | 结合info proc mappings确认访问区域范围，检查野指针和栈溢出 |
| VmSize持续暴涨，但RSS不怎么变 | 大量mmap映射未释放，或预留大块虚拟内存 | 批量采样/proc/<pid>/maps，找出持续新增的映射区域，在代码里定位对应操作 |
| RSS持续增长，内存最终耗尽 | 堆内存泄漏，或缓存/文件映射异常增长 | 用pmap -x看RSS来源，用valgrind辅助定位泄漏点 |
| 栈溢出后程序并无明显崩溃点 | 递归过深、局部数组过大，访问落到未映射的栈守卫区 | gdb查看调用栈，关注info proc mappings中栈段地址附近的保护页 |
| 多进程共享内存后RSS偏高 | 共享内存映射在多个进程的页表中都有映射 | 用pmap观察共享库和共享匿名映射的实际RSS，确认是否异常增长 |
这里再分享几条实操心得。
第一，给进程配置内存时，先确认它跑在32位还是64位环境。很多老程序迁移到64位后，把编译参数带上-m64，整个内存问题就豁然开朗。
第二，监控进程内存时，建议同时记录VmSize、VmRSS和RSS（从smaps里累加算出更精确的值）。只看其中一个指标很容易被误导。地址空间和物理内存是两码事，谁先耗尽都会要命。
第三，刚学虚拟地址空间时，一定要亲手跑一遍malloc实验，观察maps和status的变化。有了这个直观认知，后面所有关于内存隔离、按需分配、缺页中断的讨论，你才能接得住。
虚拟地址空间这块内容，理解到一定程度之后，你再看Linux内核、KVM虚拟化、容器内存隔离这些方向，都会顺很多。它不是单独的一个知识点，而是把进程管理、内存管理、文件系统、设备驱动串起来的一条暗线。反复读这两三遍，再结合实际排查几次内存问题，算是彻底入门了。
