你的进程从来没有＂真正拥有＂内存——Linux 虚拟内存的底层真相

上一篇我们讲了 free -h 的正确读法，以及为什么 buff/cache 占用高不代表内存不足。这篇想再往深一层：你知道 Linux 进程以为自己独占了整块内存，但这其实是内核给它的一个"幻觉"吗？理解了这个幻觉背后的机制，你对 ps 里那些让人困惑的内存数字，会有完全不同的理解。

一、一个让人困惑的数字对不上的场景

服务器上运行着十几个进程，你用 ps 把它们的内存占用加一遍：

ps aux --sort=-%mem | awk 'NR>1 {sum += $6} END {print sum/1024 " MB"}'

结果显示：所有进程的内存占用加起来超过了 20GB。

但是 free -h 告诉你，机器一共才 16GB 物理内存。

进程说自己用了 20GB，机器只有 16GB，这不是矛盾吗？内存从哪来的？

这个"对不上"的背后，是 Linux 内存管理最核心的设计之一：虚拟内存（Virtual Memory）。

二、每个进程都活在自己的"幻觉"里

在 Linux 里，进程看到的内存地址，不是物理内存的真实地址，而是一套内核专门给它构造的虚拟地址空间。

可以这样理解：每个进程都以为自己独占了一大块连续的内存，从地址 0 一直排到几百 GB，可以任意使用。但这个"几百 GB"，大多数时候根本不对应真实存在的物理内存页——它只是内核登记在册的一个地址空间承诺，只有当进程真正去访问某个地址时，内核才会去实际分配物理内存页，把虚拟地址和物理地址建立映射关系。

这套映射关系由内核维护，数据结构叫页表（Page Table）。每次 CPU 访问一个内存地址，硬件会自动查页表，把虚拟地址翻译成物理地址，整个过程对进程完全透明，进程完全感知不到这一层转换的存在。

这也解释了为什么 ps 里有两个不同的内存数字：

• VSZ / VmSize（虚拟内存大小）：进程向内核"声称要用"的地址空间总量，包括申请了但还没真正使用的部分、内存映射的文件、共享库等，这个数字通常很大，有时大得离谱。
• RSS / VmRSS（常驻内存大小）：进程实际占用的物理内存页数量，这才是它真正"花掉"的物理内存。

新手常见的误区：看到 VSZ 很大就以为内存快不够用了。实际上，VSZ 大不代表任何问题，它只是地址空间的账面数字；真正决定物理内存压力的是 RSS。

三、Linux 为什么敢"超卖"内存

理解了虚拟内存，下一个问题就来了：既然进程申请的虚拟内存可以远超物理内存，内核凭什么敢答应它？万一进程真的要用那么多，怎么办？

Linux 内核的答案是：内存超卖（Memory Overcommit）。

内核默认允许进程申请远超物理内存的地址空间，背后的逻辑是一个现实经验：大多数进程申请的内存，实际上用不完。 就像航空公司会卖出比座位数更多的机票，因为历史数据告诉他们，总有一部分乘客不会出现——内核也赌大多数进程的内存申请是"虚报"的。

这个行为由内核参数控制：

cat /proc/sys/vm/overcommit_memory

有三个取值：

• 0（默认）：启发式超卖，内核自己判断要不要答应，通常都会答应
• 1：无条件答应所有内存申请，申请多少给多少（虚拟地址空间）
• 2：严格模式，不允许超卖，总虚拟内存不得超过物理内存 + Swap 的一定比例

生产环境里大多数场景用默认的 0 就够了。只有对内存分配失败极其敏感的场景（比如某些金融系统），才会考虑调整为 2，代价是很多正常的大内存申请会直接失败。

四、fork() 为什么这么快：写时复制的秘密

虚拟内存的另一个巧妙应用，是 Copy-on-Write（写时复制，CoW）。

当你执行 fork() 创建一个子进程时，理论上需要把父进程的整块内存完整复制一份给子进程——如果父进程占了 2GB 内存，复制一次就是 2GB 的拷贝操作，这会很慢。

但实际上，Linux 的 fork() 几乎是瞬间完成的，原因就是写时复制：

fork() 之后，父子进程共享同一套物理内存页，内核只是给子进程复制了一份页表，让子进程的虚拟地址也映射到同一批物理页上。 只有当父进程或子进程真正去写某个内存页时，内核才把那一页单独复制出来，分给写操作方一个独立的副本，其余未被修改的页依然共享。

这也解释了为什么 Shell 里启动一个进程（先 fork() 再 exec()）可以如此轻量——绝大多数父进程的内存页根本不需要真正复制，直到子进程开始往里写才会按需拆分。

写时复制同时解释了另一个现象：刚 fork() 完的父子进程，RSS 加起来看起来远超实际物理内存占用，因为它们在共享同一批物理页，ps 对每个进程单独统计 RSS 时，这批共享的页会被重复计算进去。这正是为什么"把所有进程的 RSS 加起来"会超过物理内存总量，而不是进程真的用了那么多物理内存。

五、/proc/meminfo：比 free 更详细的内存快照

上一篇提到了 /proc/meminfo，这里重点讲几个 free -h 里看不到、但排查问题时很有用的字段：

cat /proc/meminfo

几个关键字段：

MemTotal:       16384000 kB    # 物理内存总量MemFree:          524288 kB    # 完全空闲的内存MemAvailable:    2883584 kB    # 实际可用（含可回收缓存），对应 free -h 的 availableBuffers:          131072 kB    # 块设备缓冲（文件系统元数据）Cached:          2621440 kB    # 文件内容页面缓存SwapCached:           0 kB    # 换出后又换回、仍在 Swap 备份的页Active:          8388608 kB    # 最近被访问过、不太可能被回收的页Inactive:        2097152 kB    # 长时间未访问、可以优先被回收的页Dirty:            65536 kB    # 已修改但尚未写回磁盘的"脏页"Writeback:            0 kB    # 正在写回磁盘的页Slab:            524288 kB    # 内核数据结构占用的内存（slab 分配器管理）

几个排障时特别有用的字段：

Dirty（脏页）：内存里已经被修改、但还没来得及写回磁盘的数据量。系统 I/O 压力很大时，脏页会积累。如果你发现磁盘写入突然出现尖峰，很可能是内核在集中把大量脏页刷回磁盘（这个行为由 vm.dirty_ratio 等参数控制）。

**Slab：内核内部的数据结构（目录缓存、inode 缓存等）占用的内存。在文件数量极多的系统上（比如存储大量小文件的服务器），Slab 可能会占用几 GB 甚至更多，而且这部分内存不会被计入 buff/cache**，free -h 里看不出来。如果你发现 available 持续下降但找不到对应的进程，可以看看 Slab 是不是在增长：

# 实时监控 Slab 占用变化watch -n 2 "grep -E 'Slab|SReclaimable|SUnreclaim' /proc/meminfo"

• SReclaimable：Slab 里可以被回收的部分（主要是各种缓存）
• SUnreclaim：Slab 里不可回收的部分（正在使用的内核数据结构）

如果 SUnreclaim 持续增长，通常意味着内核层面有资源泄漏，需要更深入地排查。

六、vmstat：用一张实时表读懂内存的动态

free 给你看的是一个静态快照，**vmstat 给你看的是动态趋势**——它每隔固定时间打印一行，让你看到内存、Swap、I/O、CPU 的变化走势，而不是只看某一个瞬间的值。

vmstat 2

输出每 2 秒刷新一行，格式大概是：

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 1  0      0 524288 131072 2621440   0    0     5    20  150  300  5  2 92  1  0

内存排障时重点看这几列：

• **swpd**：Swap 已使用量，持续非 0 且在增长 → 物理内存真的不够了
• si（swap in）：每秒从 Swap 换入物理内存的数据量
• so（swap out）：每秒从物理内存换出到 Swap 的数据量

si 和 so 持续非 0，是内存真正告急最直接的实时信号，比 free -h 里看 available 更能反映动态压力——available 可能还有一两 GB，但如果 so 已经持续在往 Swap 里写，说明系统正在预防性地腾出物理内存，离真正吃紧不远了。

七、一张图串起所有概念

进程视角（虚拟地址空间）         内核视角（物理内存管理）┌─────────────────────────┐      ┌──────────────────────────┐│  进程 A 的虚拟地址空间    │      │  物理内存                  ││  VmSize: 10GB           │ ──→  │  进程A真实占用 (RSS): 500M ││  （大部分是"空头支票"）   │      │  进程B真实占用 (RSS): 800M │└─────────────────────────┘      │  buff/cache: 6GB          │┌─────────────────────────┐      │  （随时可回收）             ││  进程 B 的虚拟地址空间    │      │  free: 512M               ││  VmSize: 8GB            │ ──→  ├──────────────────────────┤│                         │      │  Swap（磁盘）              │└─────────────────────────┘      │  换出的冷数据（慢）         │                                 └──────────────────────────┘

结论：

• VSZ / VmSize 大：不是问题，只是"账面数字"
• RSS 之和 > 物理内存：正常，因为共享页被重复计算
• available 低 + si/so 非零：真正的内存告警
• Slab SUnreclaim 持续增长：内核级资源泄漏，需要深查

写在最后

Linux 的内存管理，本质上是内核在"物理内存有限"和"进程对内存的无限需求"之间做的一套精密的调度和幻觉制造——虚拟地址空间让每个进程以为自己独占内存，写时复制让 fork() 几乎无代价，超卖机制让大量进程共存成为可能。

这套设计极其精妙，但也确实让"内存够不够用"这个问题变得不那么直观。理解了这套底层逻辑之后，面对 ps 里让人迷惑的数字、面对 free 里几乎为零的 free 列，你应该不会再被这些表象带偏了。

你有没有遇到过"Slab 把内存悄悄吃掉"或者"进程 VSZ 大得离谱"这类情况？排查的时候最后是怎么定位出来的？欢迎在评论区聊聊。