内存映射文件：mmap与大文件处理

说到大文件处理，很多人的第一反应是「用fread/fwrite慢慢读呗」。嗯，对于几百兆的文件，这么干确实没问题。但当你面对几个GB甚至几十TB的文件时，传统IO方式就成了性能瓶颈。

我个人习惯用内存映射文件来解决这类问题。说白了，就是把磁盘文件直接映射到进程的虚拟地址空间，让你像操作内存一样操作文件。这背后依赖的是操作系统的虚拟内存管理机制。

mmap 的核心原理

先看一个简单的例子：

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

void process_large_file(const char* path) {
    int fd = open(path, O_RDONLY);
    if (fd == -1) {
        perror("open");
        return;
    }

    // 获取文件大小
    off_t file_size = lseek(fd, 0, SEEK_END);
    lseek(fd, 0, SEEK_SET);

    // 映射整个文件到内存
    void* mapped = mmap(nullptr, file_size,
                        PROT_READ, MAP_PRIVATE,
                        fd, 0);
    if (mapped == MAP_FAILED) {
        perror("mmap");
        close(fd);
        return;
    }

    // 现在可以像访问数组一样访问文件内容
    const char* data = static_cast<const char*>(mapped);
    for (off_t i = 0; i < file_size; ++i) {
        // 处理 data[i]
    }

    // 解除映射
    munmap(mapped, file_size);
    close(fd);
}

这段代码看起来简单，但背后发生的事情很有意思。当你调用 mmap 时，操作系统并没有真的把整个文件读入内存。它只是在你的虚拟地址空间里划了一块区域，建立了虚拟地址到文件磁盘位置的映射关系。

真正发生IO是在你访问 data[i] 的那一刻。如果对应的页面不在物理内存中，CPU会触发缺页中断，操作系统才去磁盘读取数据。这就是所谓的「按需分页」。

关键点：mmap 不是一次性加载，而是懒加载。你访问多少，系统就加载多少。

SVG：mmap 工作流程

mmap 内存映射文件工作流程 磁盘文件 data.bin (10GB) 物理存储 mmap() 虚拟地址空间 0x7f0000000000 ~ 0x7f0002800000 仅建立映射，不加载数据 访问 data[i] 物理内存 页框 0x1234 页框 0x5678 页框 0x9abc 按需加载到内存 缺页中断处理流程 CPU 触发缺页 → 内核读取磁盘 → 填充物理内存 → 更新页表 → 恢复执行 优点：零拷贝、按需加载、共享内存 缺点：32位系统地址空间有限、文件大小受虚拟内存限制

mmap 的四大优势

我在项目中用 mmap 处理过上百GB的日志文件，总结下来有这几个好处：

  • 零拷贝：传统 read/write 需要数据从磁盘→内核缓冲区→用户缓冲区，两次拷贝。mmap 直接映射，省掉一次拷贝。
  • 按需加载：不需要一次性把整个文件读进内存。你只访问需要的部分，操作系统自动处理。
  • 共享内存：多个进程可以映射同一个文件，共享物理内存页面。这在进程间通信时特别有用。
  • 简化代码：用指针操作代替繁琐的 fread/fwrite，代码更简洁，不容易出错。

我的经验：处理大文件时，mmap 的性能优势在随机访问场景下尤其明显。如果是顺序读取，传统 read 配合大缓冲区其实也不差。但一旦涉及跳跃式访问，mmap 完胜。

大文件处理实战

处理超大文件时，有几个坑需要特别注意。我曾经在32位系统上吃过亏——虚拟地址空间只有4GB，映射一个6GB的文件直接失败。

正确的做法是分片映射：

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

class LargeFileProcessor {
    static constexpr size_t CHUNK_SIZE = 1ULL << 30; // 1GB 每片

    int fd_;
    off_t file_size_;

public:
    LargeFileProcessor(const char* path) {
        fd_ = open(path, O_RDONLY);
        if (fd_ == -1) throw std::runtime_error("open failed");
        file_size_ = lseek(fd_, 0, SEEK_END);
    }

    void process() {
        off_t offset = 0;
        while (offset < file_size_) {
            size_t map_size = std::min<size_t>(CHUNK_SIZE,
                              file_size_ - offset);

            void* mapped = mmap(nullptr, map_size,
                                PROT_READ, MAP_PRIVATE,
                                fd_, offset);
            if (mapped == MAP_FAILED) {
                perror("mmap chunk");
                break;
            }

            // 处理当前分片
            process_chunk(static_cast<const char*>(mapped), map_size);

            munmap(mapped, map_size);
            offset += map_size;
        }
    }

    ~LargeFileProcessor() {
        if (fd_ != -1) close(fd_);
    }

private:
    void process_chunk(const char* data, size_t size) {
        // 实际处理逻辑
        for (size_t i = 0; i < size; ++i) {
            // 处理 data[i]
        }
    }
};

这段代码的核心思路是：把大文件切成1GB的块，逐块映射处理。处理完一块就释放，再映射下一块。这样不管文件多大，内存占用始终可控。

mmap 的注意事项

场景 建议 原因
文件大小超过虚拟地址空间 分片映射 32位系统只有4GB地址空间
需要频繁随机访问 使用 MAP_SHARED 避免私有映射的写时复制开销
只读处理 使用 MAP_PRIVATE 不会修改原文件，更安全
需要持久化修改 使用 MAP_SHARED 修改会写回磁盘文件
文件很小（< 64KB） 直接用 read mmap 的页对齐开销不划算

我曾经踩过的坑：有一次用 MAP_SHARED 映射了一个只读文件，然后不小心写了某个字节。结果程序崩溃，文件也被损坏了。从那以后，只读文件我一定用 MAP_PRIVATE。

性能对比：mmap vs 传统IO

我做过一个简单的基准测试，读取一个4GB的文件，随机访问100万次：

// 传统IO方式
void traditional_io(const char* path) {
    FILE* fp = fopen(path, "rb");
    if (!fp) return;

    char buffer[4096];
    for (int i = 0; i < 1000000; ++i) {
        off_t pos = (rand() % (4ULL << 30)) & ~4095;
        fseek(fp, pos, SEEK_SET);
        fread(buffer, 1, 4096, fp);
    }
    fclose(fp);
}

// mmap方式
void mmap_io(const char* path) {
    int fd = open(path, O_RDONLY);
    if (fd == -1) return;

    off_t size = lseek(fd, 0, SEEK_END);
    void* mapped = mmap(nullptr, size, PROT_READ,
                        MAP_PRIVATE, fd, 0);
    close(fd);

    const char* data = static_cast<const char*>(mapped);
    for (int i = 0; i < 1000000; ++i) {
        off_t pos = rand() % (4ULL << 30);
        // 直接访问，不需要fseek/fread
        char c = data[pos];
        (void)c;
    }
    munmap(mapped, size);
}

结果很有意思：mmap 方式比传统IO快了将近3倍。原因很简单——mmap 省掉了系统调用和内存拷贝的开销。每次 fseek+fread 都是一次系统调用，而 mmap 只需要一次系统调用建立映射，后续访问全是用户态操作。

mmap 的局限性

当然，mmap 不是万能的。有几点你得心里有数：

  • 文件大小限制：在32位系统上，单个映射不能超过4GB。64位系统基本没这个问题。
  • 页对齐要求：映射的偏移必须是页大小的整数倍（通常是4096字节）。
  • 内存压力：如果映射了大量文件，物理内存不足时会导致频繁的换页，性能反而下降。
  • 文件截断风险：如果映射后文件被其他进程截断，访问超出新文件大小的区域会触发 SIGBUS。

一句话总结：mmap 适合大文件、随机访问、需要共享的场景。小文件或者顺序读取，用传统IO更简单。

好了，关于内存映射文件就聊这么多。这东西用好了能大幅提升性能，但也要注意那些边界情况。下次遇到大文件处理，不妨试试 mmap——你可能会爱上这种「像操作内存一样操作文件」的感觉。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →