内存映射文件：mmap在大型序列中的使用

为什么我离不开mmap

做宏基因组分析，动不动就是几十GB甚至上百GB的FASTA/FASTQ文件。刚开始那几年，我傻乎乎地用传统read()读全文件，结果内存炸得一塌糊涂。后来接触了mmap，才算真正解决了“文件太大，内存太小”的困境。

说白了，mmap就是把一个文件直接映射到进程的虚拟地址空间。你不需要一次性把整个文件读进内存，操作系统会按需加载那些真正被访问的页。你想想看，我们分析序列时经常是随机扫描——比如BLAST时跳来跳去找比对位置，mmap在这种场景下简直就是为性能而生的。

mmap核心优势

• 零拷贝：数据在磁盘和内存之间只映射一次指针，没有read()/write()的两次拷贝。
• 按需分页：只把正在访问的页调入物理内存，超大文件也不怕。
• 共享内存：多个进程可以mmap同一个文件，实现高效数据交换。
• 简洁编码：你可以像操作数组一样操作文件内容，不需要手动管理缓冲区。

什么时候该用mmap？

我总结过一张场景速查表，直接给你看：

场景	推荐mmap？	原因
顺序读取整个FASTA	不一定	传统read更快，因为顺序IO有预读优化
随机访问索引序列（如BWA、minimap2）	强烈推荐	按需分页，避免预读浪费
多进程同时读取同一参考基因组	强烈推荐	共享映射，节省物理内存
小文件（< 1GB）	随你	两种方式差别不大
需要修改文件内容	可以（但注意写保护）	mmap也能写，但共享写要加同步

实战：用mmap读取大型FASTA

这是我最常用的一段代码，处理30GB的参考基因组毫无压力：

# Python示例：mmap读取FASTA
import mmap
import os

def mmap_fasta(fa_path):
    fd = os.open(fa_path, os.O_RDONLY)
    try:
        with mmap.mmap(fd, 0, access=mmap.ACCESS_READ) as m:
            # m就是整个文件内容，像bytes一样操作
            pos = 0
            while True:
                # 找到下一个'>'
                start = m.find(b'>', pos)
                if start == -1:
                    break
                end = m.find(b'>', start + 1)
                if end == -1:
                    end = len(m)
                # 提取序列头部
                header = m[start: m.find(b'\n', start)]
                # 提取序列（去掉换行）
                seq = m[start: end].replace(b'\n', b'')
                # 处理...
                print(header.decode(), len(seq))
                pos = end
    finally:
        os.close(fd)

C语言版本更贴近底层，适合嵌入工具：

#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main() {
    int fd = open("genome.fa", O_RDONLY);
    struct stat sb;
    fstat(fd, &sb);
    char *addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
    // 现在addr就是一个大字符数组
    // 可以直接指针运算
    close(fd);
    // 使用完毕后munmap
    munmap(addr, sb.st_size);
    return 0;
}

避坑指南：我从6次崩溃中学到的

• 不要用read()把mmap映射的内容全部读入内存 —— 那违背了按需加载的初衷。
• 文件大小超过虚拟地址空间（32位系统约2GB）时，必须使用MAP_FIXED分段映射，或者升级到64位系统。
• 频繁写操作时，建议用MAP_SHARED并配合msync，否则断电会丢数据。
• 小心文件截断：如果映射后外部修改了文件大小，访问超出部分会触发SIGBUS。我的一个管道脚本就是因此半夜报警。

mmap vs 传统IO性能对比

我曾在真实25GB的宏基因组测序数据上做过对比：

方法	随机访问1百万次序列	顺序读取全文件	内存峰值
传统read()+缓冲区	85秒	12秒	25GB（全读）
传统read()+lseek随机	342秒	15秒	4KB
mmap随机访问	21秒	14秒	约12GB（按需）
mmap+顺序遍历优化	19秒	11秒	约8GB

你看，随机访问场景下mmap快了16倍。但要注意，顺序读取时mmap并没有绝对优势——传统IO有个预读机制，对于大文件连续读反而略快。所以我把mmap主要用在索引、搜索这类“跳着读”的场景。

一张图看懂mmap流程

下面这张SVG图把传统read()和mmap的路径画清楚了：

我的一点实践经验总结

如果你要处理超过10GB的序列文件，我的建议很直接：非顺序访问场景一律上mmap。顺序读取全文件可以继续用传统IO，毕竟你不需要那么复杂的内存管理。

但有个例外——如果你有多进程并行分析同一个大文件（比如同时跑16个线程的minimap2），mmap能帮你节省大量物理内存。每个进程共享同一份映射页，系统只需要保留一份磁盘cache，而不是每个进程各一份。

对了，还有个小技巧：MAP_POPULATE标志可以提前预加载映射页。如果你知道马上要访问整个文件，用这个标志能减少缺页中断的次数。但慎用——它会瞬间吃掉大量物理内存。

mmap不是银弹，但对付巨型序列文件，它是我工具箱里最趁手的家伙。用好它，你的工具就能在128GB内存的机器上处理1TB的宏基因组数据——前提是你别一次性遍历全部映射区域。