根本原因是每次read()都触发用户态到内核态的上下文切换，耗时100–300纳秒；百万次单字节读耗时2.5秒，而单次读百万字节仅需0.003秒，性能差833倍。
频繁调用 read() 是文件流性能最常见的瓶颈之一，根本原因不在磁盘或内存，而在于每次调用都触发一次用户态到内核态的上下文切换——这个过程本身就要耗费 100–300 纳秒。当程序每读 1 字节就调用一次 read()，百万次调用就能吃掉数秒 CPU 时间，性能直接跌掉 99%。
系统调用开销到底有多大
一次 read() 不只是“把数据拿过来”那么简单：
- 保存当前用户态寄存器现场
- 陷入内核、验证文件描述符和参数合法性
- 检查页缓存是否命中；未命中则触发磁盘 I/O 等待
- 把数据从内核缓冲区复制到用户提供的 buffer
- 恢复用户态并返回结果
其中前四步在每次调用中都重复执行。实测显示：循环调用 read(fd, &b, 1) 百万次耗时 2.5 秒；改用单次 read(fd, buf, 1000000) 仅需 0.003 秒——快了 833 倍。
核心优化方向：减少调用次数
关键不是让单次 read() 更快，而是让它少发生几次。高频小读是典型反模式。
-
用缓冲区合并多次读：如 C 的
setvbuf()、Go 的bufio.Reader（默认 4KB 缓冲）、Java 的BufferedInputStream。它们在用户空间预读一批数据，后续read()直接从内存取，不进内核 - 按业务特征设缓冲大小：日志行平均 200 字节，缓冲可设 2KB；纯顺序大文件读取，64KB 以上提升极小，还可能加重 GC 或延迟错误暴露
- 避免“读一行就处理一行”式写法：尤其在解析 CSV 或 JSON 流时，先批量读入再解析，比边读边 parse 快一个数量级
进阶替代方案：绕过传统 read
当缓冲区优化仍不够，或场景特殊（如大文件复制、零拷贝传输），可考虑更底层的机制：
-
sendfile()：内核直接在两个文件描述符间搬运数据，不经过用户空间，省去两次内存拷贝 + 两次系统调用（常用于 HTTP 静态文件服务） -
mmap()：将文件映射为内存地址，后续访问像读数组一样，首次缺页才触发 I/O，适合随机读或反复访问同一区域 -
io_uring：Linux 5.1+ 提供的异步 I/O 接口，支持一次系统调用提交多个读请求、批量完成，大幅降低上下文切换频次，嵌入式高采样率场景已实测降低延迟 70% 以上
哪些情况不该加缓冲
缓冲不是万能解药，滥用反而拖慢：
- 实时性要求高的场景：比如串口读传感器数据，加 4KB 缓冲可能导致几十毫秒不可控延迟
-
底层已有缓冲的协议栈：例如
http.Response.Body已被标准库用bufio.Reader包装，再套一层会干扰状态跟踪 - 随机读写或 mmap 场景：预读逻辑会污染 page cache，还可能读入完全不用的数据
-
单次写入极小数据：比如只写 16 字节 token，直接
write()比先拷进 buffer 再 flush 更快
