mmap比fread更快的关键在于绕过内核缓冲区拷贝，实现零拷贝内存访问：它将文件页直接映射至进程虚拟地址空间，避免反复系统调用与用户态/内核态切换，尤其适合大文件的随机读、重复读或部分加载场景。
mmap 为什么比 fread 更快？关键在绕过内核缓冲区拷贝
直接用 mmap 读大文件（比如 >100MB）时，性能优势主要来自零拷贝：数据不经过 read() 系统调用的用户态/内核态反复拷贝，而是让虚拟内存直接指向页缓存。但这个优势只在**随机访问、重复读、或需部分加载**时成立；顺序遍历小文件反而可能更慢——因为 mmap 需要建立 VMA 区域、触发缺页中断，有初始化开销。
- 适用场景：
mmap适合读取固定格式的大日志、数据库索引、二进制资源包；不适合流式处理或只读一次的小配置文件 - 必须搭配
MAP_PRIVATE | MAP_POPULATE（Linux）或FILE_MAP_READ+MapViewOfFileEx（Windows）才能预加载页面，避免运行时缺页卡顿 - 注意
mmap失败时返回MAP_FAILED（不是nullptr），且失败后 errno 可能是ENOMEM（虚拟地址空间不足）或EINVAL（文件长度为 0 或 offset 超限）
Windows 上 CreateFileMapping 的常见陷阱
Windows 的内存映射 API 比 POSIX 更繁琐，容易在句柄权限和映射标志上出错。最常踩的坑是：用 GENERIC_READ 打开文件，却传 PAGE_WRITECOPY 给 CreateFileMapping——这会导致映射失败，错误码为 ERROR_INVALID_PARAMETER。
- 文件必须以
GENERIC_READ（只读）或GENERIC_READ | GENERIC_WRITE（可写）打开；CREATE_ALWAYS或TRUNCATE_EXISTING会清空文件，慎用 -
CreateFileMapping的flProtect参数必须与文件打开权限匹配：PAGE_READONLY对应只读文件，PAGE_READWRITE对应可写文件 -
MapViewOfFileEx的dwDesiredAccess必须与flProtect兼容，例如FILE_MAP_READ不能用于PAGE_READWRITE映射 - 务必检查返回值：
INVALID_HANDLE_VALUE表示CreateFileMapping失败；nullptr表示MapViewOfFileEx失败
C++ RAII 封装 mmap 时如何避免资源泄漏
裸用 mmap/munmap 容易漏掉释放，尤其在异常路径中。RAII 封装的核心是：构造时映射，析构时解映射，并把映射地址和长度作为成员变量保存。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要在构造函数里直接抛异常——
mmap失败时应返回错误码或std::optional，否则栈展开时可能munmap未定义行为 - 映射地址必须用
static_cast<char*>转换，不能用reinterpret_cast（C++ 标准规定mmap返回的是void*，且对齐要求严格） - Linux 下记得调用
msync(MS_SYNC)（仅写入时需要），Windows 下对应FlushViewOfFile；但只读场景完全不需要 - 示例关键片段：
class MappedFile { char* addr_ = nullptr; size_t len_ = 0; public: explicit MappedFile(const char* path) { int fd = open(path, O_RDONLY); struct stat sb; fstat(fd, &sb); addr_ = static_cast<char*>(mmap(nullptr, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0)); len_ = sb.st_size; close(fd); // fd 可立即关闭，mmap 不依赖它 } ~MappedFile() { if (addr_) munmap(addr_, len_); } char* data() const { return addr_; } };
多线程读取同一 mmap 区域是否线程安全？
只读场景下，多个线程同时访问同一块 mmap 内存是安全的——因为页表项共享，底层物理页只读，无竞态。但要注意：这不是“自动线程安全”的代名词，实际仍受数据结构约束。
立即学习“C++免费学习笔记（深入）”；
- 如果映射的是结构化数据（如数组、struct 数组），且各线程读不同偏移，完全没问题；但如果读同一结构体字段，而该结构体本身跨 cache line 或含 padding，仍需考虑 false sharing
- 绝对不要在多线程中混用
mmap读和fread读同一文件——POSIX 不保证两者缓冲一致性，可能读到脏数据 - Windows 上多个进程映射同一文件，默认不共享修改（
MAP_PRIVATE类似行为），如需进程间同步，必须用MAP_SHARED+FILE_MAP_ALL_ACCESS，并配Interlocked或临界区保护写操作
真正难处理的从来不是映射本身，而是你假设“内存连续”后，对数据布局做的那些隐式假设——比如结构体对齐、字节序、或指针在映射外失效。这些地方一错，core dump 都没提示。
