内存映射文件（mmap）完全指南：原理、性能调优与工程实践

1. 内存映射文件：不只是把文件塞进内存

搞服务端开发、数据库内核、游戏引擎或者底层中间件的人，迟早会碰到一个瓶颈：文件 IO 太慢了。

我见过不少同事，一提到读大文件就条件反射地 fread 一堆 buffer，或者 pread 分段读，然后再自己管理内存、自己做缓存、自己处理偏移量。代码越写越复杂，性能却不尽如人意。这时候如果换个思路——用内存映射文件（memory-mapped file），很多问题会迎刃而解。

简单说，内存映射文件就是让操作系统把磁盘上的文件直接映射到进程的虚拟地址空间里。映射完成后，你对这段内存的读写，操作系统会负责在背后同步到磁盘。你不需要再调用 read/write，也不需要自己管理缓冲区，直接像操作内存一样操作文件就行。

它的核心价值有三个：第一，省掉了用户态和内核态之间的数据拷贝，数据从磁盘到内存再到应用只有一次拷贝（甚至借助更底层机制可以做到零拷贝）；第二，可以利用操作系统的页面缓存机制，文件被多个进程映射时，共享同一份物理内存，内存占用更省；第三，映射本身就是一种进程间通信手段，多个进程映射同一个文件，天然共享数据视图。

不过很多人的认知止步于此，以为 mmap 就是把文件“读进内存”，或者在 Redis 重启加载数据时用一下。实际上，内存映射文件的边界远比这宽，它涉及虚拟内存管理、缺页中断、页面回写、NUMA 架构、文件系统语义等一系列底层机制。

这篇文章我打算从“怎么用”开始，讲到“为什么这么用”，再到真实项目中才能踩到的坑，尽量把我这几年折腾 mmap 的经验一次性讲透。适合的人群是那些已经知道 mmap 存在、但还没系统梳理过它的人，或者是用过但想搞明白内部原理的人。

2. 到底映射了什么：理解虚拟内存与缺页机制

2.1 映射只是“画了一张地图”

很多人误以为 mmap 调用一完成，文件内容就已经被加载到内存里了。这个理解是错的，而且会直接影响你后续对性能的判断。

mmap 系统调用做的事情，本质上只是在你进程的虚拟地址空间里“画了一张地图”——它记录了某个地址范围内的页对应到哪个文件的哪些偏移上。这个过程不涉及磁盘 IO。返回的指针只是一个虚拟地址，映射进去的页面在物理内存里可能根本不存在。

那什么时候文件数据真正被读进内存？是你访问这个地址的时候。

CPU 访问一个虚拟地址，会先查 TLB（翻译后备缓冲器）和页表。如果页表里没有这个地址的映射关系，会触发缺页异常，内核介入，发现这个页对应的是文件某个偏移，于是从磁盘读取这一页数据到 page cache，然后更新页表，最后返回用户态重新执行访问指令。这个过程叫 demand paging（按需分页）。

这个机制带来的第一个实际指导意义是：一个 8GB 的文件，你 mmap 之后立刻看内存占用，几乎不会增加。真正消耗内存的是你“碰”过的那些页。所以很多文章说“mmap 适合大文件”，因为它的内存成本是懒惰的（lazy），你用到哪一页，它才加载哪一页。

2.2 页大小和地址对齐是隐藏约束

凡是和 mmap 打过交道的人，肯定知道 mmap 的 addr 和 offset 参数都必须是系统页大小的整数倍。在 x86-64 Linux 上，默认页大小是 4KB。为什么有这个限制？

因为页表项只记录页号，不记录页内偏移。如果你映射的起始地址不是页边界，一个页表项就无法准确描述你想要的映射范围。内核在实现上会简单粗暴地把 offset 向下取整到页边界，然后你实际映射到的内容可能和你预期差了几百字节。

这个约束的实际影响是：当你需要在一个大文件里映射一个“任意位置的小段”时，必须小心计算。比如文件 100 字节处有 4KB 数据需要映射，你只能从 offset 0 开始映射，然后通过指针偏移访问 100 字节处，而不能直接把 offset 设为 100。

更隐蔽的是，许多高性能项目在文件内部自己设计数据结构时，会刻意要求所有记录从页边界开始，原因就在于此——直接映射后可以避免额外计算，也能避免一个记录跨页边界造成额外的缺页开销。

2.3 常见的四种映射类型选择

具体到 Linux 上，mmap 有两个关键参数：prot 和 flags。prot 是访问权限，flags 决定映射的可见性和改动行为。实际项目中通常只关心四种组合。

第一种是 MAP_SHARED 加读写权限。多个进程映射同一个文件，任何进程对内存的修改，最终都会通过回写机制写回文件，其他进程也能看到。这是共享内存通信和大数据处理最常用的组合。

第二种是 MAP_SHARED 加只读权限。这种映射多用于需要读取公共配置或只读数据的场景，多个进程共享同一份物理页面，节省内存。

第三种是 MAP_PRIVATE 加读写权限。这种映射不会把改动写回文件，进程对映射页面的修改会触发写时复制（copy-on-write）。变更只对自己可见。这种组合适合做镜像加载、程序加载这类不希望污染原始文件的场景。

第四种是 MAP_ANONYMOUS，完全不映射文件，只分配一段零初始化的内存。它本质上是一种便捷的大块内存分配方式，常用于进程间共享内存（配合 MAP_SHARED）以及某些内存池实现。

我强烈建议不要使用 MAP_FIXED，除非你非常清楚目标地址一定不会被占用。这个标志会强制内核替换掉指定地址处已有的映射，轻则崩溃，重则引发难以排查的诡异问题。如果需要指定地址，请使用 MAP_FIXED_NOREPLACE（内核 4.17+）或先 mmap 一个占位区域再 remap。

3. 高性能场景下的核心用法与参数调优

3.1 映射大文件时的内存压力管理

虽然按需分页让大文件映射看起来很美，但在实际生产环境中，你不可能无限依赖操作系统的默认缺页策略。

考虑一个场景：线上服务需要扫描一个 50GB 的日志文件，但物理内存只有 32GB。如果你一次性全部映射，然后从头到尾遍历，操作系统的 LRU 策略会把不常用的页换出去。这可能没问题，但页换入换出的 IO 抖动很可能拖慢你的业务响应。

这时候有两个思路。

第一个思路是分片映射。每次只映射文件的一部分，处理完后再映射下一部分。映射一个 256MB 或 512MB 的窗口，处理完立刻 munmap，确保内存占用可控。这个思路简单有效，唯一要注意的就是不要频繁 mmap/munmap，否则系统调用开销和页表建立/销毁的开销反而会吃掉性能。窗口调大一点，比如一次映射 1GB，效果更稳。

第二个思路是用 madvise 系统调用配合访问模式做精细控制。MADV_SEQUENTIAL 告诉内核你的访问是顺序的，内核会激进地做预读，也会在页面使用完后更快地回收。MADV_RANDOM 则告诉内核不要预读，只按需加载。这两个建议对 IO 性能的影响在我实测中可以达到 20% 到 60% 的差距，取决于文件系统和磁盘类型。

还有一种做法是借助 MADV_DONTNEED 主动释放已经处理完的页面。注意，MADV_DONTNEED 对于 MAP_SHARED 映射，如果页面是干净的（未修改或已同步），效果等同于丢弃；如果页面是脏的，行为取决于内核版本和文件系统，可能表现为丢弃，也可能表现为先写回。因此在用这个接口前，必须明确自己的映射类型和页面状态，否则会丢数据。

3.2 共享内存通信与无锁设计

多进程共享内存是内存映射文件的另一大高级用法。多个进程把同一个文件映射到自己的地址空间，配合原子操作或者自旋锁，可以实现无锁或轻量锁的数据交换。

一个典型的场景是交易系统中多个进程需要共享市场行情快照。如果用传统的消息队列，一次行情发布要涉及多次拷贝和内核唤醒。如果用共享内存映射文件，发布进程写内存，订阅进程直接读内存，中间少了内核的参与，延迟可以降到微秒级。

在这个场景里，我总结出几个值得注意的要点。

第一，共享区域的数据结构要避免使用绝对指针。不同进程映射同一个文件时，映射到的虚拟地址很可能不同（除非用 MAP_FIXED 强行指定同一个地址），所以结构里的引用关系必须用偏移量而不是指针。比如用一个 int64_t offset 指向下一个消息，而不是 Message* next。

第二，需要使用原子操作或内存屏障保证可见性。多个 CPU 核心同时访问共享内存时，不加上同步机制，读取方可能看到写入方只完成一半的数据。C++11 的 std::atomic、C11 的 stdatomic.h 或者 GCC 内置的 __sync / __atomic 都值得熟练掌握。

第三，共享文件的长度一旦确定，尤其是生产者可能往文件里追加内容时，要留足余量，或者提前设计好扩容机制。因为文件扩容需要 ftruncate 或 fallocate，这几个操作对映射了该文件的其他进程不一定会自动生效——你需要重新 mmap 新区域，或者把整体映射扩大。若处理不当，其他进程访问超出原映射范围的地址时会直接段错误。

3.3 读写大文件的性能对比与分析

为了搞清楚内存映射文件在真实场景下的表现，我做过一组对比实验：对同一个 8GB 文件做全量读取，分别用传统的 pread 循环读取、fread 流式读取、mmap 全映射顺序访问、mmap 配合 madvise(MADV_SEQUENTIAL) 四种方式。

排除缓存干扰后，结果大致如下：

从数据看，mmap 配合正确的内存建议能获得约 25% 的提升，主要来自减少了用户态和内核态之间的数据拷贝。但这并不意味着 mmap 在所有场景下都是银弹。

如果文件很小（比如几 KB 到几 MB），fread 或 pread 的开销完全可以忽略，还省去了页表和缺页管理的负担。如果读写模式是随机小 IO，且每次只改几十个字节，pread/pwrite 反而更可控，因为 mmap 的脏页回写会导致一次写上页，会放大写放大倍数。

3.4 文件与映射大小的同步问题

大部分初次使用 mmap 写文件的人都会遇到一个很困惑的问题：我往映射内存里写了数据，但文件的大小没有变化。

这不是 bug，而是语义如此。mmap 映射的是文件的现有内容，映射长度由 mmap 调用的 length 参数决定，这个长度不能超过文件实际大小。你向映射区域写数据，只会修改文件偏移范围内已有内容的字节，不会自动扩展文件。

要写入新数据、追加内容，必须先把文件截断到目标长度（ftruncate 或 posix_fallocate）。最佳实践是先分配好空间，再映射。尤其是频繁追加数据的场景，先用 posix_fallocate 预留大块空间，然后每次写入只需要改一下文件尾偏移量，避免每次追加都做系统调用。

这里有一个陷阱：如果你映射长度为 4MB，然后手动 ftruncate 扩展到 8MB，接着继续通过原映射访问 4MB 到 8MB 的区域，在 Linux 上会怎样？答案是 4MB 到 8MB 这段是合法的可访问区域，但访问其中的页面时会触发页错误，内核因为找不到对应文件页（原来文件只有 4MB）会向进程发送 SIGBUS 信号，进程默认终止。这不是崩溃，而是信号处理机制在保护你。要想扩展映射，必须重新 mmap。

4. 数据一致性与可靠性：知道什么时候靠内核什么时候靠自己

4.1 msync 与脏页回写

MAP_SHARED 映射中，对内存的修改不会实时同步到磁盘。Linux 内核按照自己的节奏（默认 30 秒左右）把脏页写回。为了确保关键数据落盘，需要手动调用 msync。

如果把 msync 类比成 fwrite 之后的 fflush，第一步理解是对的，但有一定差别。fflush 是把用户态缓冲区数据推到内核缓冲区，msync 是确保映射内存中的修改同步到磁盘文件系统里（至少进入页缓存，配合 MS_SYNC 则是完整落盘）。

msync 有三种模式。MS_ASYNC 异步调度写回，立即返回；MS_SYNC 同步等待写回完成才返回；MS_INVALIDATE 让同一文件其他映射中的相关缓存失效，这个参数用得少，需要谨慎。

实际项目中，如果文件不大、写入频率不高，每条业务数据写入后调用 msync(f, len, MS_SYNC) 保证可靠性和实时性，可行。但如果写入频率很高（比如每秒成千上万次），每次都同步落盘会让性能急剧下降。这时候可以设计成：批次写入一批数据，每批次调用一次 msync，或者靠内核定期回写。

我个人的经验是：不要盲目依赖内核的自动回写机制。你永远无法精确知道内核何时会把脏页刷回磁盘，也不能确定刷回前进程是否异常退出。凡是需要持久化的关键数据，务必写完后主动同步，并设计好启动时的数据校验和恢复流程。

4.2 进程崩溃与数据恢复的边界

内存映射文件一个让很多人误判的点是：进程崩溃了，映射数据还在吗？这取决于崩溃前这些脏数据是否已回写。

进程异常退出（没有正常 munmap）时，内核会清理进程资源，但已经修改过的脏页并不会立即写回文件。脏页被标记为受文件系统管理，会由内核后续的周期性回写或缓存回收机制处理。这意味着如果你在崩溃前刚修改了映射内存但没有 msync，数据可能已经落盘，也可能在内存里待着，没人给你保证。

所以，对于强一致性的需求，必须在写入的关键点主动 msync。这一点和上面的一致性问题是一体的。

另外，我自己踩过一个坑：写数据库 WAL 日志时，用 mmap 写日志，然后依赖 msync 落盘。某次断电恢复后发现 WAL 尾部出现半截记录，排查后确认是那批记录写入后 msync 失败但错误码被忽略了。所以 msync 的返回值一定要检查，errno 也很关键。检查失败后要决定是重写还是终止进程，绝不能静默忽略。

4.3 文件被截断或替换的风险

还有一个容易踩的坑：映射了一个文件之后，如果另一个进程或同一进程的其他线程通过 ftruncate 把文件缩小到比映射范围还小，会发生什么？

已经映射但被截断掉的那部分地址，访问时会触发 SIGBUS，这是总线错误而不是段错误。很多新手分不清这两个信号。段错误是访问了没有映射关系的虚拟地址，总线错误是访问了有映射关系但底层无法提供数据的地址。这种场景在日志轮转系统（log rotation）里很常见：日志系统一边 mmap 文件，一边用 rename/truncate 切换日志文件。

解决思路有两个：一是专门设计一个“只追加、不截断”的文件格式，轮转时创建新文件、映射新文件，而不是对旧文件做截断；二是在所有可能触发 SIGBUS 的地方安装信号处理器，捕获后主动重新映射或主动退出，避免静默崩溃。

如果使用 SIGBUS 信号处理，需要注意信号处理的异步安全限制。最简单的落地方案是：信号处理器里只做标记，主循环检查标记后做清理。

4.4 持久化 IO 错误与 No space left

mmap 的写错误不会像 write 调用那样直接返回 -1。你向映射内存写入内容，错误会在之后的某个时间点通过 SIGBUS 或 SIGSEGV 表现出来。这在磁盘满的场景尤其典型。

比如你预留了 10GB 文件空间，映射后开始写，写到 9.5GB 时磁盘满了。这之前每一次写操作都没报错，但某些页面可能无法成功分配物理块。崩溃不会立即发生，而是在后续某个时机（比如内核回写时）才暴露。

这让 mmap 在处理需要可靠性的场景时显得很棘手。我会在负责写入数据的关键路径上，尽量避免无限依赖映射内存。如果一定要用，一种补偿方案是周期性调用 fdatasync 或 msync，并检查错误。另一个技巧是写入前用 statvfs 检查剩余空间，预留充足的安全余量。

5. 映射大文件与超大虚拟地址空间的工程实践

5.1 在 64 位系统上映射超大文件

64 位系统的虚拟地址空间通常有 128TB（用户空间部分），这让映射超大文件变得更加容易。单个映射最大可以达 128TB，但实际上受限于物理内存和文件系统。

不过，映射大文件（比如超过内存大小的数倍）时，设计数据结构要考虑缓存友好性。顺序遍历和随机访问的性能差异非常明显。我在处理一个 200GB 的倒排索引文件时，最初采用随机访问每个文档索引数据，吞吐量极低。后来把所有索引值按词典序排好，用顺序扫描的方式处理查询，性能提升了数倍。这不是 mmap 本身的问题，而是访问模式决定了缺页次数，缺页次数的多少直接决定了外存 IO 频率。

如果一定要随机访问超大文件的多个位置，建议在映射范围上按实际访问模式切分。比如按热点数据和非热点数据分区，热点数据常驻映射窗口，非热点数据按需映射。这比整个文件一个映射更灵活可控。

5.2 稀疏文件与大块预留

在很多数据存储系统中，稀疏文件（sparse file）配合 mmap 非常实用。稀疏文件的文件大小可以很大，但实际占用磁盘块很小，文件系统会为未写入的区块填零处理。

创建稀疏文件很简单：ftruncate 到目标大小即可，不用真的往文件里写零。然后 mmap 映射这个文件，直接往各个偏移写数据。只有你写入的块会真正占用磁盘空间。

这种模式的另一大优势是：多个进程可以映射同一个稀疏文件的不同区域，各自管理一块，不需要锁。比如一个 1TB 的稀疏文件，进程 A 负责前 500GB，进程 B 负责后 500GB，映射时各自只映射自己负责的区域。

注意，稀疏文件在网络文件系统（NFS、SMB）上行为可能不同。某些网络文件系统不支持稀疏语义，导致 ftruncate 之后实际占用满空间，或者 lseek 的 SEEK_HOLE 探测失效。在分布式环境中使用前，最好先做好兼容性验证。

5.3 页面锁定在实时场景中的作用

对于低延迟或实时性要求高的场景，页面被换出到外存的代价是难以接受的。比如高频交易系统，如果某个关键进程的映射页面被换出，再换入的时间可能达到数毫秒甚至数十毫秒，这在微秒级的核心链路里就是灾难。

mlock 和 mlockall 可以用来锁定内存，防止页面被换出。锁定的内存是实际物理内存，过多锁定会挤占其他进程的内存，而且 mlock 操作需要相应权限，普通进程可锁内存有上限（RLIMIT_MEMLOCK）。

在共享内存映射场景中，一个很实用的技巧是：整个共享区域在初始化时全部 mmap 一遍，然后调用 mlock，把共享数据固定在物理内存中，再开始业务逻辑。这样后续访问不会因为缺页而抖动。

需要注意的是，mlock 只保证内存不被换出，不保证数据落盘。持久化还需要 msync。如果既有低延迟需求又要有持久化保证，你得在锁页完成后自己设计一种适当的落盘策略，比如把关键状态写成多个副本，或者用 DPDP 等机制分担同步成本。

5.4 NUMA 架构下的映射策略

在多路服务器上，NUMA 架构让内存的访问速度不再一致。本地内存访问快，远端内存访问慢。这对 mmap 的性能有直接影响。

默认情况下，进程的内存分配可能分散到多个 NUMA 节点。如果共享内存映射文件被多个进程频繁读写，且这些进程分布在不同节点上，访问远端内存的额外延迟就可能成为瓶颈。

一个可行的策略是：每个进程尽量只访问本地 NUMA 节点上的共享内存区域。但这要求你对系统的 NUMA topology 有清晰认知，并且能控制内存分配策略。libnuma 提供了 mbind、set_mempolicy 等接口，可以在 mmap 后为特定地址范围设置内存分配策略。另一个思路是让共享内存区域在初始化时由主进程在某个特定 NUMA 节点上分配，其他进程通过映射访问时尽量减少跨节点访问的频率。

很多团队在做性能调优时忽略 NUMA 的影响，导致同一种软件在 AMD EPYC 和 Intel Xeon 上的表现差异巨大。我的经验是：如果项目真正吃到了内存带宽上限，需要排查内存页分布和跨节点访问比例。简单地用 numastat 和 perf 就能发现瓶颈。

6. 常见问题与排查技巧实录

6.1 段错误（SIGSEGV）和总线错误（SIGBUS）的区分

这两个信号是最常见的 mmap 问题，但根因完全不一样。

段错误的典型原因：访问了没有映射关系的地址。常见触发场景包括：映射范围计算错误导致指针越过 mmap 区域；munmap 之后继续访问旧指针；MAP_FIXED 覆盖了其他映射区域导致后续代码访问原本地址崩溃。

总线错误的典型原因：映射存在，但底层文件无法提供所请求的数据。常见触发场景：映射的文件被 ftruncate 截短；映射长度超过文件实际大小，访问超出部分；磁盘 IO 错误导致无法读取数据页；文件系统不支持某些操作。

排查思路：先看核心转储或使用 gdb 查看崩溃地址，对照映射范围判断是否越界。/proc/<pid>/maps 可以精确看到进程的映射布局。总线错误通常用 strace 跟踪系统调用，同时关注文件系统状态和磁盘剩余空间。

6.2 映射区域大小与文件大小不符的问题

很多人写出的代码是先 mmap 文件再扩展文件再写入，结果发现每次扩展后新区域无法访问，或者旧映射访问范围没包括新扩展的部分。

这个问题根因还是映射长度是调用 mmap 时确定的，不会自动跟踪文件变化。正确的做法是：先把文件扩展到将来需要的最大大小，再一次性映射，或者每次扩展后重新 mmap。

如果你需要频繁扩展文件，并且扩展频率很高，建议放弃单次大映射方案，改为分块映射。每个块映射固定大小，块内数据写满后再映射新块。这样避免反复整块重映射。

6.3 mmap 后文件内容变化是否立即可见

同一进程或另一进程对文件的不同区域做了 mmap，一个进程修改了某个页面的数据，另一个进程什么时候能看到？

在 MAP_SHARED 映射中，修改是通过页表映射直接落在同一物理页面上，另一个进程如果映射的是同一页，立即可见。但要注意 CPU 缓存一致性问题，多核系统上通常需要原子操作或内存屏障来确保跨核心的可见性。如果是 NFS 这种网络文件系统，则涉及客户端缓存一致性，情况会更复杂。

如果是 MAP_PRIVATE 映射，修改后的数据只对当前进程可见，文件本身不变，其他进程看不到。

6.4 性能问题：缺页频繁或缓存颠簸

遇到映射大文件后性能不理想的情况，优先使用 perf 工具查看缺页事件，再用 sar -B 或 vmstat 查看 page fault 和 swap 指标。

常见优化手段包括调整 madvise 访问策略、调整映射窗口大小、增加预读机制、考虑用 posix_fadvise 和 readahead 配合使用。如果瓶颈在写回，可以尝试把脏页比例调高（/proc/sys/vm/dirty_ratio），降低回写频率，但这是全局影响，需要谨慎。

6.5 快速排查速查表

7. 绕不开的移植性与跨平台问题

7.1 POSIX 系列接口和 Windows 的差异

内存映射文件最常见的 API 在 POSIX 系统上是 mmap/munmap/msync，在 Windows 上是 CreateFileMapping/MapViewOfFile/UnmapViewOfFile/FlushViewOfFile。两者用起来差别很大。

Windows 上的映射对象从命名管道到文件均可，命名的内存映射文件还能跨进程共享，无需文件系统实际落盘。这与 POSIX 的匿名映射非常类似。Windows 的 FlushViewOfFile 对应 msync，但它只刷新视图范围，FlushFileBuffers 才对应 fdatasync 级别的落盘。

跨平台代码如果自己维护两套实现，很容易在细节上出错。我建议抽象一个轻量级封装，只暴露 MapFile、UnmapFile、SyncRange 三个操作，内部按平台区分。这样业务代码就不需要关心平台差异。

7.2 文件系统对映射行为的影响

不同文件系统对 mmap 的支持程度、性能表现和语义细节差异很大。

ext4、XFS、Btrfs 在本地盘上的 mmap 性能和相关语义都较成熟。ZFS 的内存映射实现利用了 ARC（自适应替换缓存），但惰性写入和刷新策略和传统文件系统不一样，在某些工作负载下可能导致可见的写延迟波动。

网络文件系统（NFS）上的 mmap 最需要谨慎。NFS 的缓存一致性基于租约和缓存验证，多个客户端同时映射并修改同一文件的同一区域，几乎没有绝对保证。一个客户端写入的数据，另一个客户端可能很久之后才看到，甚至因为缓存刷新策略互相覆盖。如果必须跨网络共享数据，我倾向用共享内存/消息队列/数据库，而不是依赖 NFS 上的 mmap。

7.3 不同操作系统上的实验数据参考

我在 Linux（ext4）、macOS（APFS）、Windows（NTFS）上分别做了同样的 mmap 顺序读吞吐测试，配置为本地 NVMe SSD，读取一个约 4GB 的二进制文件。

数据说明，即便在操作系统层面，mmap 的性能也不是绝对优于传统 IO。最终还是要看访问模式和应用场景。

8. 内存映射文件的替代方案与选型判断

8.1 什么时候不该用 mmap

没有银弹。mmap 虽然灵活，但不是所有场景的首选。

第一个不适合的场景是小文件的频繁小写入。例如一个不断更新状态的配置文件，只有几百字节，每秒钟更新一次，用 pwrite 直接写文件比 mmap 更简单可靠，开销也更低。

第二个不适合的场景是超高的随机写压力，而且每次写入的数据量远小于一页。mmap 的一次小写操作，实际上会让整页变脏，后续回写时是整页写回，写放大严重。这种情况下，pread/pwrite 配合用户态缓冲、按固定块对齐批量落盘，效率更高。

第三个不适合的场景是需要严格事务语义的数据库引擎内部，尤其是需要 undo/redo 日志的复杂系统。mmap 无法精确控制提交点、无法优雅处理部分写、无法在 IO 错误时返回错误码，这都与数据库的恢复机制天然冲突。

比如很多数据库专家认为，mmap 写入期间的崩溃一致性很难保证，业界不少数据库明确说“不推荐把 mmap 用于 WAL”。他们不是否定 mmap，而是它的控制粒度太粗了。

8.2 选型对比：mmap、read/write、io_uring、DPDK

我个人的选型判断标准是：如果核心矛盾是“文件较大、需要共享、读为主、性能敏感”，选 mmap；如果核心矛盾是“写入可靠性、事务语义、错误处理”，那优先考虑 read/write 或 io_uring。

8.3 从 mmap 平滑迁移到其他方案

如果你已经在用 mmap，但因为上面的某些问题需要迁移到其他方案，我的建议是不要一次性推翻，而是保留抽象层。

在业务代码和具体 IO 实现之间加一层接口，比如 ReadAt(offset, buffer, len) 和 WriteAt(offset, buffer, len)。mmap 实现只需要用 memcpy 加上内存屏障；文件 IO 实现就调用 pread/pwrite；异步实现就接 io_uring。这样既能在早期用 mmap 快速验证性能，也能在后期根据线上表现平滑切换。

这种设计也方便做单元测试，测试环境用普通文件 IO，压测环境切到 mmap，线上再根据实际数据表现决定。我自己做底层存储模块时，一直沿用这个思路，省去了很多返工。

9. 日常走查中的几个细节经验

实际项目中，关于 mmap 的坑往往不是理论知识不够，而是细节被忽略。下面这些经验都是我在调试中一点点攒下来的，按建议优先级写在最后。

第一，常看 /proc/<pid>/maps 和 pmap。排查任何映射问题，第一步先看这两项，确认虚拟地址范围和映射权限是否符合预期。很多“为什么数据没存上”的问题，看一眼映射权限马上就有答案——你映射的是只读，写入自然失败。

第二，使用 MAP_POPULATE 要谨慎。这个标志位会在 mmap 返回前就完成所有页面的预读，适合希望一次性把文件全部载入内存的场景。但它会阻塞直到所有请求页都读入，大文件映射时可能造成明显延迟。如果希望预热缓存但不希望阻塞，可以用 MAP_POPULATE 配合线程，或在映射后手动读取一遍首页/末页触发预读。

第三，mremap 可以用于扩展或缩小映射区域，但可移植性较差，而且对共享映射的支持有限。如果代码需要在多平台跑，尽量避免依赖它。

第四，信号处理器里不要随便写日志。如果你用信号处理器来处理 SIGBUS 或 SIGSEGV，不要再调用非异步安全函数。我自己遇到过信号处理器里调 printf 导致二次崩溃的情况，排查了很久才定位。

第五，mmap 如果映射的是普通文件，close 原文件描述符在 mmap 之后是安全的。内核会通过映射本身保持对文件结构的引用。但不要在映射期间用这个 fd 做 ftruncate 缩小文件，否则触发上面的安全隐患。

第六，共享内存映射的初始化要重视。多进程同时映射一个共享文件后，如果没有明确初始化流程，进程启动时可能读到半初始化的数据。建议设计一个独立的初始化阶段，由一个进程完成共享区的结构布局和元数据写入，其他进程只读，等看到元数据中标记“已初始化”后才开始读写。

第七，如果需要跨架构共享内存映射文件，不要忘记大小端问题。x86 是 little-endian，SPARC/ARM 等平台可能是 big-endian。直接用 C 结构体映射，在不同架构的机器上解析出的字段值可能完全错乱。更稳的做法是定义统一的字节序格式，存储时明确转换，或者为每个数据字段定义显式的序列化/反序列化函数。数据文件的跨平台共享从来不是免费的。

第八，mmap 之后不要再通过 read/write 对同一文件的同一区域做并发操作，否则可能破坏映射内的数据一致性。内核会把映射区写入和普通 write 写入视为不同的写路径，虽然同属页缓存，但在并发场景下可能产生不可预料的顺序问题。我实测过，同一文件写进程用 pwrite，读进程用 mmap，在写入速率很高时，读进程可能看到间歇性的“撕裂”数据，即使单次写入是一个小块。

10. 一个越用越顺手的方向

内存映射文件这个机制，在我刚开始接触时觉得它就是个“偷懒”的 IO 方式——把文件当内存用，省得设计缓冲层。等真正深入之后，才发现它背后牵扯的是整个操作系统的内存管理和文件系统协同机制。从按需分页到回写策略，从共享内存到崩溃一致性，每一层都有值得琢磨的细节。

我现在设计任何需要处理大文件或多进程共享数据的模块，都会先想一下：能不能用内存映射文件？如果不能用，为什么不能用？有没有什么办法把问题转化掉？很多时候，问题的本质不在于“读文件太慢”，而在于“数据从磁盘到计算单元之间拷贝了太多次”。内存映射文件恰好能省掉这些拷贝，但代价是你要接受它的控制方式。

我个人在做后续类似的项目时，通常会先搭一个最小原型：映射文件、顺序写入一批数据、msync、重新映射读取验证，跑通后再逐步加并发和恢复逻辑。原型能验证思路，真正深入时再去解决那些边界问题和性能陷阱。

这篇文章写到这，我把能想到的 mmap 相关内容都梳理了一遍，从原理到用法，从性能到可靠性，从单机到跨平台。如果你现在正准备在项目里引入它，我的建议是从小范围、低风险的模块先试水，比如共享配置、索引读取这类只读场景。等积累了足够的经验和代码模式，再去挑战那些需要写回、需要保证一致性的核心路径。

内存映射文件是一把好用的刀，但它确实有自己的适用边界。知道它能做什么，更要知道它不能做什么，这才是从“会用”走到“用好”的关键。