mmap 比 fread/fwrite 更快因其绕过内核缓冲区多次拷贝，实现文件到虚拟内存的直接映射，但存在缺页中断等隐性开销；适用于大文件随机访问、多进程共享只读数据或固定区域频繁修改。
为什么 mmap 比 fread/fwrite 更快？
因为 mmap 绕过了内核缓冲区的多次拷贝：普通读写要经历「磁盘 → 内核页缓存 → 用户缓冲区」，而 mmap 让文件内容直接映射进进程虚拟地址空间，访问就像读写内存一样。但注意，这不等于“无代价”——缺页中断、页表管理、TLB 压力都是隐性开销。
适用场景：mmap 真正高效的地方是随机访问大文件（比如数据库索引、日志查找）、需要多进程共享同一份只读数据、或频繁修改固定区域（如位图、内存池头）。顺序流式读写反而可能因预读策略失效而变慢。
- 64 位系统下推荐用
MAP_POPULATE预加载物理页，避免首次访问时卡顿 - 只读场景加
PROT_READ和MAP_PRIVATE，避免写时复制（COW）开销 - 写入后必须调用
msync(MS_SYNC)才能保证落盘，munmap不触发同步
Windows 上怎么等价实现 mmap？
Windows 没有 mmap，但 CreateFileMapping + MapViewOfFile 功能完全对应。关键差异在于句柄管理和保护标志：
-
CreateFile必须带GENERIC_READ | GENERIC_WRITE，即使只读也要申请写权限（否则CreateFileMapping失败） -
MapViewOfFile的dwDesiredAccess才真正控制访问权限：FILE_MAP_READ/FILE_MAP_WRITE - 映射大小不能超过文件实际长度；若需扩展，先用
SetFilePointerEx+SetEndOfFile扩容，再映射
错误示例：ERROR_MAPPED_FILE 常因文件句柄未设 FILE_FLAG_RANDOM_ACCESS 导致，尤其在 SSD 上影响预读性能。
立即学习“C++免费学习笔记（深入）”；
如何安全处理大于 2GB 的文件映射？
32 位程序天然受限于 4GB 虚拟地址空间，即使文件只有 2.5GB，也可能因 DLL 占位导致无法分配连续映射区。64 位下虽无此限，但仍有陷阱：
- Linux：
mmap的length参数是size_t，但某些老内核对超大映射会返回ENOMEM，建议分块映射（如每次 512MB） - Windows：
MapViewOfFile的dwNumberOfBytesToMap是DWORD（最大 4GB），超限时必须用MapViewOfFileEx并手动指定基址 - 跨平台代码别用
sizeof(int)判断文件大小，统一用off_t（Linux）或LARGE_INTEGER（Windows）
一个易忽略点：stat 或 GetFileSizeEx 返回的大小可能被其他进程截断，映射前最好加 flock 或 LockFileEx。
munmap 后指针还能用吗？
不能。一旦调用 munmap（或 Windows 的 UnmapViewOfFile），对应虚拟地址区间立即失效。后续访问会触发 SEGV_MAPERR（Linux）或 ACCESS_VIOLATION（Windows），不是“数据丢失”，而是段错误。
- 多线程中务必确保无任何线程仍在访问该映射区，
munmap本身不是原子操作 - RAII 封装时，析构函数里
munmap前要加std::atomic_thread_fence防止编译器重排 - 调试时可用
/proc/self/maps（Linux）或 VMMap 工具确认映射是否残留
最常被忽视的是信号处理：若在 SIGSEGV 信号 handler 中尝试访问已 munmap 的地址，会导致递归崩溃——handler 本身可能就运行在该映射区内。
