mmap替代fread/fwrite可提升大文件随机读写性能，关键在于按需缺页加载、避免拷贝与上下文切换，但需注意msync同步、禁止realloc、对齐要求及多线程安全。
用 mmap 替代 fread / fwrite 直接内存映射
对几百 MB 甚至 GB 级二进制文件做随机读写时，fread 和 fwrite 的系统调用开销、缓冲区拷贝、用户态/内核态切换会明显拖慢速度。直接用 mmap（Linux/macOS）或 CreateFileMapping + MapViewOfFile（Windows）把文件“变成内存”，后续访问就像操作数组一样快。
关键点：
-
mmap不会立即加载全部内容到物理内存，而是按需缺页加载，内存占用可控 - 写入后需调用
msync（或MAP_SYNC标志，取决于内核版本）确保落盘，否则可能丢失数据 - 避免在
mmap区域内做std::vector::push_back或其他可能触发 realloc 的操作——指针会失效 - 64 位程序下可安全映射超大文件；32 位下注意地址空间碎片，建议分段映射
int fd = open("data.bin", O_RDWR);
size_t file_size = lseek(fd, 0, SEEK_END);
void* addr = mmap(nullptr, file_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// 直接 reinterpret_cast<uint8_t*>(addr)[offset] = value;
msync(addr, file_size, MS_SYNC); // 确保写入磁盘
munmap(addr, file_size);
close(fd);禁用 C 运行时缓冲，用 O_DIRECT 绕过页缓存（Linux）
当你要完全控制 I/O 路径（比如实现自定义缓存、避免与内核页缓存竞争），且文件大小远超可用内存时，O_DIRECT 可跳过内核页缓存，减少一次内存拷贝。但代价是：所有 read/write 必须满足对齐要求。
常见踩坑点：
立即学习“C++免费学习笔记（深入）”；
- 缓冲区地址必须按
getpagesize()对齐（常用posix_memalign分配） - I/O 大小必须是页大小的整数倍（如 4096 字节）
- 文件偏移量也必须页对齐
-
O_DIRECT在某些 SSD 或文件系统（如 ext4 with journaling）上可能反而更慢，务必实测
int fd = open("data.bin", O_RDWR | O_DIRECT);
void* buf;
posix_memalign(&buf, 4096, 4096);
ssize_t r = pread(fd, buf, 4096, 0); // offset=0 是页对齐的批量处理 + 预分配 std::vector 避免频繁重分配
如果读取后要在内存中做结构化解析（比如把二进制流转成 std::vector<mystruct></mystruct>），别边读边 push_back。每次扩容都会触发 memcpy，对千万级结构体就是灾难。
更优做法：
- 先
stat获取文件大小，除以结构体大小，得到预估元素数量 - 用
reserve()预分配容量，再用resize()或迭代器填充 - 若结构体含指针或非 POD 类型，确保二进制布局兼容（加
static_assert(std::is_trivially_copyable_v<mystruct>)</mystruct>） - 考虑用
std::span<uint8_t></uint8_t>指向 mmap 区域，避免额外拷贝
struct Record { uint64_t id; float val; };
size_t file_size = /* ... */;
size_t count = file_size / sizeof(Record);
std::vector<Record> records;
records.reserve(count);
records.resize(count); // 一次性分配+默认构造
// 然后用 fread 或 memcpy 填充 raw data多线程读写要小心：文件偏移 vs 内存映射 vs 锁粒度
多个线程并发读写同一文件，最容易出错的是共享文件偏移（lseek + read 组合不是原子的）。即使用了 pread/pwrite，也要注意：
-
pread/pwrite是线程安全的，但不解决数据竞争——多个线程往同一 offset 写，结果未定义 - 用
mmap后，各线程直接操作内存地址，此时需用std::atomic或互斥锁保护临界区域，而非文件锁 - 避免用
flock或fcntl(F_SETLK)控制大文件——锁粒度太粗，严重串行化 - 真正高吞吐场景下，推荐按块划分：线程 A 处理 [0, 1GB)，线程 B 处理 [1GB, 2GB)，完全无共享状态
文件 I/O 性能瓶颈往往不在“怎么读”，而在“谁在读、读多少、是否重复拷贝”。mmap 和 O_DIRECT 不是银弹，它们把控制权交还给你，也把责任一并移交——对齐、同步、生命周期管理，漏掉任一环都可能引发静默错误或性能崩塌。
