Tokio I/O 性能调优：从 bufreader 到 vectored I/O 的进化路线 Tokio I/O 性能调优从 bufreader 到 vectored I/O 的进化路线一、从裸read到BufReader为什么缓冲这么重要我最初的代码是这样直接读文件的use tokio::io::{AsyncReadExt, AsyncSeekExt}; use tokio::fs::File; async fn count_lines_slow(path: str) - Resultusize, Boxdyn std::error::Error { let mut file File::open(path).await?; let mut count 0; // 每次只读一个字节 —— 每个字节触发一次 read() 系统调用 let mut buf [0u8; 1]; loop { match file.read(mut buf).await? { 0 break, // EOF _ { if buf[0] b\n { count 1; } } } } Ok(count) }这段代码性能极差——每读一个字节触发一次read()系统调用从用户态切换到内核态读一个 100KB 的文件就要做 10 万次系统调用。这还只是读如果要边读边解析就更慢了。改进方案BufReader在内存里维护一个缓冲区默认 8KB每次读取时先从缓冲区读缓冲区空了才做一次系统调用补货use tokio::io::{AsyncBufReadExt, BufReader}; async fn count_lines_bufreader(path: str) - Resultusize, Boxdyn std::error::Error { let file File::open(path).await?; // BufReader 默认 8KB 缓冲区一次 read() 系统调用读入 8KB 数据 let reader BufReader::new(file); let mut lines reader.lines(); // 按行读取内部使用缓冲区 let mut count 0; while let Some(_line) lines.next_line().await? { count 1; } Ok(count) }对于大文件可以把缓冲区调大一点// 32KB 缓冲区适合顺序读取大文件 let reader BufReader::with_capacity(32 * 1024, file);核心原理系统调用syscall的开销远大于内存操作。BufReader用空间换时间把数千次 syscall 压缩到几十次。二、搭配BufWriter读得快写也要快读的问题解决了写呢很多场景下我们是边读边写的比如文件格式转换、日志处理管道use tokio::io::{AsyncWriteExt, BufWriter}; async fn copy_file_with_buf(src: str, dst: str) - Result(), Boxdyn std::error::Error { let src_file File::open(src).await?; let dst_file File::create(dst).await?; let mut reader BufReader::with_capacity(32 * 1024, src_file); let mut writer BufWriter::with_capacity(32 * 1024, dst_file); // 读完一个缓冲区就写一个缓冲区两边都是批量操作 let mut buf vec![0u8; 32 * 1024]; loop { let n reader.read(mut buf).await?; if n 0 { break; } writer.write_all(buf[..n]).await?; } // BufWriter 析构前一定要 flush否则缓冲区里残余数据会丢失 writer.flush().await?; Ok(()) }读写缓冲配合使用的性能提升三、vectored I/O一次系统调用读写多块内存BufReader已经不错了但还有优化空间。来看一个场景我需要把一段 JSON 数据写入文件前面是固定的 header中间是动态的 body最后是固定的 footer。普通写法// 三次 write 系统调用 writer.write_all(HEADER.as_bytes()).await?; // syscall 1 writer.write_all(body_bytes).await?; // syscall 2 writer.write_all(FOOTER.as_bytes()).await?; // syscall 3三次write就是三次系统调用。vectored I/O也叫 scatter/gather I/O可以一次系统调用完成多段不连续内存的读写use tokio::io::AsyncWriteExt; async fn write_json_with_vectored( writer: mut (impl AsyncWriteExt Unpin), body: [u8], ) - Result(), Boxdyn std::error::Error { // 定义三段不连续的内存区域IoSlice let header tokio::io::IoSlice::new(b{\data\:); let footer tokio::io::IoSlice::new(b}); let body_slice tokio::io::IoSlice::new(body); // 一次 write_vectored 系统调用写入三块内存 writer.write_vectored([header, body_slice, footer]).await?; Ok(()) }对应的读取端也可以用read_vectoreduse tokio::io::AsyncReadExt; async fn read_with_vectored(reader: mut (impl AsyncReadExt Unpin)) - Result(Vecu8, Vecu8), Boxdyn std::error::Error { // 两个独立的缓冲区一次 readv 系统调用同时填充 let mut header_buf vec![0u8; 64]; // 前 64 字节 let mut body_buf vec![0u8; 1024]; // 接下来的 1024 字节 // 这里需要把 mut [u8] 转为 IoSliceMut let mut slices vec![ tokio::io::IoSliceMut::new(mut header_buf), tokio::io::IoSliceMut::new(mut body_buf), ]; reader.read_vectored(mut slices).await?; Ok((header_buf, body_buf)) }vectored I/O 的优势在于把 N 次系统调用的开销压缩为 1 次。在需要读写多个不连续内存区域的场景比如网络协议的 header body 分离读取、文件格式的分段写入这个优化非常有意义。踩坑提醒write_vectored不保证一次性写完所有数据。我在生产环境遇到过——写一个 3 段 buffer总共 12KBwrite_vectored返回只写了 6KB剩下的数据丢了。原因是有两个 IoSlice 中的 buffer 没有对齐到内存页边界内核只写了一部分就返回了。排查了一下午才发现这个坑。解决方案是封装一个write_vectored_all函数循环写入直到全部写完async fn write_vectored_all( writer: mut (impl tokio::io::AsyncWriteExt Unpin), mut bufs: [std::io::IoSlice_], ) - std::io::Result() { while !bufs.is_empty() { let n writer.write_vectored(bufs).await?; if n 0 { return Err(std::io::Error::new(std::io::ErrorKind::WriteZero, write zero)); } // 跳过已写入的字节继续写剩余部分 bufs std::io::IoSlice::advance_slices(bufs, n); } Ok(()) }这个坑告诉我一个道理系统调用的返回值一定要检查不能想当然认为写了就等于全写完了。一线开发者往往会忽略这类边界情况。四、进化路线全景对比我把四种方案在同一个场景下做了基准测试场景是读取一个 100MB 的日志文件按行解析并统计错误日志数量use std::time::Instant; use tokio::io::{AsyncBufReadExt, AsyncReadExt, BufReader}; use tokio::fs::File; #[tokio::main] async fn main() - Result(), Boxdyn std::error::Error { let path test_100mb.log; // 方案 A逐字节读取最差 let start Instant::now(); let mut file File::open(path).await?; let mut buf [0u8; 1]; let mut count_a 0; loop { if file.read(mut buf).await? 0 { break; } if buf[0] b\n { count_a 1; } } println!(逐字节读取: {}ms, {} 行, start.elapsed().as_millis(), count_a); // 方案 BBufReader lines()较好 let start Instant::now(); let file File::open(path).await?; let reader BufReader::with_capacity(64 * 1024, file); let mut lines reader.lines(); let mut count_b 0; while let Some(_) lines.next_line().await? { count_b 1; } println!(BufReader(64K): {}ms, {} 行, start.elapsed().as_millis(), count_b); // 方案 C手动缓冲读取可控性更强 let start Instant::now(); let mut file File::open(path).await?; let mut buf vec![0u8; 256 * 1024]; // 256KB 大缓冲 let mut count_c 0; loop { let n file.read(mut buf).await?; if n 0 { break; } // 在内存中快速统计避免字节级系统调用 count_c buf[..n].iter().filter(|b| b b\n).count(); } println!(大缓冲读取(256K): {}ms, {} 行, start.elapsed().as_millis(), count_c); Ok(()) } // 典型结果 // 逐字节读取: 45230ms, 1520000 行 // BufReader(64K): 342ms, 1520000 行 // 大缓冲读取(256K): 178ms, 1520000 行从 45 秒到 178 毫秒差距是250 倍——这就是 I/O 优化的威力。不过大缓冲区也不是越大越好。我踩过一个坑为了追求极致的吞吐量把缓冲区设成了 1MB结果在处理大量小文件每个只有几 KB时每个文件都分配了 1MB 的栈上空间总内存暴涨反而被 OOM killer 杀了。后来定了规矩缓冲区大小不超过目标文件大小的 1/4且最大不超过 256KB。对于不确定文件大小的场景默认 8KB 或者 32KB 是最稳妥的选择。另一个边界问题是BufReader::lines()在处理超大单行时比如一行 JSON 有几百 MB会导致缓冲区被撑爆。这时候需要降级为手动分块读取自己实现换行符检测。遇到这种场景别强行用lines()。五、总结I/O 优化的进化路线很清晰第一步上BufReader/BufWriter——这是性价比最高的优化改几行代码就能消灭 99% 的无效系统调用。第二步调优缓冲区大小——默认 8KB 适合大多数场景大文件顺序读写可以调到 32KB-256KB。第三步vectored I/O——当你的数据天然是分段存储的header/body/footer、网络协议帧用readv/writev减少系统调用次数。作为程序员我之前确实不太懂操作系统的系统调用开销但通过这次调优我真正理解了为什么内存操作比磁盘操作快背后的原因。这些基础概念虽然枯燥但在性能优化时它就是最大的杠杆点。