mmap比fread更适合大文件检索，因其将文件直接映射进进程虚拟地址空间，避免反复用户态/内核态拷贝和缓冲区分配，实现微秒级随机访问延迟；但需注意它按需加载页、首次访问可能卡顿，且仅适用于只读、随机访问、文件>100mb等场景。
为什么 mmap 比 fread 更适合大文件检索
因为 mmap 把文件直接映射进进程虚拟地址空间，避免了反复的用户态/内核态拷贝和缓冲区分配。对 GB 级文件做多次随机查找时，mmap 的延迟稳定在微秒级，而 fread + fseek 在非顺序访问下容易触发大量磁盘寻道和 page fault 尖峰。
但要注意：mmap 不等于“自动加载全部内容”——它只是建立映射，实际页（page）只在首次访问时按需加载（lazy mapping）。这意味着启动快、内存占用初始低，但也意味着第一次访问某偏移可能卡顿。
- 适用于：只读、随机访问、文件大小 > 100MB、检索逻辑需要频繁跳转（如索引查 record、二分找 offset）
- 不适用：小文件（开销反超）、写入频繁（需处理 msync 和同步策略）、内存极度受限且访问模式高度稀疏（可能引发 OOM）
- 关键限制：
mmap映射区域不能超过进程可用虚拟地址空间（64 位系统通常不是瓶颈，32 位下慎用 >2GB 文件）
如何用 mmap 安全打开并映射只读大文件
核心是调用 mmap 前必须确保文件描述符有效、长度准确、权限匹配。常见错误是忽略 stat 获取真实文件大小，或误用 PROT_WRITE 却以 MAP_PRIVATE 映射只读文件。
#include <sys>
#include <sys>
#include <fcntl.h>
#include <unistd.h><p>int fd = open("data.bin", O_RDONLY);
if (fd == -1) { /<em> handle error </em>/ }</p>
<p>struct stat sb;
if (fstat(fd, &sb) == -1) { /<em> handle error </em>/ }
off_t file_size = sb.st_size;</p>
<p>// 注意：len 必须是 page size 对齐（内核会向下取整到 page boundary）
// 所以我们手动 round up
size_t len = (size_t)((file_size + getpagesize() - 1) & ~(getpagesize() - 1));
void<em> addr = mmap(nullptr, len, PROT_READ, MAP_PRIVATE, fd, 0);
if (addr == MAP_FAILED) { /</em> handle error — e.g., ENOMEM or EACCES */ }</p>
<p>// 记得 close fd — mmap 后 fd 可关闭，不影响映射
close(fd);
</p></unistd.h></fcntl.h></sys></sys>
-
MAP_PRIVATE足够用于只读场景，比MAP_SHARED开销略低，且不会意外污染文件 - 务必用
fstat获取st_size，不要依赖lseek(fd, 0, SEEK_END)—— 某些文件系统（如 NFS）不支持该操作 - 映射长度
len必须 ≥ 实际数据长度，否则末尾访问会触发SEGV_MAPERR
如何在 mmap 区域中安全做二分查找或偏移计算
映射成功后，addr 就是起始指针，你可以像访问普通数组一样用 static_cast<uint8_t>(addr) + offset</uint8_t> 计算位置。但所有偏移都必须落在 [0, file_size) 范围内 —— 超出会 segfault，且无法靠异常捕获（SIGSEGV 不是 C++ 异常）。
典型陷阱：二分查找中计算中点时整数溢出，或未校验 record header 是否越界。
// 假设每条 record 固定 128 字节，header 为 uint32_t length + uint32_t key const uint8_t* base = static_cast<uint8_t>(addr); size_t record_size = 128; size_t n_records = file_size / record_size; <p>// 安全的 mid 计算（避免 low+high 溢出） size_t low = 0, high = n_records; while (low p = base + mid record_size; // ⚠️ 必须先检查 p 是否在 [base, base + file_size) 内 if (p + sizeof(uint32_t) > base + file_size) break; uint32_t key = <em>reinterpret_cast<const uint32_t>>(p + 4); if (key </const></em></p> <ul> <li>所有指针运算前，先做边界检查：比如 <code>p + N ，而不是依赖“应该不会越界”</code> </li> <li>如果 record 长度可变，必须解析 header 中的 length 字段，并验证 <code>p + length </code> </li> <li>不要在 mmap 区域里调用 <code>std::string</code> 构造函数（它可能内部调用 malloc 或抛异常），优先用 <code>std::string_view</code> 或 raw pointer + len</li> </ul> <h3>何时以及如何 munmap 和错误处理</h3> <p><code>munmap</code> 不是可选操作 —— 忘记调用会导致资源泄漏（虚拟内存碎片、/proc/<pid>/maps 泄露）。但更隐蔽的问题是：SIGSEGV 无法用 try/catch 捕获，必须用 signal handler 或提前防御性校验。</pid></p> <ul> <li>映射失败时，<code>mmap</code> 返回 <code>MAP_FAILED</code>（即 <code>(void*)-1</code>），不是 <code>nullptr</code> —— 别用 <code>if (!addr)</code> 判断</li> <li>访问非法地址会触发 <code>SIGSEGV</code>，默认终止进程。若需容错（如扫描未知格式文件），必须用 <code>sigaction</code> 注册 <code>SIGSEGV</code> handler 并 longjmp，但这破坏可移植性和调试性，**强烈建议优先用边界检查代替**</li> <li> <code>munmap(addr, len)</code> 成功后，<code>addr</code> 变成野指针，后续任何解引用都是未定义行为；别把它存成全局裸指针，封装成 RAII 类更安全</li> </ul> <p>真正麻烦的不是映射本身，而是把“文件偏移 → 内存地址”的抽象彻底想清楚 —— 很多人卡在看似正确的指针运算上，实际越界了却没立刻崩溃，直到读到脏内存才出错。</p></uint8_t>
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
