元宿six我最早接触内存映射文件，是因为一个非常头疼的线上问题：服务通过普通 read 循环读取一个接近 2GB 的关键数据文件，进程 CPU 占用一直不高，但加载耗时超过 40 秒，而且一旦并发读取，磁盘 IO 居高不下，性能抖动特别明显。后来换成 mmap 方案，首次加载降到 1 秒以内，后续访问甚至能接近内存速度，整个服务的瓶颈直接消失。
这篇文章就围绕“内存映射文件高级用法”展开，内容不限于最基础的 mmap 调用，而是把内核原理、共享内存、写时复制、预读调优、进程间通信、避坑经验一起串起来讲。适合对文件 IO、性能优化、系统编程有一定基础，但想系统掌握内存映射文件底层机制和实战技巧的开发同学。哪怕你之前只听说过 mmap 这个名字，我也尽量用大白话把底层逻辑讲透。
1. 内存映射文件到底是什么：从一次性能排查说起
1.1 一个真实的性能瓶颈
先回到那个数据库加载的场景。当时的数据文件结构很简单，是一份按 key 排序的索引快照，文件内部有固定大小的记录，每条记录 256 字节。加载逻辑也简单：打开文件，read 到内存，解析成哈希表，然后对外提供服务。
问题是这样的：文件 2GB，堆内要再复制一份，老年代压力大；加载过程涉及用户态缓冲区和内核 page cache 之间的一次次拷贝；加载完成后，那份原始缓冲区内存还要等 GC 回收。整个流程浪费在“重复拷贝”上，而且文件越大，浪费越明显。
后来把方案改成 mmap：把整个文件直接映射到进程地址空间，不需要一次性 read，也不需要维护一份显式的堆内副本，需要访问哪条记录，就让内核按需加载对应页。效果立竿见影，加载时间从 40 秒级别降到了几百毫秒级别，GC 压力也基本消失了。
1.2 内存映射的核心原理
内存映射文件的核心，是把“文件”和“内存”统一成同一套页面管理机制。传统 read 的路径是：磁盘 → 内核 page cache → 用户态缓冲区，每次读取都涉及一次 CPU 拷贝。而 mmap 做的事情，是在进程的虚拟地址空间里划出一块区域，把这区域的页表项直接关联到文件在 page cache 中的页。
举个例子，你映射了一个 1MB 的文件，进程地址空间里就多了一段长度 1MB 的区域。但你访问第 0 页时，如果该页不在内存里，内核会触发缺页异常，随后从磁盘读取对应文件的对应页，填入 page cache，再更新页表映射。这个过程对用户程序是透明的。好处很明显：用户态看不到重复缓冲区，内核的 page cache 就是你的“内存”。
这个过程可以用一个生活类比来理解：传统 read 相当于你要读一本书，每次都得从书架上把整本拿下来，然后把需要的章节手工抄到笔记本上；而 mmap 相当于你把书架直接搬到眼前，想看哪一页，手指翻到哪一页就行，书页本身不需要抄走，内核替你做好了书签。
1.3 一次映射的完整生命周期
一次完整的 mmap 生命周期通常包括几个阶段：打开文件、创建映射、访问映射区域、同步修改、解除映射。
- 打开文件，获取文件描述符 fd。
- 调用 mmap，指定映射长度、保护模式、映射标志、fd 和偏移量。
- 访问映射区域，例如直接通过指针读写。
- 如果有写入且需要持久化，调用 msync 把脏页刷回磁盘。
- 使用完毕，调用 munmap 解除映射。
这个流程中最容易出问题的点是：映射长度、文件实际大小、系统页大小三者之间的关系。很多人第一次写 mmap 代码，会想当然地认为映射长度等于文件长度就好，但如果长度不是页大小（通常 4096 字节）的整数倍，内核会多映射出半个页，而访问超出文件实际大小的部分，就可能触发 SIGBUS，这个后面详细讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 基础用法与四个最关键参数
2.1 创建映射的完整流程
在 Linux 上，mmap 的系统调用原型是：
c复制void *mmap(void *addr, size_t length, int prot, int flags,
int fd, off_t offset);
一个最常见的只读映射是这样写的：
c复制#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main() {
int fd = open("data.bin", O_RDONLY);
if (fd < 0) {
perror("open");
return 1;
}
struct stat st;
fstat(fd, &st);
size_t length = st.st_size;
char *addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, 0);
if (addr == MAP_FAILED) {
perror("mmap");
close(fd);
return 1;
}
char first = addr[0];
printf("first byte: %c\n", first);
munmap(addr, length);
close(fd);
return 0;
}
这里有几个隐藏细节值得展开：
第一，addr 一般传 NULL，让内核选择合适地址。如果想指定地址，必须满足页对齐，否则直接报 EINVAL。
第二，offset 必须是页大小整数倍。这源于页表映射的粒度限制。页大小通常可以通过 sysconf(_SC_PAGESIZE) 获取，一般 x86_64 Linux 上是 4096，但不是所有平台都这样。
第三，length 如果为 0，调用会失败。所以空文件不能直接映射，必须先处理文件大小。
第四，mmap 返回的地址是页对齐的，但 length 不要求页对齐，内核会向上取整到页大小的整数倍。
2.2 prot 参数的选型和误区
prot 参数控制映射区域的访问权限，有四个值可以组合使用：
- PROT_READ：可读。
- PROT_WRITE：可写。
- PROT_EXEC：可执行。
- PROT_NONE：不可访问。
很多人把 prot 理解为“权限越大越好”，这是错的。权限不仅是逻辑约束，还会影响内核的一些行为。
比如，你只想把文件内容作为只读数据载入，却传了 PROT_READ | PROT_WRITE，那么内核必须为可能出现“写”行为做准备。当使用 MAP_PRIVATE 时，写操作会触发写时复制，这意味着即使你实际没写数据，某些优化路径也不能启用了。
另一个常见的坑是：以只读方式打开文件（O_RDONLY），却指定 PROT_WRITE，这会导致 mmap 失败。反过来，以读写方式打开文件，但只指定 PROT_READ，这是允许的。所以 prot 和文件打开模式的匹配原则是：映射要求的权限，不能超出文件描述符允许的范围。
还有一个进程间共享的场景：如果两个进程需要共享一块可写的映射区域，两边都必须用 O_RDWR 打开同一个文件，并且指定 PROT_READ | PROT_WRITE 和 MAP_SHARED。如果有一边只开了只读，那它只能读到别人写的数据，自己不能写，这对调试共享数据的程序来说是个容易混淆的点。
2.3 flags 参数：共享、私有与写时复制
flags 参数是 mmap 的精华，常用组合包括：
- MAP_SHARED：修改对其它映射同一文件的进程可见，并且会写回底层文件。
- MAP_PRIVATE：修改只对当前进程可见，不会写回文件，也不会影响其它进程的映射。
- MAP_ANONYMOUS：不基于文件，常用于分配零初始化内存。
- MAP_FIXED：强制使用指定地址，如果不满足条件会覆盖已有映射，日常使用务必谨慎。
- MAP_POPULATE：让内核提前预读映射页，减少首次访问的缺页。
MAP_PRIVATE 的实现机制是写时复制（Copy-on-Write，COW）。当你第一次写一个已映射的页面时，内核会复制该页，并把当前进程的页表重定向到新复制的页上。这个过程消耗内存和时间，因此对 MAP_PRIVATE 区域频繁写入，性能不一定好于普通 read 后直接改内存。
有一个典型的场景：多个进程同时加载同一份巨大的只读词典文件，每个进程只读不写，用 MAP_PRIVATE 就是最省内存的方案，因为所有进程共享同一个 page cache 页。如果某个进程想修改某个页，内核才给它单独复制一份，其它进程的视图完全不受影响。
这里我踩过一个坑：写了一个配置加载器，用 MAP_PRIVATE 加载配置后试图修改配置，本意是“只改当前进程的副本”，却忘记考虑写时复制带来的性能损耗，结果配置热更新时请求毛刺明显。后来改成读时只映射，修改时复制到普通堆内存，问题才解决。核心教训：即使 MAP_PRIVATE 允许你写，也不意味着你该写，尤其是在高频路径上。
2.4 offset 与 length：边界条件的秘密
offset 和 length 定义了文件范围到内存区域的映射关系。offset 必须是页大小的整数倍，length 则没有对齐要求。但内核在映射时，会额外映射一个补齐页。
举个例子：文件真实大小 5000 字节，页大小 4096 字节。你按 5000 长度映射，内核实际映射了 8192 字节（2 页）的地址空间范围，其中第 1 页包含文件字节 0~4095，第 2 页包含 4096~5000 以及 5001~8191 的零填充区域。
访问补齐的零填充区域是安全的，可以读，但如果你是在写映射，例如把文件向后扩展，就必须先把文件 set 到足够大小，否则：
- 访问超出文件实际大小的页，会触发 SIGBUS。
- 写入补齐页，如果文件没有相应扩展，也会触发 SIGBUS。
- 只有先通过 ftruncate 扩展文件，再继续写映射区域，才是安全的。
这在实际项目里有讲究：想通过 mmap 往文件末尾追加数据，不要直接映射到新长度，而是应该先 ftruncate 扩展文件，再重新 mmap，或者只映射原来文件大小，追加时走 pwrite。那种“映射大文件，然后越界写”的方式，是生产环境崩溃的常见来源。
3. 高级用法一：用映射文件做进程间共享内存
3.1 共享内存的方案对比
进程间共享数据，常见方案有管道、消息队列、Socket、共享内存等。管道和 Socket 都涉及数据拷贝和内核态用户态切换，适合小数据量、高可靠性要求的通信。如果数据量大、需要低延迟共享，共享内存几乎是唯一能打到“零拷贝”级别的方案。
共享内存的实现方式有两种主流：
- System V 共享内存（shmget/shmat）：经典接口，但管理模型比较老，生命周期是“随内核”，需要手工清理。
- POSIX 共享内存（shm_open/mmap）：把共享内存对象当成文件来映射，接口统一，还能和 mmap 的机制直接配合。
用 mmap + 文件做共享内存时，底层的文件不一定是普通磁盘文件，也可以是 tmpfs 文件系统的文件，比如 Linux 下 /dev/shm 目录。tmpfs 文件在内存中，不会产生磁盘 IO，非常适合跨进程高频共享数据。
3.2 基于文件映射的双进程读写案例
下面用一个简单的生产者消费者案例来说明。生产者进程往共享映射区写入一批结构体，消费者进程读取这批结构体。
先定义共享数据结构：
c复制// common.h
#define SHM_NAME "/my_shm"
#define MAX_ITEMS 1024
typedef struct {
int id;
char data[64];
} shared_item;
typedef struct {
int count;
shared_item items[MAX_ITEMS];
} shared_region;
生产者代码：
c复制#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include "common.h"
int main() {
int fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666);
if (fd < 0) {
perror("shm_open");
return 1;
}
ftruncate(fd, sizeof(shared_region));
shared_region *region = mmap(NULL, sizeof(shared_region),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (region == MAP_FAILED) {
perror("mmap");
return 1;
}
for (int i = 0; i < 10; i++) {
region->items[i].id = i;
snprintf(region->items[i].data, sizeof(region->items[i].data),
"item-%d", i);
}
region->count = 10;
msync(region, sizeof(shared_region), MS_SYNC);
printf("producer done, count=%d\n", region->count);
return 0;
}
消费者代码：
c复制#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
#include "common.h"
int main() {
int fd = shm_open(SHM_NAME, O_RDWR, 0666);
if (fd < 0) {
perror("shm_open");
return 1;
}
shared_region *region = mmap(NULL, sizeof(shared_region),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (region == MAP_FAILED) {
perror("mmap");
return 1;
}
printf("consumer sees count=%d\n", region->count);
for (int i = 0; i < region->count; i++) {
printf("id=%d, data=%s\n", region->items[i].id,
region->items[i].data);
}
munmap(region, sizeof(shared_region));
close(fd);
shm_unlink(SHM_NAME);
return 0;
}
这个例子能跑通，但只能用于演示。真实生产环境里，生产者和消费者可能同时运行，必须考虑同步问题，比如用信号量、互斥锁保护共享区域。POSIX 信号量可以放在共享内存里，多进程用 sem_wait/sem_post 同步，这是另外一个话题，但也是 mmap 共享内存真正能落地的前提。
还需要注意：shm_open 创建的对象大小是 0，必须用 ftruncate 初始化大小，否则 mmap 会失败或映射大小不对。很多人第一次写共享内存时忘了 ftruncate，白白排查半天。
3.3 匿名映射与 fd=-1 的特殊用途
匿名映射不基于任何文件，直接向内核申请一块零初始化内存。它的标志是 MAP_ANONYMOUS，此时 fd 传 -1，offset 传 0。
匿名映射最常见的用途是 fork 进程间共享内存。子进程是父进程的拷贝，但普通堆内存是独立的，只有 MAP_SHARED 的匿名映射区域会在 fork 后保持一致。
举个具体例子：服务启动时，用 MAP_ANONYMOUS | MAP_SHARED 分配一块统计信息区，然后 fork 多个 worker 进程，每个 worker 都能更新统计区，主进程读取汇总。这样避免了在每个请求里都用锁保护全局统计，也避免了进程间 IPC 的序列化开销。
这里有个很隐蔽的坑：如果 mmap 匿名映射时不指定 MAP_SHARED，而是默认 MAP_PRIVATE，fork 之后父子进程各自看到的是同一块物理页，但一旦任何一边写入，就会触发写时复制，数据就不再共享了。所以做共享统计时，忘记加 MAP_SHARED 会让统计结果出现“看起来能读到初始值，但更新的值互相看不见”的诡异情况。
4. 高级用法二：超大文件的随机访问与懒加载
4.1 为什么随机读性能优于 read
普通 read 随机读取文件，每次都要指定 offset 和缓冲区，然后执行一次系统调用，内核把数据从 page cache 拷贝到用户态缓冲区。即使 page cache 命中了，也要承受系统调用和内存拷贝的开销。
而 mmap 随机读，本质上就是一次指针解引用。文件页已经映射到进程地址空间，访问就是普通的内存读，不存在系统调用，不存在用户态拷贝。高频随机读场景下，两者差距非常明显。
我曾经在一个索引查询服务里对比过：文件大小 8GB，平均每次查询读取 4KB 随机数据，用 pread 的 p99 延迟大约 35 微秒，换成 mmap 后 p99 降到 8 微秒左右。虽然访问的物理页还是同一批 page cache，但省掉系统调用和拷贝后，耗时下降显著。
当然，这个优势的前提是映射页已经被缓存。如果访问模式是纯粹的随机且文件远超物理内存，page cache 会反复颠簸，mmap 页面会被频繁换入换出，这种情况下 mmap 也不一定能赢过精心设计的预读方案。
4.2 大文件分片映射的正确姿势
不是所有场景都适合“一次映射整个文件”。文件大小超过虚拟地址空间范围，或者某些操作系统不支持超大映射时，分片映射是更好的选择。
分片映射的基本思路是：不映射整个文件，而是映射一个窗口，然后根据访问位置移动窗口。移动的做法是：先 munmap 当前窗口，再 mmap 新窗口。
但频繁 munmap 再 mmap 是有代价的，因为第一次访问新窗口必然触发缺页，缺页至少要读一次磁盘。更好的做法是：把窗口切得稍大一点，例如映射 64MB 或 256MB 的窗口，并在窗口内保留一个“当前位置”的索引，避免频繁切换。
另一个优化是双窗口。用一个 2 倍窗口大小的环形缓冲区思路：当前访问落在当前窗口内就直接用，落在相邻区域就预映射下一个窗口，切换窗口时保留前一个窗口的映射，两头交错。这种做法在遍历超大文件且访问有局部性的场景很有用。
4.3 利用 madvise 提升局部性
madvise 是 mmap 的好搭档，它给内核提供关于映射区域访问模式的建议，让内核调整预读和缓存策略。常见参数：
- MADV_NORMAL：默认行为，内核按常规预读策略处理。
- MADV_RANDOM：告诉内核这个区域的访问是随机的，不要大量预读，避免浪费。
- MADV_SEQUENTIAL：告诉内核这个区域会被顺序访问，可以加大预读长度。
- MADV_WILLNEED：主动提示即将访问，让内核提前把对应页载入内存。
- MADV_DONTNEED：提示不再需要，内核可以先回收这些页。
实际使用中，MADV_RANDOM 对大文件随机索引很有效。我曾经在同样的日志文件随机读取测试里，加上 madvise 后，实际磁盘读次数大约少了 30%，因为内核不再做无谓的大块预读。反过来，顺序遍历一个超大文件时，MADV_SEQUENTIAL 能触发更深度的预读，让顺序读吞吐提升不少。
注意 madvise 给的是“建议”，不是“指令”，内核不一定完全遵守。但它成本极低，调用一次即可，值得在压力测试前先试试不同策略的差异。
5. 高级用法三：写时复制与私有映射的特殊场景
5.1 什么是写时复制，为什么它是把双刃剑
写时复制的核心思想是“不修改就不复制”。映射同一文件的多个进程，开始时都指向同一批物理页。只有当某个进程写入某个页时，内核才把那个页复制一份，并把该进程的页表更新到新副本上。
这个机制让“多进程共享只读大文件”变得极其高效。比如一个 10GB 的只读词典文件，10 个进程同时映射，物理内存里只需要 10GB 的一份副本，而不是 100GB。每个进程各自读自己的映射地址就够了，内存消耗大幅降低。
但写时复制的代价也藏在“写”里。如果某个进程不小心连续写入 MAP_PRIVATE 映射区域，每写一个页都会触发一次缺页异常和页复制。这个开销不是写普通内存能比的。我有一个实际案例：一个后台任务利用 MAP_PRIVATE 加载模板文件，然后想把模板中的占位符替换成真实值，结果替换到 200MB 模板时，CPU 飙升明显，原因是几乎每个页都触发了一次 COW，内存瞬时也翻了一倍。
这类场景的正确做法是：把模板映射成只读，替换逻辑在普通堆内存里做，最后再写回文件或生成新文件。不是所有映射区域都适合直接“改”。
5.2 用私有映射做进程启动时的配置快照
进程启动时，如果所有配置项都以 mmap 私有映射的方式加载，那 fork 出的多个子进程就能共享同一批配置物理页，直到它们各自修改配置。
这个模式对“只读为主，偶尔修改配置”的服务很有用。主进程先解析配置文件，形成一份结构化数据，放在 MAP_PRIVATE 映射区。fork 子进程后，子进程读取配置不需要额外拷贝。当子进程收到“更新配置”命令时，它只需要修改自己映射区里的字段，就会触发 COW，别的子进程的配置完全不受影响。
这里要注意的是：COW 后修改只影响“当前进程页表中该页的映射”，但如果你修改的结构体横跨多个页，每页都会独立复制一次，所以修改配置对象最好保证对象大小不超过一页，并且尽量按页对齐。
5.3 MAP_FIXED 是危险的，能不用就别用
MAP_FIXED 会让内核强制把映射放到指定地址，如果指定地址已经存在映射，会直接覆盖。这是极其危险的操作，因为它可能踩掉进程里其他模块的映射，包括动态库、堆、栈，轻则数据损坏，重则段错误崩溃。
安全替代方案是 MAP_FIXED_NOREPLACE（Linux 4.17+），它也是固定地址映射，但检测到冲突时返回 EEXIST 而不是覆盖已有映射。即便这样，固定地址也要非常谨慎，一般只用在 JIT、特殊加载器等需要精确控制地址空间的场景。
我见过一个崩溃案例，某项目为了让共享内存地址在所有进程中都一致，强制指定了某个固定地址，结果第三方库也默认加载到同一片区域，导致共享内存内容被覆盖、程序间歇性崩溃。排查过程极其痛苦，最后靠 gdb 看地址冲突才定位到 MAP_FIXED。
6. 性能调优与内核交互
6.1 缺页中断是真正的热点
mmap 的读取路径上，第一次访问一个未映射页时，会触发缺页异常。内核需要：
- 找到对应的文件页。
- 检查 page cache 是否已有缓存页。
- 如果没有，发起磁盘 IO。
- 把页加入 page cache。
- 建立页表映射。
- 返回用户态。
所以“首次访问”的开销远高于后续访问。如果你的程序只是映射了文件但没有主动访问，它并不会像 read 那样真正把文件内容读入内存。这一点很多人理解偏差，以为 mmap 之后文件内容马上就“在内存”里了，其实只是建立了地址映射关系。
因此，热启动优化可以用 MAP_POPULATE 主动触发预读，但要注意：MAP_POPULATE 会把指定长度的页都加载进内存，如果文件特别大，页缓存压力会瞬间升高。对小文件（几十 MB 以内）很有用，大文件可能直接拖垮内存。更优雅的方式是用 madvise 的 MADV_WILLNEED，只对热点区域预加载。
6.2 脏页回写与 msync 的正确时机
MAP_SHARED 映射区的写入，并不会立刻写回磁盘，而是由内核在后台按脏页回写机制定期刷盘。这意味着程序崩溃时，最近写入的数据可能丢失。如果你需要保证持久性，就必须调用 msync。
msync 有三个常用标志：
- MS_SYNC：同步等待，直到数据落盘才返回。
- MS_ASYNC：异步调度，马上返回。
- MS_INVALIDATE：使其他映射失效，一般搭配上面的标志使用。
使用建议：数据量小、需要强一致时用 MS_SYNC；数据量大、允许短暂窗口丢失风险时用 MS_ASYNC。但有一种情况必须用 MS_SYNC：即将 munmap 前，必须确保数据落盘，否则映射一解除，脏页可能还没刷，程序就退出了。
另外，msync 只同步“映射区域”的脏页，不保证其他 fd 相关缓冲区的同步。比如你先写文件内容，再 mmap 读取，看到旧数据的可能性也不小，因为 page cache 和文件系统元数据缓存有各自的脏提交路径。必要时用 fsync(fd) 同步整个文件的元数据和数据块。
6.3 用 mlock 锁定热页，防止交换抖动
当物理内存不足时，内核可能换出进程的匿名页或文件页。对于 mmap 映射区，如果页面被换出，下一次访问会触发 swap-in，延迟可能比磁盘读还高，因为你还要多一次 swap IO。
如果某些映射页是关键路径上的热数据，可以用 mlock 或 mlockall 把这些页锁定在内存中，阻止内核换出。
需要注意的是：
- mlock 操作需要权限，超出 RLIMIT_MEMLOCK 限制会失败。
- 锁定太多内存会降低系统整体弹性，容易引发其他进程 OOM。
- 应该只锁真正高频访问的关键页，而不是整个大文件。
我个人的习惯是：在大索引服务里，把索引的“头部页”和“热数据区”锁定一小部分，比如几十 MB，其余部分仍然依赖 page cache 自然缓存。这样既保证了延迟稳定，又不至于锁死大量内存。
7. 实战案例：用 mmap 打造高并发词典服务
7.1 场景需求
假设要做一个词典查询服务，词典文件是已经构建好的二进制数据：一个固定大小的词项数组，每个词项包括 8 字节 key 和 64 字节 value，总共 5000 万条记录，文件大小约 3.6GB。服务要求支持高并发查询，单次查询需要在几十微秒内返回。
传统方案启动时把文件全量读入内存，会产生明显启动延迟和额外的内存占用。使用 mmap 后，可以做到：启动只建立映射，不加载数据；查询时按 key 二分查找，访问到的页按需加载；多个 worker 进程共享同一份 page cache。
7.2 核心实现
核心结构体：
c复制typedef struct {
uint64_t key;
char value[64];
} dict_entry;
typedef struct {
int fd;
size_t file_size;
dict_entry *entries;
size_t entry_count;
} dict_index;
初始化时：
c复制int dict_load(dict_index *idx, const char *path) {
int fd = open(path, O_RDONLY);
if (fd < 0) return -1;
struct stat st;
fstat(fd, &st);
idx->fd = fd;
idx->file_size = st.st_size;
idx->entry_count = st.st_size / sizeof(dict_entry);
idx->entries = mmap(NULL, st.st_size, PROT_READ,
MAP_PRIVATE | MAP_POPULATE, fd, 0);
if (idx->entries == MAP_FAILED) {
close(fd);
return -1;
}
return 0;
}
查询时直接二分：
c复制const char *dict_lookup(dict_index *idx, uint64_t key) {
size_t lo = 0, hi = idx->entry_count;
while (lo < hi) {
size_t mid = lo + (hi - lo) / 2;
if (idx->entries[mid].key < key) {
lo = mid + 1;
} else if (idx->entries[mid].key > key) {
hi = mid;
} else {
return idx->entries[mid].value;
}
}
return NULL;
}
这里有个性能细节：二分查找时，每次访问 entries[mid] 都相当于随机访问一个页。如果搜索范围跨度很大，会触发大量缺页。实际优化时，可以先把二分查找改成“跳表加插值”或“多级索引”结构，减少随机访问次数。更简单的一种优化是，把 index 头部的一小段固定区域 mlock 住，让二分查找前几层一直驻留内存。
7.3 压测结果观察
我在一台 32GB 内存、普通 SSD 的机器上压测过这个服务。进程启动时间约 50ms，真正的映射建立没有耗时。查询随机 key 时，第一波请求触发缺页，延迟明显偏高；但运行几分钟后 page cache 变热，p99 稳定在 20 微秒左右。对比之前用 read 全量加载的方案，启动时间从 30 多秒降到几十毫秒，内存占用从进程内 10GB 级降到共享 page cache 6GB 级，同时多进程 worker 之间的重复内存占用也消失了。
这说明 mmap 非常适合“大文件 + 随机读 + 多进程共享”的组合。当然，如果词典服务还需要频繁更新数据，那就要引入写映射、锁同步等机制，复杂度会明显上升，得根据业务权衡。
8. 常见问题与排查技巧实录
8.1 SIGBUS 产生与避免
SIGBUS 是 mmap 场景中最典型的崩溃信号，出现原因通常是：访问了映射区域，但对应的文件区域不存在或没分配空间。
常见触发路径：
- 文件被 truncate 变小，映射区域超出新文件大小。
- 新建空文件，没 ftruncate 就开始映射和访问。
- 稀疏文件中，访问了还没写入数据的空洞页，文件系统返回“无空间”错误。
- 在 MAP_SHARED 映射区写入，但磁盘空间不足。
排查方式：先确认文件实际大小与映射长度；再检查是否执行了 ftruncate；最后查看磁盘剩余空间。定位准确后，按“先扩展文件，再访问映射”的顺序改就好。
8.2 mmap 后文件被删除
有时候，另一个线程或进程会 unlink 掉正在映射的文件。文件被删除后，映射区域仍然有效，因为底层 inode 还活着，但是新访问会得到什么行为，取决于具体实现。有些场景下，后续写入可能不落盘，读到的还是旧数据，但等你 munmap 后再重新打开同名文件，得到的就是另一个新文件。
我遇到过一次诡异现象：服务一直在读一个配置映射，配置更新流程是“删除旧文件，写新文件”。结果服务始终读到旧配置，排查才知道映射持有旧 inode，新文件没有打断旧映射。解决办法是配置更新时不要删除重建，而是直接覆盖写入，或采用“mmap 区域重新加载”的协议。
8.3 内存占用虚高，页面回收异常
mmap 大文件后，用 top 看 RES 值可能不高，但用 ps 看 VSZ 会非常大，因为虚拟地址空间包含了整段映射。这是正常现象。真正的问题在于，如果你的程序大量写入 MAP_SHARED 区域，脏页会一直留在 page cache 里，可能造成“内存被缓存占满”的假象。
排查办法是观察 /proc/meminfo 中的 Dirty、Writeback 字段，以及 /proc/sys/vm/dirty_ratio 相关配置。若脏页堆积明显，考虑适当调小 dirty_ratio，或者主动调用 msync 周期刷盘。
8.4 跨平台差异与 Windows 的 Mapping
Linux 的 mmap 在不同架构上行为基本一致，但 Windows 的内存映射文件走的是 CreateFileMapping 和 MapViewOfFile 接口，语义有差异：
- 在 Windows 上，一个映射文件视图的粒度受系统分配粒度影响（通常 64KB），offset 对齐要求更严格。
- Windows 的 FlushViewOfFile 对应 Linux 的 msync。
- 关闭映射视图时，Windows 需要 UnmapViewOfFile 再 CloseHandle，顺序不能反。
如果你的项目需要跨平台，建议把 mmap 封装成统一接口，并分别实现 Linux 和 Windows 两端。封装层要特别注意 offset 对齐的差异，因为同样的代码在 Linux 上能跑，在 Windows 上可能返回 ERROR_MAPPED_ALIGNMENT。
9. 实操心得与总结建议
9.1 哪些场景不适合用 mmap
不是所有文件 IO 都应该用 mmap。下面这些场景，用传统 read/write 反而更好：
- 文件非常小，几百字节到几十 KB，普通 read 开销可以忽略，mmap 的页表建立和缺页过程反而更重。
- 写入很频繁的小文件，脏页回写、COW 这些机制会让简单写入复杂化。
- 需要跨网络文件系统或文件可能被外部进程频繁修改的场景，缓存一致性问题很难控制。
- 需要严格顺序读大文件，但物理内存非常有限，mmap 无法依赖 page cache，预读效果也不如 read 加 posix_fadvise 来得直接。
9.2 代码审查时要盯住的清单
每次 review 涉及 mmap 的代码，我会重点检查这几个点：
- 是否检查了 mmap 返回值为 MAP_FAILED，并正确输出 errno。
- 是否对 offset 做了页对齐处理。
- 是否检查了文件大小与映射长度之间的关系。
- 写入共享映射前是否确认过文件大小已通过 ftruncate 扩展。
- MAP_SHARED 写入后是否在关键持久化路径上调用 msync。
- 是否在不需要 MAP_FIXED 的地方误用了 MAP_FIXED。
- munmap 后是否立即把相应指针置 NULL，避免悬垂指针。
- 共享内存场景是否配套了信号量或锁，避免多进程数据竞争。
9.3 个人实践体会
用 mmap 做了几年性能优化后，我的感触是：它是一把能让你“贴近内核”的工具，也是一种必须接受“按需加载”语义的编程模型。很多人第一次接触时兴奋于性能提升，但忽略了对文件生命周期、页缓存、缺页行为的理解，最后在诡异崩溃和数据丢失上付出代价。
如果你想真正掌握它，建议自己写几个实验程序：先跑通全量映射；再试试部分映射和 madvise；然后模拟一次文件被截断，观察 SIGBUS；最后在生产环境里压一次随机读和顺序读，把延迟曲线拉出来对比。跑完这几个实验，你对内存映射文件的理解，会超过绝大多数只会调 API 的开发者。踩坑不可怕，关键是每次踩完之后，都能把“为什么”彻底搞清楚。