C++读写大型二进制文件性能优化技巧【实战分享】

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(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），别边读边 push_back。每次扩容都会触发 memcpy，对千万级结构体就是灾难。

更优做法：

• 先 stat 获取文件大小，除以结构体大小，得到预估元素数量
• 用 reserve() 预分配容量，再用 resize() 或迭代器填充
• 若结构体含指针或非 POD 类型，确保二进制布局兼容（加 static_assert(std::is_trivially_copyable_v)）
• 考虑用 std::span 指向 mmap 区域，避免额外拷贝

struct Record { uint64_t id; float val; }; size_t file_size = /* ... */; size_t count = file_size / sizeof(Record); std::vector 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 不是银弹，它们把控制权交还给你，也把责任一并移交——对齐、同步、生命周期管理，漏掉任一环都可能引发静默错误或性能崩塌。