最直接的大文件分块读取方式是用 std::ifstream::read() 配合二进制模式与 gcount() 检查实际字节数,块大小建议 4kb–64kb,避免 operator>>/getline;mmap() 仅适合只读随机访问场景;windows 超 4gb 文件推荐 createfile+readfile;处理逻辑需预留内存、避免频繁分配。

用 std::ifstream 配合 read() 做固定大小分块读取最直接
大文件不一次性加载进内存,是避免 OOM 和提升响应的关键。C++ 标准库里最可控的方式就是用 std::ifstream 的 read() 成员函数手动控制每次读多少字节。
常见错误是用 operator>> 或 getline() 处理大二进制/无结构文本文件——它们内部有缓冲和解析开销,还可能因换行符或空格提前截断,完全不适合“分块”这个目标。
- 块大小建议设为 4KB~64KB(如
4096、65536),太小导致系统调用频繁,太大可能挤占其他内存 - 务必检查
gcount()返回值:它才是本次实际读到的字节数,read()本身不抛异常也不自动补零 - 打开文件时加
std::ios::binary,否则 Windows 下遇到\x1A会误判 EOF
std::ifstream file("huge.bin", std::ios::binary);
file.seekg(0, std::ios::end);
size_t total = file.tellg();
file.seekg(0);
const size_t chunk_size = 65536;
std::vector<char> buf(chunk_size);
while (file.read(buf.data(), chunk_size)) {
process_chunk(buf.data(), chunk_size);
}
// 处理最后一块(不足 chunk_size)
if (file.gcount() > 0) {
process_chunk(buf.data(), static_cast<size_t>(file.gcount()));
}
用 mmap() 替代 read() 能绕过内核拷贝,但只适合只读+随机访问场景
Linux/macOS 上 mmap() 把文件直接映射成内存地址,省去 read() 的用户态/内核态数据拷贝,理论吞吐更高。但它不是万能加速器,用错反而更慢。
典型误用:对一个只顺序读一遍的大日志文件做 mmap(),结果触发大量缺页中断,比 read() 还卡;或者在小内存机器上映射几十 GB 文件,直接被 OOM killer 干掉。
立即学习“C++免费学习笔记(深入)”;
-
mmap()后仍需按需访问内存区域,不访问就不会加载物理页——别以为“映射了就等于全读进来了” - 必须用
MAP_PRIVATE+PROT_READ,写入需求要另说,且 Windows 对应 API(CreateFileMapping)行为差异大 - 记得
munmap(),尤其在长生命周期程序中,否则内存泄漏不易察觉
Windows 下 CreateFile + ReadFile 比 fopen 更稳,尤其超 4GB 文件
Visual C++ 的 std::ifstream 在处理大于 4GB 的文件时,某些旧版本 runtime 会因 32 位偏移量截断 tellg() 或 seekg(),导致分块错位。原生 Win32 API 没这问题。
关键点不在“多快”,而在“不丢字节”。比如你按每 1MB 分块,第 1024 块本该从位置 1048576000 开始,但 tellg() 返回 0,后面全乱。
- 用
CreateFile时指定FILE_ATTRIBUTE_NORMAL和FILE_FLAG_SEQUENTIAL_SCAN,帮系统预判访问模式 -
ReadFile的lpNumberOfBytesRead参数必须检查,不能只看返回值 TRUE/FALSE - 路径要用宽字符(
L"..."),否则中文路径在ANSI模式下直接失败
分块后处理逻辑卡住?先确认是不是 std::vector::resize() 或字符串拼接拖慢了
很多人把 IO 优化做完,发现整体速度没变——问题常出在“处理块”的环节。比如用 std::string += 累积解析结果,或反复 resize() 一个 vector,触发多次内存重分配。
这不是 IO 问题,是内存模式问题。尤其当块大小固定、处理逻辑确定时,提前预留空间几乎零成本。
- 如果每块解析出 N 条记录,且 N 可估算,就用
results.reserve(expected_total)开局 - 避免在循环里构造临时
std::string再转std::vector<uint8_t></uint8_t>,直接用std::string_view观察原始 buffer 片段 - 调试时加个
clock()或std::chrono打点,确认耗时真在 IO 层,还是卡在process_chunk()里










