深入理解mmap内存映射：从底层机制到工程实战

有段时间我盯着一台日志分析服务器的监控面板发呆，CPU持续在 80% 以上，磁盘 IO 却低得可怜，QPS 上不去，每个请求平均延迟却不断飙升。当时处理的是每天 40GB 左右的访问日志，程序用传统的 fread 一行行解析，再配合一些正则提取字段。说白了就是典型的 read 系统调用加用户态缓冲，数据从磁盘页缓存拷到内核缓冲区，再从内核缓冲区拷到用户态缓冲区，每一次 read 都有一次上下文切换，大量小数据块读取让 CPU 被系统调用淹没。后来我换成 mmap 文件映射，同一个解析任务，CPU 直接掉到 30% 左右，整个处理管线秒级完成。从那次之后，我开始认真研究内存映射文件的高级用法，才发现之前对它的理解太浅了——它远不止“把文件读到内存”这么简单，它是一整套虚拟内存与文件系统协同工作的机制，能在进程间通信、大文件随机访问、持久化数据结构、性能调优等场景里扮演核心角色。

这篇东西我会从底层机制讲起，结合几个我实际做过的工程案例，把 mmap 怎么用、为什么好、坑在哪里都摊开来说清楚。内容面向已经会基本文件操作的开发者，不需要你有内核背景，但如果你写过一些 C/C++ 或者 Go，理解起来会顺畅很多。

1. 三年后我才真正理解“把文件当内存用”这句话

我第一次接触 mmap 是在一本讲 Unix 环境编程的书上，当时只觉得它是个读取文件的新姿势：mmap 一下，拿个指针，然后就能像数组一样访问文件内容，挺方便。但一旦遇到性能问题、数据同步问题、多进程并发问题，就完全不知道怎么处理。原因很简单——我只知道“怎么调 mmap”，不知道“mmap 背后发生了什么”。

1.1 一次线上事故让我重新审视 read/write 的代价

那时做一个实时日志清洗服务，数据源是多个业务模块落盘的文本日志，格式基本固定，每行一条记录。最初实现很朴素：用 fopen/fgets 逐行读，配合 sscanf 拆字段，再写到下游。刚上线时数据量小，一切正常。但业务增长后，单日日志量从几个 GB 涨到几十个 GB，服务开始频繁出现 CPU 毛刺，而且毛刺集中在凌晨日志轮转后的高峰。

用 perf 抓了一下热点，排在最前面的两个函数是 copy_user_enhanced_fast_string 和 entry_SYSCALL_64_after_hwframe。前者说明用户态和内核态之间的数据拷贝成了大头，后者说明系统调用本身的开销也压不住了。fgets 每次只读一小段，但底层本质上是反复的 read 系统调用；每个 read 从进程的用户态陷入内核态，把页缓存中的数据复制到用户缓冲区，再返回用户态。日志文件一大，系统调用次数乘以每条日志的读取次数，数量级非常恐怖。

换成 mmap 之后，情况完全不一样。文件被映射进进程地址空间，read 文件变成了普通的指针访问。读操作如果命中了已经在页缓存里的页，CPU 直接访问内存，不需要系统调用；就算发生缺页，内核会一次性把整个 4KB（或 2MB/1GB）的页加载进来，后续的数据都直接命中。日志行解析从“反复读内核”变成了“读内存”，性能自然就起来了。

1.2 “映射”的精髓在于按需加载，而不是一次性读入

很多人以为 mmap 是把整个文件加载到内存，其实这是最大的误解。mmap 建立的是“虚拟地址到文件页的映射关系”，不是“物理内存里的数据副本”。映射完成后，你去访问其中的某个地址，如果对应的页不在内存里，CPU 触发缺页异常，内核根据映射关系从磁盘（或者页缓存）加载这一页，再返回用户态继续执行。

这个机制意味着一个 100GB 的文件，你也可以毫无压力地 mmap，只要你不是一次性把所有页面都摸一遍。物理内存只存放真正被访问到的页，其他部分停留在磁盘上。我之前处理几十 GB 的日志时，就是直接 mmap 整个文件，然后多线程并行扫描，内存开销远没有想象中大，因为每个线程只在自己的区间顺序访问，页面用完还可能被内核自动回收。

这个特性在数据库、搜索引擎、键值存储这些都极其重要。它们处理的数据集往往大于物理内存，但业务访问具有局部性，把数据文件 mmap 进来，操作系统天然地充当了缓存管理器，按需加载热点页，淘汰冷页，不需要开发者自己实现一套 LRU 缓存。

2. mmap的底层旅程：虚拟地址、缺页中断与脏页回写

要真正用好 mmap，必须理解它和传统 IO 在内核路径上的区别。我尽量用大白话解释，但该有的概念一个不落。

2.1 传统 IO 为什么会有两次拷贝和一次系统调用

传统 read 路径是这样的：进程发起 read(fd, buf, len)，陷入内核态；内核根据 fd 找到对应的文件，检查页缓存里有没有目标数据；如果没有，发起磁盘 IO 把数据读进页缓存；然后把页缓存中的数据拷贝到用户态缓冲区；最后返回用户态。

这里最容易被忽略的代价是：即使数据已经在内核页缓存里了，read 仍然必须经历一次“内核态拷贝到用户态”，外加一次完整的系统调用上下文切换。为什么不能直接让用户态访问页缓存？因为安全——用户态进程不能随便拿内核管理的物理页。而 mmap 做的，就是让内核对进程的页表做了一次特殊设置：把文件页映射进进程的虚拟地址空间。从此进程访问这块地址，就直接访问页缓存里的物理页面，少了一次拷贝，也少了系统调用（只要不触发缺页）。

一句话总结：传统 IO 是“你去拿，我复制给你”；mmap 是“这块地直接归你管，你自己走进去”。

2.2 页表、缺页异常和 readahead 协作

进程虚拟地址不是直接对应物理地址的，中间隔着一层页表。mmap 系统调用做的事情，本质上就是在进程的虚拟地址空间里划出一块区域，并且建立“虚拟页 -> 文件页”的映射关系，但不一定立刻分配物理页。

第一次访问某个虚拟页时，CPU 查页表发现这一页没有物理页对应，触发缺页异常（page fault）。缺页异常处理函数根据 VMA（虚拟内存区）的映射信息，判断这是一个文件映射，于是从页缓存里找目标页；没有就从磁盘读入页缓存，再建立页表项，返回用户态。这整个过程对于程序员来说是透明的。

内核还会做 readahead（预读）。如果你按顺序访问文件，缺页异常会导致内核预测你会连续读后面的页，然后提前把多页加载到页缓存。这就是为什么顺序扫描一个 mmap 文件，虽然第一次访问会产生缺页异常，但后面的很多页已经在内存里了，速度会非常快；而随机访问时，readahead 的收益不大，甚至可能造成无效预读，所以要用 madvise 告诉内核你的访问模式。

2.3 MAP_SHARED 与 MAP_PRIVATE 的区别，一字之差天壤之别

很多初学者搞不清楚这两个标志到底代表什么。它们决定了映射的“写语义”，也就是写操作对其他进程和底层文件是否可见。

MAP_PRIVATE 的典型用途是让进程像“拿了一份文件快照”一样工作，但又不真正复制文件内容。比如动态加载器在加载共享库时，代码段用 MAP_PRIVATE 映射，如果某个进程对库的代码段做了修改（极端情况，比如自修改代码），修改只对当前进程有效，不会污染磁盘上的文件，也不会影响其他进程。

但要注意，MAP_PRIVATE 的写时复制是发生在“页”级别上的。第一次写某一页时，内核会复制这一页，之后这一页的修改都在私有副本里。这个副本是内存页，不会被写回文件。我见过有人想用 MAP_PRIVATE 做事务回滚——先映射，再修改，出错后重新映射就“回滚”了。这个思路可行，但风险在于：如果页已经被写时复制并且被内核回收，重新映射确实能回到文件版本，但内存中的私有修改就丢了，不能作为可靠的持久化方案。

2.4 msync 与脏页回写：数据什么时候真正落到磁盘

MAP_SHARED 映射下，你写的页面首先被标记为脏页，然后由内核后台线程（比如 pdflush 或 flusher 线程）在合适的时机写回磁盘。这个过程是异步的，所以程序只调用 write（对映射区的赋值）就退出，数据可能还没真正落盘。这时系统崩溃，数据就丢了。

要强制同步，必须调用 msync。这是 mmap 最容易被忽略的配套调用。msync(addr, len, MS_SYNC) 会同步刷新指定范围的脏页到磁盘，阻塞直到完成；MS_ASYNC 只是异步调度写回，不等待。我在做持久化存储的时候，每次写完关键数据都会调用 msync，确保数据在返回成功之前已经落盘。这个语义和传统 write 写入后调用 fsync 是等价的。

正因为 msync 涉及到同步阻塞和磁盘 IO，它不是免费的。高频小写入的情况下，如果每次都 msync，性能可能不如传统 write + fsync，因为传统 write 先进入页缓存，页面合并后由内核统一回写；而 mmap 每次小写入都会改动一个页面的很小的部分，如果页被频繁同步，写放大问题就会很明显。这一点放到后面的选型建议里细说。

3. 大文件实战：从40GB日志秒开说起

现在聊点实操。大文件处理是我认为 mmap 最值得用、也最容易看到效果的一类场景。

3.1 40GB 日志文件，如何做到“秒开”

所谓“秒开”，并不是真的把 40GB 载入内存，而是打开文件、建立映射、开始扫描这个过程几乎瞬间完成。mmap 系统调用本身只建立映射关系，不读数据，所以即使文件是 40GB，mmap 的耗时也只在微秒到毫秒级别，具体取决于页表操作数量。

真正耗时的是你第一次访问某个页面。但这也没关系，因为顺序扫描时，内核的 readahead 会提前加载大量页，实际遍历速度接近纯内存读取。我在处理 40GB 日志时，打开文件后直接 mmap，然后开启 8 个线程，每个线程负责文件的一个区间，用指针直接解析字符串。整个文件扫描加统计的时间从原来的几十分钟（用 fgets）降到了几分钟以内。

这里有个细节：多线程扫描时，每个线程应尽量连续处理一段地址区间，而不是让所有线程交错读取同一页，否则会造成同一页被多个线程反复访问，触发不必要的锁竞争和缓存抖动。我是把文件按页边界对齐切分成多个区间，每个线程只处理自己的区间。

3.2 用 madvise 管理预读策略

Linux 提供了 madvise 系统调用，可以告诉内核你对映射区域的访问模式，让内核调整预读和缓存策略。

• MADV_SEQUENTIAL：告诉内核你会顺序访问。内核会加大预读窗口，并可能在访问过后尽快释放页面，避免缓存被无用的旧页占据。
• MADV_RANDOM：告诉内核你会随机访问。内核会减少预读，避免浪费 IO。
• MADV_WILLNEED：告诉内核你很快会访问某个区域。内核会主动把这段区域读入内存，相当于给了个“热需求”提示。
• MADV_DONTNEED：告诉内核这段区域你暂时不需要了，内核可以优先回收这些页。

在大文件顺序扫描场景，MADV_SEQUENTIAL 效果最明显。我在日志扫描程序里，完成映射后就调用 madvise，扫描速度还有小幅提升，因为内核不会做无谓的预读过量，也不会因为内存压力提前丢弃后续需要的页。

3.3 冷热数据分离的映射方案

大文件里往往大部分数据是“冷”的，只有一小部分是“热”的。比如一个历史订单文件，可能只有最近一周的数据会被频繁查询。这种情况我倾向于把文件切成多个映射区间，而不是把整个文件一次性映射。

比如一个 20GB 的订单数据文件，我会根据索引里的时间范围，把最近一周的数据区间映射为常驻内存的热区（配合 MAP_POPULATE 或 MADV_WILLNEED 预加载），历史数据则映射为普通区域，按需缺页。这样做的好处是，热区数据不会因为冷数据的顺序扫描而被挤出页缓存，冷区数据也不会因为预读过量浪费内存。

注意 MAP_POPULATE 只在 Linux 上支持，而且如果文件区域很大，它会立刻触发大量磁盘 IO，导致映射时间变长。不要一看到“预加载”就往大范围上怼，只对真正频繁访问的热区域使用。

4. 多进程共享内存：一个比消息队列更省心的方案

内存映射文件另一个高级应用场景是进程间通信（IPC）。多个进程把同一个文件映射到自己的虚拟地址空间，内核保证这些映射对应到同一物理页面，于是进程之间就通过网络（内存总线）交换数据，比 pipe、消息队列、socket 都高效。

4.1 共享文件映射的同步问题

共享内存映射必须解决并发控制问题。两个或更多进程同时写同一块内存，数据会相互覆盖。我见过有人直接把一个结构体放在共享内存里，多个进程各自往里面写字段，结果初看没问题，一上线数据就错乱。本质原因是结构体的不同字段不是原子更新的，进程 A 写到一半，进程 B 读取到半新半旧的数据。

解决并发一致性的通用手段是加锁。在共享内存映射里，可以用基于原子操作的自旋锁，也可以用 POSIX 信号量（sem_t）。我自己的习惯是：临界区小、持锁时间短，用自旋锁或原子 CAS；临界区可能发生阻塞（比如持有锁的同时做网络 IO），用信号量或 futex，避免浪费 CPU 空转。

4.2 一个无锁环形缓冲区的实现

如果本身就是单生产者、单消费者模型，连锁都可以省掉。我实现过一个日志采集组件，生产者进程把日志写入共享内存里的环形缓冲区，消费者进程从缓冲区读取并转发到下游。生产者和消费者各自维护一个 write_seq 和 read_seq，这两个序列号用原子变量存在共享内存头部。

生产者写入数据前先检查 (write_seq - read_seq) 是否达到缓冲区上限；消费者读取前检查是否有新数据。核心数据结构如下：

c复制struct ring_header {
    _Atomic uint64_t write_seq;
    _Atomic uint64_t read_seq;
    char padding[48];
};

struct ring_buffer {
    struct ring_header header;
    char data[1024 * 1024 * 64];  // 64MB 数据区
};

生产者的写入逻辑简化后是这样：

c复制uint64_t prod_acquire(struct ring_buffer *rb, size_t len) {
    uint32_t max_wait = 1000000;
    while (max_wait--) {
        uint64_t w = atomic_load_explicit(&rb->header.write_seq, memory_order_relaxed);
        uint64_t r = atomic_load_explicit(&rb->header.read_seq, memory_order_acquire);
        uint64_t used = w - r;
        if (used + len <= RING_CAPACITY) {
            return w;
        }
        sched_yield();
    }
    return UINT64_MAX;  // 超时
}

因为有环形缓冲区的天然限制，生产者和消费者不会真正写到同一块内存，只是通过原子计数协调读写位置。write_seq 和 read_seq 都是单调递增的，不存在 ABA 问题。实测下来，这个方案在单生产者单消费者场景里可以达到接近纯内存的吞吐，延迟比 pipe 低一个数量级以上。

4.3 用共享映射做配置热更新

配置热更新也是 mmap 的经典应用场景。传统做法是进程监听配置文件变化，重新读取并解析。但多个进程同时热更新配置时，很难保证所有进程用的是同一份“快照”数据。

改用共享内存映射后，我通常在共享映射区里放一个带版本的配置块：

c复制struct config_block {
    uint64_t version;
    uint64_t data_len;
    char data[0];  // 实际配置数据，比如 JSON 或 protobuf 序列化后的字节
};

配置更新进程先从文件读取新版配置，序列化到一块内存，然后原子地把 version +1，最后更新 data 区域。读取进程每次使用配置前，快速读取 version，只要 version 没变，配置数据就是一致快照（前提是版本号在最后更新，并且写入时用内存屏障保证顺序）。如果 version 变了，重新从共享内存加载 data。

这种方式比“每个进程各自读文件、各自解析”快得多，而且天然保证所有进程看到同一版本配置。要注意的是：一定要保证单个配置块的大小是固定的或者有充分边界检查，否则一个进程写坏了版本号，其他进程拿着错误版本去解析 data，可能会越界访问，触发 SIGBUS 或 SIGSEGV。

5. 持久化数据结构：免序列化的索引设计

我在做一个轻量级嵌入式存储引擎时，用到了 mmap 更“高级”的玩法——直接把数据结构映射到文件上，数据即内存、内存即数据，省掉了序列化和反序列化。

5.1 为什么不用反序列化

传统做持久化的方式是：内存里维护一个结构体，每次需要保存时，把结构体序列化成字节流，写入文件；启动时读入文件，反序列化回结构体。序列化本身有 CPU 开销，而且如果结构体很大（比如几十 GB 的索引），加载和保存过程都极其耗时。

用 mmap 可以直接在映射文件上操作数据结构。比如一个哈希索引，把桶数组、条目链表指针都布局在 mmap 文件里，进程启动后 mmap 一下，所有指针直接有效；不需要解析任何字节流，因为数据在磁盘上的布局就是进程内存里的布局。

当然，这里有个前提：你的数据结构里不能存“进程虚拟地址指针”，只能存“文件内偏移量”。因为不同进程 mmap 同一个文件时，映射的虚拟地址可能不同，存进程地址会导致另一个进程访问到无效地址。我用 uint64 偏移量代替指针，使用时通过基地址加偏移换算成真实地址。

5.2 一个简易持久化 KV 索引设计

我设计过一个简单的持久化 KV 索引，文件布局如下：

• Header（固定 256 字节）：魔数、版本号、桶数量、记录数量、空闲链表头偏移。
• Bucket array：每个桶是一个 uint64 偏移量，指向该桶第一条记录。
• Record 区域：每条记录包含 key、value、next 偏移量、记录状态（有效/已删除）。

关键代码思路：

c复制#define MAGIC 0x4D4D4150  // "MMAP"

typedef struct {
    uint32_t magic;
    uint32_t version;
    uint64_t bucket_count;
    uint64_t record_count;
    uint64_t free_list_head;
} file_header;

typedef struct {
    uint64_t key;
    uint64_t value;
    uint64_t next;
    uint8_t  status;
} record;

// 初始化时把文件映射进来，初始化 header
void db_init(const char *path) {
    int fd = open(path, O_RDWR | O_CREAT, 0644);
    ftruncate(fd, INITIAL_FILE_SIZE);
    char *base = mmap(NULL, INITIAL_FILE_SIZE, PROT_READ | PROT_WRITE,
                      MAP_SHARED, fd, 0);
    file_header *hdr = (file_header *)base;
    // 第一次使用时初始化 header 和 bucket array
    // 之后使用时直接读取
}

// 查找 key：从桶偏移出发，沿 next 指针遍历
record *db_get(char *base, uint64_t key) {
    file_header *hdr = (file_header *)base;
    uint64_t idx = hash(key) % hdr->bucket_count;
    uint64_t off = ((uint64_t *) (base + sizeof(file_header)))[idx];
    while (off != 0) {
        record *r = (record *)(base + off);
        if (r->status == 1 && r->key == key) {
            return r;
        }
        off = r->next;
    }
    return NULL;
}

这里的核心技巧是：所有“指针”都是文件内偏移量。base + off 才是真实的虚拟地址。这样做的好处是，即使文件被不同进程在不同虚拟地址映射，偏移量依然有效。

5.3 崩溃恢复与数据一致性的现实约束

直接用 mmap 做持久化数据结构，最大的难点是崩溃一致性。你写了一个 record，修改了桶数组的偏移，然后又修改了 header 的 record_count。这三个改动分布在不同的页面里，如果写完 record 后系统崩溃，桶数组可能还指向旧位置，数据就“丢了”或产生孤儿记录。

我的做法是引入类似 WAL（预写日志）的思路，但简化处理：写数据前，先把一条“变更记录”追加到另一个日志文件并 msync；然后再更新内存映射区；更新完毕后，再写一条“提交标记”到日志文件并 msync。恢复时，如果日志里有未提交的变更，就回放或丢弃。

实在不想写 WAL 的话，至少要做到“先写数据页，再写索引页”。这样即使崩溃，最多出现索引还指着旧数据，但不会出现数据页被部分写入导致的关键结构损坏。当然这是用“最终一致”换“简化的实现”，对强一致性的业务要谨慎使用。

6. 踩坑实录：SIGBUS、文件截断与脏页丢失

这部分是我最想写的，因为网上讲 mmap 如何强大的人很多，讲坑的人太少。我用 mmap 做共享内存、做持久化索引，前前后后踩了不少坑，有些坑非常隐蔽，排查起来极其费时。

6.1 文件被截断导致进程崩溃：SIGBUS 的根因与预防

SIGBUS 是 mmap 用户最常遇到的崩溃信号。它的触发原因是：进程访问了“映射区域内但文件大小已经覆盖不到”的页面。

举个例子：进程 A mmap 了一个文件，长度是 1GB。进程 B 这时用 ftruncate 把文件截断到 100MB。进程 A 访问映射区域内第 200MB 的那一页时，内核发现这个虚拟页在打开的文件里已经没有对应数据了，无法满足访问，于是向进程发送 SIGBUS，进程直接死掉。

我遇到过一次很实际的场景：多个进程共享一个数据文件，某个模块错误地在启动时重新初始化文件，调用了 ftruncate 清零，结果其他正在运行的进程集体 SIGBUS。排查了很久才定位到是 ftruncate 的锅。

预防方式：

• 对共享文件，必须约定好生命周期管理，不允许运行中的进程随意截断文件。
• 如果不得不动态调整文件大小，一定要在调整后用 msync 或信号量通知其他进程重新 mmap，并保证在旧映射无效前，其他进程不会访问超出新范围的部分。
• 代码里可以捕获 SIGBUS 信号，记录日志，但很难做到“优雅恢复”，因为被中断的可能是一段任意代码。所以目标是避免触发，而不是事后补救。

6.2 系统崩溃后 mmap 数据去哪了：msync 的正确姿势

mmap 的 MAP_SHARED 映射下，数据写入页缓存，内核延迟回写磁盘。如果进程正常运行，退出前内核也会把脏页刷盘。但如果系统崩溃（断电、内核 panic），只有已经写完的部分数据会保留，未同步的脏页会丢失。

而且脏页丢失的量是不可预测的。前一秒你赋值的数据可能还在页缓存里，下一秒系统断电，数据就没了。要保证持久化，必须主动调用 msync。我踩过的坑是：早期版本的程序只在退出时调用一次 msync，结果进程被 kill -9 时，最后一小段时间的写入数据完全丢失。后来改成了每处理一批数据就 msync 一次。

msync 的粒度也需要斟酌。msync 一个很大的区域会阻塞较长时间，因为内核要把所有脏页刷盘。如果数据是分批产生的，最好按批同步地址范围。另外，在同步前记得加内存屏障，确保你的写操作在 CPU 缓存层面已经可见（虽然 x86 上通常不需要，但在其他架构上要小心）。

6.3 并发写同一页的隐藏冲突：不只丢数据那么简单

多个进程 MAP_SHARED 映射同一个文件，如果它们同时写同一个页面，结果不仅仅是数据错乱那么简单。页面是内核管理的，两个进程同时映射同一页，写操作会直接落到同一物理页上。这时如果需要页面回写，内核会把整个页面回写，而两个进程的修改会混杂在一起，形成不可预期的中间状态。

更隐蔽的是，如果某个进程对某个页进行了 MAP_PRIVATE 映射（比如加载共享库时），写操作触发写时复制，其他进程看到的数据不变，但这会导致同一文件的不同部分在不同进程里处于不同的可见性状态，调试时容易产生“为什么我用共享映射改了，对方看不到”的困惑。

解决思路很明确：加锁，或者按区隔离。多进程写同一个文件时，每个进程只写属于自己的偏移区间，用原子计数器协调边界；必须写共享区时，用信号量或锁保护。

7. 调优组合拳：madvise、mprotect、mlock与Huge Pages

性能调优是 mmap 高级用法里最吸引人的部分。这部分我会讲几个我实际用过的优化手段，以及它们什么时候有效、什么时候无效。

7.1 madvise 的几种策略何时生效

前面提过 MADV_SEQUENTIAL、MADV_RANDOM 和 MADV_WILLNEED。这里补充一个实践细节：madvise 是“建议”而不是“指令”，内核可以忽略它。在大多数 Linux 内核上，MADV_DONTNEED 是有效的，会立即释放指定范围的页；MADV_WILLNEED 通常也会触发预读。但 MADV_SEQUENTIAL 的效果在不同内核版本上有差异，调优时不能依赖它，最好先验证实际性能变化。

我使用的策略是：

• 顺序扫描场景：映射后立刻 madvise(MADV_SEQUENTIAL)。
• 随机访问场景：madvise(MADV_RANDOM)。
• 热点数据需要预加载且数据量不大（几百 MB 以内）：mmap 后用 madvise(MADV_WILLNEED)，或者直接用一个线程按顺序访问一遍，触发预读。

7.2 用 mprotect 给只读热数据加保护

mprotect 可以修改映射区域的访问权限。对于只读的映射区域（比如代码段、配置数据、索引文件），设置 PROT_READ 可以防止意外写入。更重要的是，它能让内核的缺页异常处理更高效，因为不需要为写操作做准备。

我在做只读索引文件时，mmap 的 flags 会带上 PROT_READ，并且在加载完成后调用 madvise(MADV_RANDOM) + mprotect 保持只读。这样一旦有代码尝试写索引，立刻触发 SIGSEGV，能尽早暴露 bug，而不是让数据悄悄被改坏。

7.3 什么时候才该用 mlock 和 Huge Pages

mlock 可以把指定内存区域锁定在物理内存中，防止被 swap 换出。对延迟非常敏感的应用（比如交易系统、实时数据处理），map 的文件区域如果是热点数据，不想在访问时因为换页产生延迟抖动，就可以 mlock。

但 mlock 是有代价的：锁住的内存不能被回收，相当于占用了物理内存。锁太多会导致整个系统内存紧张，甚至触发 OOM。所以要谨慎设置锁定范围，只锁真正热的小段区域。

Huge Pages 也是类似思路：减少页表项数量，减少 TLB miss，提高大内存访问性能。透明大页（THP）开起来很方便，但也有坑——它可能导致 mmap 映射的内存页变大，进而让缺页加载的粒度变大，如果访问模式是稀疏随机访问，反而浪费内存和 IO。我倾向于在数据库等大内存工作负载场景使用显式 Huge Pages，并且精确控制映射区大小，而不是全局开 THP。

8. mmap不是银弹：什么场景该老老实实用read/write

写到这里必须泼点冷水。mmap 很强大，但它绝不是万能的。我在项目里见过不少人盲目地把所有文件读写都改成 mmap，结果性能不升反降，还引入了一堆并发和一致性问题。

8.1 小文件频繁创建与删除：mmap 反而更慢的场景

如果你处理的是大量小文件，每个文件几十 KB 到几 MB，而且生命周期很短，创建后写入，读完就删除，那么用 mmap 并不划算。每次 mmap 都要建立虚拟内存区间，牵涉到页表操作，虽然已经优化过，但比一次 read 系统调用要重；而小文件的读写本身很快，系统调用开销占比不大，mmap 的优势发挥不出来。

另一种情况是网络文件系统（NFS、CIFS）上的文件。这类文件系统对 mmap 的支持虽然存在，但一致性语义和本地文件系统不同，特别容易出现数据可见性和刷新问题。如果你的文件在 NFS 上，我建议优先用普通的 read/write，配合 fsync，而不是 mmap。

8.2 延迟敏感、长事务、磁盘可靠性：这些场合适用 read/write

mmap 的缺页异常是异步发生的。你访问一个页面时，如果它不在内存里，进程会阻塞在缺页异常处理上，这个延迟是不可预测的——可能几微秒，也可能几毫秒，取决于磁盘延迟和内核的 IO 调度。对延迟抖动要求极高的场景（比如高频交易、实时控制），这种不可预测的阻塞是致命的。而传统 read 的阻塞可以更精确地控制预读和缓冲，延迟曲线通常更平滑。

数据库类应用对持久化的一致性要求极高。mmap 的脏页回写时机由内核决定，虽然能通过 msync 强制刷盘，但很难做到传统 write + fsync + WAL 那样精细的落盘时序控制。PostgreSQL 的官方文档里就明确说它对数据文件使用传统的 read/write，而不是 mmap，很大一部分原因就是不想让内核的页面回收策略干扰数据库的 buffer pool 管理和崩溃恢复逻辑。

8.3 我自己的选型决策表

实战中我是按下面这张表来决定的：

这表不是金科玉律，但它能帮你在决定用不用 mmap 的时候，快速理清思路。核心判断标准是：你的场景里，mmap 的页面缓存管理优势能不能抵消它的页错误延迟和一致性复杂度。

最后再分享一个我个人的小习惯：不管用哪种方案，上线前一定会做故障注入测试，模拟进程崩溃、系统掉电、文件被外部截断等场景，确认数据的丢失范围和一致性表现符合预期。内存映射文件确实是把双刃剑，用好了效率惊人，用不好就是线上事故的温床。多做测试，比多读十篇博客都有用。