📚 课程目录第3章系统调用开销

3、系统调用开销：read/write 的上下文切换成本

做文件读写，很多人第一反应就是调 read()、write()。嗯，这没错。但你知道每次调用背后发生了什么吗？

说白了，一次 read() 或 write()，你的程序就得从用户态切到内核态。这个切换，我习惯叫它“过门”。门一开一关，几百纳秒就没了。单看一次没啥感觉，但如果你读写 1GB 文件，每次只读 1 字节……那光过门的时间就够你喝一壶的。

现代操作系统把 CPU 分了两个权限等级：用户态和内核态。你的应用程序跑在用户态，不能直接碰硬件。文件系统、磁盘驱动这些“硬核”东西，全在内核态。

所以当你调用 read() 时，流程是这样的：

一次 read()，两次上下文切换，一次数据拷贝。write() 同理。

核心结论：每次系统调用 ≈ 两次上下文切换 + 一次数据拷贝。调用次数越多，浪费在“过门”上的时间就越多。

我直接给你看一组我在 Linux 5.10 上实测的数据：

看到了吗？如果数据已经在 page cache 里，系统调用本身的成本占比就很高。一次 400 纳秒，一百万次就是 400 毫秒。你想想看，这还只是单线程。

我曾经踩过的坑：有一次做日志采集程序，逐行 read() 一个几百 MB 的日志文件。结果 CPU 全耗在系统调用上了，磁盘根本没跑满。后来改成批量读，CPU 占用直接降了 70%。

怎么减少？说白了就三个方向：

不是越大越好。我个人的经验是：

为什么会这样？因为内核和硬件层面也有缓冲区。你一次读 1MB，内核可能分多次从磁盘取。你一次读 4KB，刚好一个页，一次搞定。

我的建议：如果拿不准，先用 64KB 试试。大部分场景下这是个不错的折中点。然后拿 perf 工具测一下，看系统调用次数和 CPU 开销，再微调。

有时候你的数据分散在多个缓冲区里。比如一个网络包，头部在 buf1，负载在 buf2。传统做法是：

// 两次系统调用
write(fd, buf1, len1);
write(fd, buf2, len2);

用 writev 可以合并成一次：

struct iovec iov[2];
iov[0].iov_base = buf1;
iov[0].iov_len  = len1;
iov[1].iov_base = buf2;
iov[1].iov_len  = len2;

// 一次系统调用
writev(fd, iov, 2);

系统调用次数减半。数据量越大，效果越明显。

mmap 把文件直接映射到进程地址空间。之后你读写文件就像读写内存一样，不需要 read/write 系统调用。

// 映射文件
char *data = mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, fd, 0);

// 直接读，没有系统调用
char c = data[0];

// 用完记得解除映射
munmap(data, file_size);

好处很明显：省了系统调用，省了内核到用户的数据拷贝。但要注意：

我曾经翻过车：在一个数据库项目里，我用 mmap 做日志写入。结果程序崩溃时，最后几毫秒的数据没刷到磁盘。因为 mmap 的写入是延迟刷盘的，不像 write() 那样可以控制 fsync 时机。后来我改成了 write + 定时 fsync，才解决问题。

下面这张图展示了 read() 一次 4KB 数据的完整路径：

假设你要读取一个 64MB 的文件。看看不同策略的效果：

策略	缓冲区大小	系统调用次数	上下文切换开销
逐字节读	1 字节	67,108,864	~20 秒
小缓冲区	64 字节	1,048,576	~314 毫秒
合理缓冲区	4 KB	16,384	~5 毫秒
大缓冲区	4 MB	16	~0.005 毫秒

从 20 秒降到 5 微秒，差了 4000 倍。你想想看，这还只是上下文切换的开销，还没算磁盘 I/O 的时间。

我的习惯：写文件读写代码时，我第一件事就是检查循环里有没有 read()/write()。如果有，立刻改成批量操作。这是性价比最高的优化，没有之一。