一文吃透 Linux 和 Windows 虚拟内存:从页表到换页,真正在生产里怎么跑

我这篇就不搞什么“故事开头”“面试八股”，直接开干。
虚拟内存这个东西，大家都听过，但真到线上一出 “内存爆了”“swap 狂飙”“某进程 OOM 了”，很多人第一反应还是重启。
重启不是不行，就是丢人，而且问题也没解决。

这次我想把自己这几年在 Linux 和 Windows 上折腾虚拟内存踩过的坑掏一遍，按“问题—机制—实战”这么个路子说，说着说着可能会跑题，不过也算是我平时排障的真实思路。

虚拟内存到底在忙啥：别被概念吓住

先把话说明白：虚拟内存这玩意，本质就是用一层“中间地址”把进程看到的地址和真实物理内存隔开。

为啥要隔开？

• • 让每个进程觉得“我一个人独占全部内存”，互相别踩；
• • 方便做内存保护，某进程乱写不至于把整个系统写挂；
• • 物理内存不够时，把一部分丢磁盘上，尽量保证程序还能跑。

Linux 也好，Windows 也好，都是干这几件事，只是细节上差别挺多。
运维日常遇到的那些 “page cache 占满”“commit charge 爆了”“swap 抖动” 之类现象，全和这些细节有关。

内存管理方式：段表、页表，Linux 和 Windows 路子不太一样

当年 32 位时代，段式、页式这些词经常一起出现。简单说：

• • Windows 走的是“段+页”结合的路子，用段表（Segment Table）再套页表；
• • Linux 基本可以当它就是“纯分页”，段那层用得很轻。

现在 64 位时代，大家更偏向统一平坦地址空间，但历史包袱还在，行为上还是能看出差异。

1. Windows：段+页，虚拟地址拆两层

Windows 下一个虚拟地址要经过两步：

1. 1. 段表：先看这个地址属于哪段（Code/Data/Stack……）；
2. 2. 页表：再把该段里的偏移映射到物理页框。

对我们运维来说，这里有两个点要记：

• • Windows 上的每个进程地址空间划分得比较“规范”：代码段、堆、栈、PE 映射区等都有固定策略；
• • 某些安全机制（比如 DEP、ASLR）也是在段级别配合页属性一起玩的。

2. Linux：直接“页式”，段几乎被弱化

Linux 这边就简单粗暴很多：

• • 直接用页表来管全部虚拟地址；
• • 段寄存器基本一套平坦映射，进程看到的 0 ~ TASK_SIZE 一整片逻辑上都在用户空间，以上是内核空间。

为什么我们 top 里经常能看到进程虚拟内存动辄几个 G，甚至几十 G？
就是因为 Linux 在虚拟地址这块特别“豪横”，管你物理上有多少，先映射再说，真正用到时再分配物理页。

这也导致 Linux 上经常出现那种：

• • VIRT 巨大，RES 不大；
• • 高并发的服务申请了大量虚拟地址但没真用，commit 过载时就会 OOM。

Windows 上也有类似概念，只是表现形式不太一样，后面讲。

虚拟地址空间布局：32 位和 64 位的差别，别搞混

很多人看 Linux 的 /proc/<pid>/maps 或者 Windows 的 VMMap 截图，会发现地址空间是块状的，用户区、内核区、堆、栈、mmap 区，挤得满满的。

1. 32 位时代：地址空间真不够用

32 位 CPU 能寻址的最大空间是 4G，这 4G 还要用户和内核分。

常见配置：

• • 32 位 Windows：用户空间默认 2G，内核 2G；
  有种 /3GB 开关，可以把用户空间扩大到 3G，内核 1G，但稳定性要打折;
• • 32 位 Linux：默认 3G 用户 + 1G 内核，是经典配置。

这事对运维有什么影响？
比如老旧 32 位系统上跑 Java / Oracle，这种进程自己就想要好几个 G 堆，结果地址空间都不够，连启动都费劲。

我以前遇到一个 Windows 2003 + 32 位 Oracle 的老系统，某天业务加了点数据，实例重启直接起不来，报错内存不足，最后一看，纯属地址空间撑爆了，物理内存还剩一堆。
那次之后我对“虚拟地址空间”这个概念算是记死了。

2. 64 位之后：空间多得是，但坑还在

64 位下的理论空间大到离谱，不过 OS 和硬件都会限制几级页表，实际有效的也足够夸张。

典型配置：

• • 64 位 Windows：用户空间可以很大，内核也独立一块；
• • 64 位 Linux：用户和内核也各有区域，内核空间比 32 位更灵活，比如可以映射更多物理内存、巨页等。

有同事看到 Linux 上 VIRT 动辄几十 G 就慌，我的经验是：

• • 只要 RES（常驻集）还合理，swap 不怎么动，就别太紧张；
• • 真正要警惕的是 commit（overcommit）和 swap 抖动，而不是单纯虚拟地址数值。

交换空间（Swap）：Linux 的 swap 分区 vs Windows 的 pagefile.sys

虚拟内存说来说去，离不开一个关键词：换页。
物理内存不够时，OS 把不常用的页写到磁盘，再需要时再读回来，这个过程就是大家经常骂的 “swap”。

1. Windows：pagefile.sys 做后盾

Windows 用的是页面文件 pagefile.sys：

• • 默认放在系统盘根目录，系统自动调整大小；
• • 也可以配置多个磁盘上的 pagefile，分散 IO 压力；
• • 任务管理器里看到的 “提交的内存（Committed）” 就是虚拟内存的一个侧写：物理 RAM + pagefile。

实际排障时，我比较关注：

• • Commit charge 接近 Commit limit 时，系统就危险了；
• • 大量 page fault / 磁盘飙高，说明在疯狂换页，用户感受就是“卡成 PPT”。

我有一次帮人看一台 Windows 文件服务器，32G 内存，结果 pagefile set 成了 1G，某个备份进程一跑，commit 立刻顶满，系统开始疯狂杀进程，连 RDP 都连不上。
最后把 pagefile 设置为自动，commit limit 上去了，系统就稳多了。

2. Linux：Swap 分区 / Swap 文件两种形态

Linux 更灵活：

• • 可以用独立的 swap 分区；
• • 也可以用普通文件做 swap（swapfile），用 mkswap + swapon 搞定。

几个点我踩过的坑：

• • 纯粹“禁用 swap”不一定是好事，有时反而容易触发 OOM；
• • swap 盘最好别和高 IO 的数据盘混一起，容易互相拖垮；
• • 云服务器上默认 swap 很小甚至没有，这时候 OOM 比较常见，要结合业务需求加 swap 或调 overcommit。

生产里我一般：

• • 给核心服务适当保留一点 swap，当成“缓冲垫”；
• • 监控 swap in/out 指标，一旦持续 swap in/out，就说明内存压力持续偏高，要么加内存，要么调业务。

内存映射文件（mmap / Memory Mapped Files）：性能优化的利器

虚拟内存除了用来“救急”，还有一块经常被忽略，就是内存映射文件。

1. Windows：Memory Mapped Files

Windows 提供了 CreateFileMapping / MapViewOfFile 这一套：

• • 可以把一个文件直接映射进地址空间；
• • 进程像访问内存一样读写文件，OS 负责后台把脏页刷到磁盘；
• • 多进程还能共享同一块映射区，实现共享内存。

实战里：

• • 某些数据库、缓存系统用这招减少用户态和内核态的数据拷贝；
• • 日志组件、文件缓存也会利用内存映射加速 IO。

如果你在 Windows 上看到一个进程 Working Set 很大，但磁盘读写并不多，很可能就是用了大规模的 memory mapped file。

2. Linux：mmap 系统调用

Linux 下就是 mmap：

void* addr = mmap(NULL, length, PROT_READ | PROT_WRITE,
                  MAP_SHARED, fd, 0);

运维侧可以从 /proc/<pid>/maps 里看到映射的文件路径：

• • 某些大文件（比如日志、数据库文件）直接被映射进来；
• • 库文件 .so 也是以映射方式加载的，读写共享。

这块对我们排障的重要意义在于：

• • RES 里面包含了这些映射文件占的页；
• • 但是这些页往往可以被回收（因为有磁盘后备），所以别看到大 RES 就慌，要看 RSS、anon 等更细的指标。

页面置换策略：LRU、Working Set，各家有各家的小心思

物理内存有限，哪些页留着，哪些丢掉？
这里就是不同操作系统“性格”的差异所在。

1. Windows：Working Set 模型

Windows 里有个概念叫 Working Set：

• • 对每个进程维护一个“当前常住的页集合”；
• • 会根据系统整体压力动态调整每个进程的 working set 大小；
• • 压力大时，系统会“修剪”某些进程的 working set（trim），把不常用的页挤出去。

任务管理器里看到的 “Working Set (Memory)” 基本就是这个概念。

这会带来一些有意思的现象：

• • 有时你会发现进程刚启动时占用很高，过一会儿自动降下来，就是系统在收紧它的 working set；
• • 某些后台进程长时间不用，页被回收了，再唤醒时会有一波 page fault，短暂“卡一下”。

2. Linux：LRU 等回收算法

Linux 常见说法是“LRU”（Least Recently Used），实际上现在内核里的算法比纯 LRU 复杂多了，不过我们可以这么粗略理解：

• • 把页分成 active / inactive 两大链表；
• • 最近访问过的放 active，久未访问的慢慢滑到 inactive；
• • 回收时从 inactive 列表上优先扫，避免把热点页踢出去。

此外还有：

• • 匿名页（进程堆栈等）和文件页（page cache）分开统计；
• • 后台线程 kswapd 负责内存回收，必要时触发 direct reclaim。

我们在监控里经常会看到：

• • page cache 一路涨，直到内存压力上来，内核开始回收 cache；
• • 如果 cache 回收不够，就会涉及匿名页，系统可能变卡，最终走到 OOM。

一旦 you see：

dmesg | grep -i oom

出现 OOM killer 日志，说明内核已经开始杀进程自救了。
这个时候再骂“Linux 内存管理垃圾”其实也没啥用，更多是你业务超出了机器承载。

TLB：虚拟地址到物理地址的“加速高速缓存”

说到虚拟内存，就离不开 TLB（Translation Lookaside Buffer）。

简单粗暴解释：

• • 页表在内存里，要查一次虚拟地址 -> 物理地址，需要访问内存；
• • TLB 是放在 CPU 里的一个小缓存，专门缓存最近用过的虚拟地址到物理地址的映射；
• • 命中 TLB，就省去了查页表的开销。

不同操作系统在处理 TLB 失效（TLB miss）时策略不一样，比如上下文切换时要不要 flush TLB，怎么标记 ASID 等，这些细节对于我们这种运维一般不需要太深入。
不过有个点还是很实在：

• • 大量随机访问 + 大内存 + 小页（4K）时，TLB 压力会很大；
• • 使用 HugePage（大页，比如 2M）可以减少 TLB 压力，提高命中率。

这也就是为什么一些数据库、中间件都建议配置 HugePage / Large Page 的原因。

内存保护：别让一个进程把全系统写挂

虚拟内存还有一个大用处是内存保护：

• • 每个页都有访问权限：读、写、执行；
• • 进程不能随便访问不属于自己的页；
• • 操作系统在页表里标记各种属性，有问题就触发异常（段错误、访问冲突）。

Linux 下常见的是 Segmentation fault，Windows 下是 Access Violation。

对我们运维来说：

• • 程序频繁崩溃，日志里满是 segfault/0xc0000005 之类的错误，很多时候是越界访问、非法指针；
• • 也可能是 DEP / SELinux / ASLR 之类安全机制挡住了奇怪的行为。

这块更多是开发要修，但我们至少要知道：
不是所有崩溃都是“内存不足”，有些是“乱写被 OS 当场抓住”。

高低端内存：32 位时代的历史遗留问题

这里提一个很多新同学都没怎么碰过的概念：高端内存。

主要出现在 32 位 Linux 时代：

• • 低端内存：直接映射到内核空间，内核可以直接用线性地址访问；
• • 高端内存：需要通过临时映射才能访问，管理起来麻烦一些。

原因就是内核空间只有 1G/2G 的那一小块，还要同时映射设备、内核自身、各种缓存，物理内存一多就映射不过来。

如今大多数生产都 64 位了，这事影响不大，不过如果你还在维护一些特别老的系统，这个概念会在 dmesg 里频繁出现。

Linux / Windows 的内存回收：谁在背后默默“扫地”

内存回收这块，是运维最容易感知到系统“性格”的地方。

1. Linux：kswapd + direct reclaim + OOM killer

Linux 的回收链路大致是：

1. 1. 背景线程 kswapd 定时扫描页，回收不常用的；
2. 2. 当某个进程申请内存时发现不够，可能触发 direct reclaim，自己现场打扫；
3. 3. 还不够，就会走到 OOM killer，从一堆进程里挑几个“贡献”出来。

你可以从这些地方观察：

• • /proc/meminfo 里的 SwapCached, Dirty, Writeback, Active, Inactive 等；
• • vmstat 1 看 si/so（swap in/out）、cs（上下文切换）、wa（IO 等待）；
• • dmesg 里 OOM 日志。

有一次某平台的批处理任务跑着跑着，突然一批服务集体挂，监控上看 CPU 并不高，就是 load 高得离谱，磁盘 IO 爆，最后查下来：
那段时间大量任务堆积，内存吃满了，系统开始疯狂 reclaim + swap，最后扛不住 OOM，把几个大进程干掉了。
那次之后我们在批处理集群上专门做了内存水位限流和 swap 监控。

2. Windows：内存管理器 + Standby List + Working Set Trim

Windows 这边的逻辑则是：

• • 把内存分成多个列表：active、standby、free 等；
• • 不常用的页会被放到 Standby List，需要时可以立即再用；
• • 内存紧张时，会尝试压缩、修剪各进程的 working set；
• • 最后实在不行，才会开始大量写 pagefile，系统就明显卡。

任务管理器 / 资源监视器 / RAMMap 这些工具，其实就是把这些列表可视化出来。
比如 RAMMap 里 Standby List 特别大时，系统整体还算健康；
一旦 Standby 也被吃光，Free 几乎为 0，而且 pagefile 写得飞快，那就是真的紧张。

虚拟内存的几个典型坑，顺带聊几个案例

这里随手列几个我见得比较多的坑，算是和大家共勉。

1. 以为 “禁用 swap” 就很专业

很多刚上手的同学，装完 Linux 第一件事就是关 swap，理由是“swap 会拖慢系统”。

结果：

• • 内存一紧张，没地方缓冲，只能直接 OOM；
• • 某些后台进程、日志收集器之类最先被杀，问题更加难排。

我现在的习惯：

• • swap 不要太大，但也别完全没；
• • 核心服务可以通过 oom_score_adj 调低被杀的优先级；
• • 监控 swap 使用率，一旦持续高位，就需要加内存或做限流。

2. 误解 page cache：看到 cached 就紧张

Linux 上 free 输出里 cached、buff/cache 很高，其实大多是好事：

• • 说明系统充分利用空闲内存做文件缓存；
• • 一旦有新进程需要内存，cache 是可以被回收的。

我见过有人看到 free 输出里 used 90%+，立刻加 swap 再重启，结果没必要。
真正要担心的是：

• • buff/cache 被吃掉，available 很低；
• • swap in/out 持续升高；
• • OOM 日志出现。

3. Java / .NET 类进程的堆设置与系统虚拟内存冲突

另外一个经典坑：

• • 开发把 JVM 堆设得很大，比如 8G；
• • 机器总内存也就 8G，系统和其他进程也要吃；
• • 结果一上负载 JVM 还没吃满堆，系统已经在 swap / OOM 了。

这类问题在 Windows、Linux 上都见过。
解决思路无非：

• • 要么给进程一个相对合理的堆上限；
• • 要么给机器多加点内存；
• • 或者拆进程，别所有服务堆在一台上。

写在最后的几句废话

虚拟内存这块，说白了是在软件层面补硬件资源的短板，同时又帮我们做了隔离、安全、性能优化这些事。
Linux 和 Windows 的设计理念不一样，表现出来的各种指标也不完全相同，但只要抓住几个核心点：

• • 虚拟地址 vs 物理地址；
• • 页表 / TLB；
• • swap / pagefile；
• • 回收策略（LRU / Working Set）；
• • 各种监控指标怎么读；

很多“看起来玄学”的现象，其实都能解释得清清楚楚。

我这边写的东西比较散，就是平时查问题、踩坑时积累下来的那点体会，能帮你少重启几次机器就算没白写。
以后有机会还会单独拆开，比如专门写一篇“如何系统分析 Linux OOM”和“Windows 内存泄漏排查实战”，就不挤在这一篇了。

如果你看到这里还没睡着，那咱算有点缘分。
欢迎把这篇文章转给身边还在为 “内存爆了怎么办” 头大的同事，也欢迎在评论区说说你碰到过什么奇葩的虚拟内存问题，大家一起交流。

想系统看我后续的运维实践文章，记得关注一下 @运维躬行录，别走丢了。

公众号：耕云躬行录
个人博客：躬行笔记