最近在啃 Linux 基础 IO 这块越看越觉得这东西才是整个系统编程的骨架。不管是写网络服务、搞嵌入式还是日常排查线上问题最后都会绕回文件描述符、缓冲区和系统调用这三板斧。这篇笔记是我把 Linux IO 从底层到应用层重新捋了一遍之后的总结重点围绕文件描述符、open/read/write/close 这类系统调用、标准 IO 的缓冲机制、重定向与 dup/dup2以及 IO 性能排查这几个方向展开同时把面试里高频出现的细节坑也一并整理了。适合正在学 Linux 系统编程的同学、准备面试的后端开发以及被 IO 性能问题折磨过的运维和嵌入式工程师文中的代码和命令都可以直接拿过去跑一遍验证。1. 一切皆文件理解 Linux IO 的底层视角1.1 文件描述符是什么Linux 设计哲学里最核心的一句话就是一切皆文件。普通文件是文件目录是文件键盘鼠标是文件网卡 socket 是文件甚至进程间的管道、共享内存对象在 Linux 里都被抽象成了文件。正因为所有东西都能用文件的方式访问所以 IO 操作才能统一成一套接口打开、读写、关闭。那内核怎么区分一个进程打开了几十个不同的文件呢答案就是文件描述符file descriptor简称 fd。fd 本质上是一个非负整数它作为下标指向进程的文件描述符表这张表里每一项都是一个指向内核中打开文件表记录的指针。你平时调用的open()返回整数 fdread()、write()使用这个整数来定位到底操作哪个文件内核拿到这个整数后通过进程的文件描述符表找到对应的文件对象再完成实际 IO。关键点文件描述符是进程级的资源不是全局的。同一个文件被两个进程打开会得到两个不同的 fd也对应两个独立的文件描述符表项。这就是为什么多进程写同一个文件时各自的文件偏移量互不干扰。1.2 0、1、2 三个默认描述符每个进程启动时内核会默认打开三个文件描述符这是 POSIX 标准约定的也是 shell 能实现重定向的基础描述符名称常见指向0stdin键盘输入1stdout终端输出2stderr终端错误输出所以你在 C 代码里直接写write(1, hello, 5)就能往终端打一个 hello。很多脚本里出现的2/dev/null、1log.txt本质就是在 shell 层面对描述符 1 或 2 做重定向操作这个后面我单独讲。这里有个值得记住的细节printf 往 stdout 写perror 往 stderr 写。stderr 默认是无缓冲的stdout 如果是终端则行缓冲所以要保证错误信息能第一时间刷出来设计上是有意的。1.3 fd 分配的最小未用原则fd 不是随机分配的内核采用最小未使用值的分配策略。比如进程默认占用了 0、1、2你第一次open()拿到的 fd 一定是 3第二次是 4。如果中途 close(4) 了下一次 open 的时候又会优先分配 4而不是 5。这个特性很多人在学 dup2 的时候会忽略但它是理解重定向的钥匙。shell 在执行cmd file时就是先 open 一个文件得到 fd假设是 1但 1 已经被占用了怎么办shell 会先 close(1)再去 open 那个文件因为最小未使用原则新的 fd 刚好变回 1。后续 printf 往标准输出写实际就落到了文件里。2. 系统调用四件套open/read/write/close 的运行细节2.1 open 的 flags 参数怎么选open 函数原型是int open(const char *pathname, int flags, mode_t mode)。flags 是位图组合最常用的三组基础模式是O_RDONLY只读O_WRONLY只写O_RDWR读写注意这三者必须且只能选一个不能同时传O_RDONLY | O_WRONLY。配合使用的其他常用 flags 有O_CREAT文件不存在就创建此时需要第三个参数 mode 指定权限比如 0644O_TRUNC打开时把文件长度清空为 0覆盖写日志时慎用O_APPEND写入前自动把文件偏移量移到文件末尾多进程同时写日志文件时这个很关键O_EXCL和O_CREAT配合使用文件已存在则 open 失败这是创建锁文件的常用手段O_NONBLOCK非阻塞模式打开管道、设备时常用O_APPEND有一个隐蔽优势它保证每次 write 前内核都会把偏移量置为文件末尾而且这个移到末尾写入是原子操作。换句话说多进程并发往同一个文件里追加日志不会出现互相覆盖的问题。相比之下如果你自己先lseek到末尾再 write中间可能被其他进程打断。2.2 read 和 write 返回值的含义read 和 write 的返回值不是简单的成功/失败而是返回实际传输的字节数理解这一点能避开大量并发编程的坑。read返回大于 0 表示实际读到的字节数返回 0 表示读到 EOF也就是文件末尾返回 -1 表示出错具体原因看 errnowrite返回大于 0 表示实际写入的字节数返回 -1 表示出错特别要强调的是write 返回 N 不代表你传进去的 N 字节一次性全部写完了而是内核接受了 N 字节。在管道、socket、非阻塞 IO 的场景下write 可能只写了一半你必须做好循环写入。同理read 也可能只读了一部分不能假设一次 read 就把 buffer 装满。这也是为什么生产级代码里到处都是下面这样的封装ssize_t read_full(int fd, void *buf, size_t count) { ssize_t total 0; while (total count) { ssize_t n read(fd, (char *)buf total, count - total); if (n 0) break; // EOF if (n 0) { if (errno EINTR) continue; // 被信号打断重来 return -1; } total n; } return total; }这里面EINTR的处理是新手最容易漏的。当进程收到信号系统调用可能被中断read 返回 -1 并且 errno 为 EINTR这不是真正的错误应该重新调用。很多年久失修的代码不处理这个分支结果就是程序在信号频繁时莫名读写失败。2.3 lseek 与文件偏移量每个打开的文件对象都有独立的文件偏移量file offset读写共用同一个偏移量。lseek 可以把偏移量移到指定位置实现随机读写。off_t lseek(int fd, off_t offset, int whence);whence 有三种SEEK_SET偏移量设为 offset即从头开始算SEEK_CUR偏移量 当前位置 offsetSEEK_END偏移量 文件末尾 offset最实用的一个场景是读取文件头部信息比如读完头 100 字节后lseek(fd, 0, SEEK_SET)回到开头再读。还有一类冷知识是 lseek 可以超过文件结尾此时中间会产生一个空洞读洞里的数据全是\0文件系统并不为空洞分配磁盘块。这解释了为什么某些幽灵文件用ls -lh看着很大du看却占不了多少空间。2.4 一次完整的系统调用读写示例下面这段代码演示了标准 IO 和系统调用混用时的行为差异建议编译运行看看#include stdio.h #include unistd.h #include fcntl.h #include stdlib.h int main() { // 先用标准 IO 向 stdout 写一段 printf(standard io no newline); // 直接用系统调用写 write(1, syscall write\n, 14); // 如果不加下面这句你看到的输出顺序可能是 // syscall write // standard io no newline // 因为 printf 的数据还待在缓冲区进程结束时才 flush fflush(stdout); return 0; }运行后你会发现不调用 fflush 时write 的内容先打印printf 的内容最后才出来。原因就是标准 IO 库有自己的用户态缓冲区printf 只是把数据存进了缓冲区并没有立刻交给内核直到进程退出或缓冲区满才统一 flush。这个现象背后就是标准 IO 和系统调用之间的缓冲差异也是下一节的重点。3. 标准 IO 库与系统调用缓冲机制决定了你的程序性能3.1 三种缓冲模式C 标准库提供的 fopen/fread/fwrite/printf 等函数是在系统调用之上做了一层封装核心就是缓冲区管理。根据目标文件的类型标准 IO 库自动选择三种缓冲策略之一全缓冲fully buffered数据写满缓冲区默认 4096 字节或根据文件系统最优块大小才真正调用系统调用写入内核。普通文件的读写默认是全缓冲行缓冲line buffered遇到换行符\n就 flush。终端设备的输出默认是行缓冲所以 printf(hello\n) 能立刻显示无缓冲unbuffered每次写都立即转向系统调用最典型的就是 stderr保证错误信息不因程序崩溃而丢失用setvbuf可以手动修改缓冲模式这在做嵌入式日志输出、或者需要实时落盘时很常用。注意这里说的全缓冲/行缓冲是用户态 libc 的缓存和内核中的文件页缓存是两层东西。很多教程把这两个混在一起讲导致读者对write 到底什么时候落盘一知半解。下面我把分工说清楚标准 IO 缓冲解决的是用户态到内核态的系统调用次数内核页缓存解决的是内存到磁盘的 IO 次数。3.2 printf fork 为什么会出现双份输出这个问题几乎是面试必问也是实际开发里踩过的大坑。#include stdio.h #include unistd.h #include sys/wait.h int main() { printf(hello ); fork(); wait(NULL); return 0; }如果 stdout 是终端你只看到一个 hello。但如果把输出重定向到文件./a.out out.txt再打开文件一看里面会出现两个 hello。原因printf 往用户态缓冲区写入了 hello 但因为没有换行符数据仍然呆在缓冲区里。fork 时子进程复制了父进程的整个地址空间包括这份缓冲区内容。于是父进程退出时 flush 一份子进程退出时 flush 一份文件里就有两遍了。终端下行缓冲遇到没有换行的 printf 不会立刻输出但程序退出时会 flush。重定向到文件后是全缓冲同样的逻辑。这个案例告诉我们写日志模块时如果程序要 fork 子进程一定要在 fork 之前fflush(NULL)清掉所有标准 IO 缓冲区否则日志出现重复就是家常便饭。3.3 什么时候必须绕过标准 IO标准 IO 方便但不是万能。以下几种场景建议直接用系统调用追求极致性能的高并发网络服务。每请求一个 buffer 就够用read/write减少拷贝。很多高性能中间件比如 Nginx 的部分路径、Redis 的持久化就直接用系统调用需要精细控制偏移量和高低水位。文件读写有时不希望有标准 IO 那层缓冲介入比如 PIPE 两端即时交互数据标准 IO 的缓冲会造成莫名延迟涉及epoll、fcntl设置非阻塞时fd 与系统调用配合更灵活标准 IO 层的 FILE 指针会引入额外状态机搅乱心智当然绝大多数场景下标准 IO 是更优选择它自动处理了缓冲、格式化、错误处理写起来也快得多。我个人的习惯是业务代码用标准 IO框架底层用系统调用。4. 重定向与 dup/dup2shell 的 和 | 背后是什么4.1 重定向的本质是修改描述符指向很多人用了很多年 shell每天都敲 log.txt却没想过它的底层机制。重定向的本质是一个进程在启动之前先把文件描述符 1或 2指向目标文件然后 exec 执行命令。比如ls out.txtshell 大概做了这些事情open(out.txt, O_WRONLY|O_CREAT|O_TRUNC, 0644)拿到 fd 3调用 dup2(3, 1)把 fd 3 复制到 fd 1 上即让描述符 1 指向 out.txt 对应的文件对象close(3)释放旧的 fdexec 执行 lsls 的 stdout 也就是 fd 1实际写到 out.txt因为 ls 自己根本不知道 stdout 是不是终端它只管往 fd 1 写所以重定向对大部分程序都是透明的。这也解释了为什么有些程序非要自己打开 /dev/tty 才能交互就是因为这类程序希望绕过重定向强制往终端输入输出。4.2 dup2 重定向输出的完整代码自己实现一个 shell 风格重定向核心代码并不复杂#include stdio.h #include fcntl.h #include unistd.h #include stdlib.h int main() { int fd open(out.txt, O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd 0) { perror(open); exit(1); } // 重定向 stdout 到文件 if (dup2(fd, STDOUT_FILENO) 0) { perror(dup2); exit(1); } close(fd); // 原始 fd 已经不需要了 printf(这句话会写到 out.txt 里\n); fprintf(stderr, 这句话仍会出现在终端\n); return 0; }这里有个细节很多人困惑为什么 dup2 之后要 close(fd)因为 dup2(fd, 1) 之后fd 1 和 fd 3 指向同一个文件对象两者没有区别。为了不浪费描述符资源也为了防止后面误操作 fd 3 影响 stdout标准做法是关闭原 fd。但注意此时不能关闭 fd 1 本身否则 stdout 就没了。再补充一个 dup 和 dup2 的区别dup 返回一个新的最小未使用 fd而 dup2 可以指定要赋值的目标 fd。dup2 的另一个特性是当 oldfd 不等于 newfd 时如果 newfd 已打开dup2 会先把它关闭再复制这个行为让重定向变得很安全。4.3 管道与进程间通信的 IO 视角shell 里的|管道符号本质是创建一个内存中的管道文件把一个进程的 stdout 接到另一个进程的 stdin。管道在内核里是一个环形缓冲区一端写一端读。cat large.txt | grep error | wc -l这条命令背后至少创建了两个管道。cat 的 fd 1 指向第一个管道的写端grep 的 fd 0 指向第一个管道的读端、fd 1 指向第二个管道的写端wc 的 fd 0 指向第二个管道的读端。值得注意的问题管道缓冲区是有容量上限的。传统管道默认 64KBLinux 上可通过 fcntl 修改当写端写入速度超过读端消费速度写进程会被阻塞在 write 调用上直到读端腾出空间。这就是制造管道阻塞类 bug 的根本原因。调试这种问题第一反应是看是不是管道满了而不是怀疑代码死循环。5. 内核缓冲区与 IO 性能为什么磁盘 IO 会明显变慢5.1 一次 write 系统调用经历了什么很多初学者对 write 有误解以为调用 write 就等于把数据写到磁盘了。实际上从用户态到磁盘中间隔了好几层用户态程序调用 write数据从用户缓冲区拷贝到内核的页缓存page cache内核把这次写操作标记为脏页并返回 write 成功脏页在之后由内核线程比如 pdflush / writeback异步刷到磁盘真正落盘完成后数据才算持久化换句话说write 返回成功只代表数据进了内核的页缓存不代表已经写到磁盘硬件上。如果这时候断电未落盘的数据就丢了。需要强制落盘的场景要调用fsync(fd)它会让内核阻塞等待脏数据刷盘后才返回。这也解释了热词里io性能明显下降了这一现象的常见根源如果业务每次写都调用 fsync性能就会断崖式下跌因为 SSD 的顺序写也扛不住每次刷盘。很多数据库的 WAL 日志、Redis 的 AOF 策略都是在吞吐和持久化之间做折中比如每秒 fsync 一次批量刷盘。5.2 页缓存、脏页比例与写放大内核缓冲区并不是越多越好页缓存占用过多内存会挤压应用可用内存所以内核有一整套调节参数vm.dirty_ratio脏页占系统内存的百分比上限默认 20%超过后内核强制同步写vm.dirty_background_ratio默认 10%后台写回线程开始刷盘vm.dirty_writeback_centisecs后台刷盘线程的唤醒间隔当你发现IO 性能明显下降了别急着找磁盘硬件的问题先看看是不是大量 dirty 页堆积导致强制同步写。cat /proc/meminfo | grep Dirty可以快速看脏页量如果长期接近比例上限要调整业务写入节奏或内核参数。对于磁盘性能测试dd命令是最常见的粗糙工具但很多人忽略了它的一些参数细节# 跳过页缓存直接读写磁盘测真实硬件性能 dd if/dev/sda of/dev/null bs1M count1024 iflagdirect # 默认走页缓存测的是缓存吞吐通常快得多不代表真实磁盘性能 dd if/dev/sda of/dev/null bs1M count1024加iflagdirect跳过页缓存对比两次速度差异就能大概判断瓶颈是在硬件还是在内核缓存策略。5.3 排查 IO 性能下降的实用三板斧遇到线上程序突然变慢我一般按下面这个顺序排查第一板斧strace -p pid看进程卡在哪个系统调用上。如果大量线程阻塞在 write 上说明写目标磁盘/管道/socket处理不过来。如果阻塞在 fsync说明磁盘刷盘太慢要么硬件老化要么交易量太大。第二板斧iostat -x 1看每个磁盘的 util、svctm、await。util 接近 100% 说明磁盘忙不过来await 明显高于 svctm 说明有排队可能是大量随机小 IO 导致 IOPS 打满。第三板斧lsof -p pid看进程打开了哪些文件确认是不是有日志文件无限增长、直接把磁盘空间耗尽df -h 看下或者在写一个被删除了的大文件这种情况 df 正常但磁盘一直不释放lsof 能看到 deleted 标记。实战教训曾经遇到一台机器磁盘空间明明没满但程序不断报 No space left on device最后 lsof 找到一个被删除的 40GB 日志文件文件句柄还开着磁盘空间一直被占用。所以大型服务必须做日志滚动logrotate而且删除日志前最好先 truncate 而非 rm避免句柄悬空。6. 面试高频题与避坑清单Linux IO 这样学才牢靠6.1 我整理的面试高频题目与速答要点结合自己准备面试的经历和被问过的题目整理了一份常见问题的清单每一道都值得亲手验证一遍问题关键答案要点什么是文件描述符进程文件描述符表的下标非负整数指向内核打开文件表有独立偏移量fd 和 FILE* 的区别fd 是系统调用层面的句柄FILE* 是标准 IO 库的封装包含用户态缓冲区read 返回 0 表示什么读取到 EOF注意不是读到空数据阻塞式 read 在无数据时不会返回 0write 完全可靠吗不可靠可能在写入中途返回需要循环写入且要处理 EINTRO_APPEND 为什么多进程安全偏移量移动和写入是原子操作见机动手fork 后缓冲区会重复输出吗会printf 未 flush 的缓冲区被子进程复制退出时重复 flushfork 前 fflush(NULL)dup2 和 dup 有什么区别dup2 可指定目标 fd自动关旧dup 最小未用分配fsync 有什么用强制把页缓存脏数据刷到磁盘提供持久性保证代价是性能下降标准 IO 缓冲有几种全缓冲、行缓冲、无缓冲文件默认全缓冲终端默认行缓冲stderr 无缓冲怎么排查进程卡在 IO 上strace 看系统调用iostat 看磁盘状态lsof 看文件句柄6.2 学习路径与实际操作建议如果让我给一条 Linux IO 的学习路线建议按这个顺序来第一步把文件描述符表和缓冲区模型印在脑子里尝试画出用户态缓冲区 - 内核页缓存 - 磁盘的完整链路图。注意这里的图用纸笔画就行关键是理解数据流动方向。第二步动手写代码验证。把文中的 forkprintf 示例、dup2 重定向示例、循环 read 的代码都编译运行一遍用 strace 观察系统调用。strace ./a.out能看到每一条系统调用和参数这是理解 IO 行为最快的方式。第三步用/usr/bin/time -v ./a.out看程序的 user time / system time对比标准 IO 和直接系统调用的时间差异。真实项目中IO 方式选错导致的性能差距可以达到数量级。第四步针对性做小实验用dd iflagdirect测量磁盘真实性能改变vm.dirty_ratio观察写入吞吐变化这样你对内核做缓冲才有切身体会。6.3 踩过的一些坑提前帮你们避开最后分享几个我实际踩过的坑真金白银换来的经验第一个坑是信号打断导致 IO 中断。早期写网络服务时不处理 EINTR压测时偶发连接断开排查了两天才发现是 read 被 SIGWINCH 这类无关信号打断代码没做重试。记住任何阻塞系统调用都要考虑 EINTR 分支。第二个坑是混合使用 fopen 和 open 操作同一个文件。标准 IO 的缓冲区和系统调用是两套机制不通过 fflush 就混着读会出现数据顺序错乱。要么全程标准 IO要么全程系统调用绝不混用。第三个坑是日志类的追加写没加 O_APPEND。我见过线上服务用 O_WRONLY 模式打开日志文件手动在日志模块里每次写之前 lseek 到文件末尾。一旦发生多线程或多进程同时写日志就会互相覆盖。换成 O_APPEND 之后问题彻底消失。第四个坑是忘记 close 导致 fd 泄漏。进程每打开一个文件就占一个描述符如果程序长期运行又不断 open 不 close最终 fd 耗尽报 too many open files。排查方法很简单ls /proc/pid/fd | wc -l统计打开数如果持续增长就是泄漏了。代码里尽量用 RAII 思想或类似机制保证每个 open 都有对应 close 路径。按照上面的步骤走一遍再配合几次实际问题的排查Linux 基础 IO 这块就算真正入门了。我自己回头看很多之前觉得玄学的现象——输出顺序乱、日志重复、性能突然下降、文件写不进去——归根结底都是对缓冲区和描述符的理解不到位。把这些基础打牢后续看网络编程、看存储框架都会顺畅得多。 深入理解Linux IO：文件描述符、系统调用与缓冲机制核心详解
最近在啃 Linux 基础 IO 这块越看越觉得这东西才是整个系统编程的骨架。不管是写网络服务、搞嵌入式还是日常排查线上问题最后都会绕回文件描述符、缓冲区和系统调用这三板斧。这篇笔记是我把 Linux IO 从底层到应用层重新捋了一遍之后的总结重点围绕文件描述符、open/read/write/close 这类系统调用、标准 IO 的缓冲机制、重定向与 dup/dup2以及 IO 性能排查这几个方向展开同时把面试里高频出现的细节坑也一并整理了。适合正在学 Linux 系统编程的同学、准备面试的后端开发以及被 IO 性能问题折磨过的运维和嵌入式工程师文中的代码和命令都可以直接拿过去跑一遍验证。1. 一切皆文件理解 Linux IO 的底层视角1.1 文件描述符是什么Linux 设计哲学里最核心的一句话就是一切皆文件。普通文件是文件目录是文件键盘鼠标是文件网卡 socket 是文件甚至进程间的管道、共享内存对象在 Linux 里都被抽象成了文件。正因为所有东西都能用文件的方式访问所以 IO 操作才能统一成一套接口打开、读写、关闭。那内核怎么区分一个进程打开了几十个不同的文件呢答案就是文件描述符file descriptor简称 fd。fd 本质上是一个非负整数它作为下标指向进程的文件描述符表这张表里每一项都是一个指向内核中打开文件表记录的指针。你平时调用的open()返回整数 fdread()、write()使用这个整数来定位到底操作哪个文件内核拿到这个整数后通过进程的文件描述符表找到对应的文件对象再完成实际 IO。关键点文件描述符是进程级的资源不是全局的。同一个文件被两个进程打开会得到两个不同的 fd也对应两个独立的文件描述符表项。这就是为什么多进程写同一个文件时各自的文件偏移量互不干扰。1.2 0、1、2 三个默认描述符每个进程启动时内核会默认打开三个文件描述符这是 POSIX 标准约定的也是 shell 能实现重定向的基础描述符名称常见指向0stdin键盘输入1stdout终端输出2stderr终端错误输出所以你在 C 代码里直接写write(1, hello, 5)就能往终端打一个 hello。很多脚本里出现的2/dev/null、1log.txt本质就是在 shell 层面对描述符 1 或 2 做重定向操作这个后面我单独讲。这里有个值得记住的细节printf 往 stdout 写perror 往 stderr 写。stderr 默认是无缓冲的stdout 如果是终端则行缓冲所以要保证错误信息能第一时间刷出来设计上是有意的。1.3 fd 分配的最小未用原则fd 不是随机分配的内核采用最小未使用值的分配策略。比如进程默认占用了 0、1、2你第一次open()拿到的 fd 一定是 3第二次是 4。如果中途 close(4) 了下一次 open 的时候又会优先分配 4而不是 5。这个特性很多人在学 dup2 的时候会忽略但它是理解重定向的钥匙。shell 在执行cmd file时就是先 open 一个文件得到 fd假设是 1但 1 已经被占用了怎么办shell 会先 close(1)再去 open 那个文件因为最小未使用原则新的 fd 刚好变回 1。后续 printf 往标准输出写实际就落到了文件里。2. 系统调用四件套open/read/write/close 的运行细节2.1 open 的 flags 参数怎么选open 函数原型是int open(const char *pathname, int flags, mode_t mode)。flags 是位图组合最常用的三组基础模式是O_RDONLY只读O_WRONLY只写O_RDWR读写注意这三者必须且只能选一个不能同时传O_RDONLY | O_WRONLY。配合使用的其他常用 flags 有O_CREAT文件不存在就创建此时需要第三个参数 mode 指定权限比如 0644O_TRUNC打开时把文件长度清空为 0覆盖写日志时慎用O_APPEND写入前自动把文件偏移量移到文件末尾多进程同时写日志文件时这个很关键O_EXCL和O_CREAT配合使用文件已存在则 open 失败这是创建锁文件的常用手段O_NONBLOCK非阻塞模式打开管道、设备时常用O_APPEND有一个隐蔽优势它保证每次 write 前内核都会把偏移量置为文件末尾而且这个移到末尾写入是原子操作。换句话说多进程并发往同一个文件里追加日志不会出现互相覆盖的问题。相比之下如果你自己先lseek到末尾再 write中间可能被其他进程打断。2.2 read 和 write 返回值的含义read 和 write 的返回值不是简单的成功/失败而是返回实际传输的字节数理解这一点能避开大量并发编程的坑。read返回大于 0 表示实际读到的字节数返回 0 表示读到 EOF也就是文件末尾返回 -1 表示出错具体原因看 errnowrite返回大于 0 表示实际写入的字节数返回 -1 表示出错特别要强调的是write 返回 N 不代表你传进去的 N 字节一次性全部写完了而是内核接受了 N 字节。在管道、socket、非阻塞 IO 的场景下write 可能只写了一半你必须做好循环写入。同理read 也可能只读了一部分不能假设一次 read 就把 buffer 装满。这也是为什么生产级代码里到处都是下面这样的封装ssize_t read_full(int fd, void *buf, size_t count) { ssize_t total 0; while (total count) { ssize_t n read(fd, (char *)buf total, count - total); if (n 0) break; // EOF if (n 0) { if (errno EINTR) continue; // 被信号打断重来 return -1; } total n; } return total; }这里面EINTR的处理是新手最容易漏的。当进程收到信号系统调用可能被中断read 返回 -1 并且 errno 为 EINTR这不是真正的错误应该重新调用。很多年久失修的代码不处理这个分支结果就是程序在信号频繁时莫名读写失败。2.3 lseek 与文件偏移量每个打开的文件对象都有独立的文件偏移量file offset读写共用同一个偏移量。lseek 可以把偏移量移到指定位置实现随机读写。off_t lseek(int fd, off_t offset, int whence);whence 有三种SEEK_SET偏移量设为 offset即从头开始算SEEK_CUR偏移量 当前位置 offsetSEEK_END偏移量 文件末尾 offset最实用的一个场景是读取文件头部信息比如读完头 100 字节后lseek(fd, 0, SEEK_SET)回到开头再读。还有一类冷知识是 lseek 可以超过文件结尾此时中间会产生一个空洞读洞里的数据全是\0文件系统并不为空洞分配磁盘块。这解释了为什么某些幽灵文件用ls -lh看着很大du看却占不了多少空间。2.4 一次完整的系统调用读写示例下面这段代码演示了标准 IO 和系统调用混用时的行为差异建议编译运行看看#include stdio.h #include unistd.h #include fcntl.h #include stdlib.h int main() { // 先用标准 IO 向 stdout 写一段 printf(standard io no newline); // 直接用系统调用写 write(1, syscall write\n, 14); // 如果不加下面这句你看到的输出顺序可能是 // syscall write // standard io no newline // 因为 printf 的数据还待在缓冲区进程结束时才 flush fflush(stdout); return 0; }运行后你会发现不调用 fflush 时write 的内容先打印printf 的内容最后才出来。原因就是标准 IO 库有自己的用户态缓冲区printf 只是把数据存进了缓冲区并没有立刻交给内核直到进程退出或缓冲区满才统一 flush。这个现象背后就是标准 IO 和系统调用之间的缓冲差异也是下一节的重点。3. 标准 IO 库与系统调用缓冲机制决定了你的程序性能3.1 三种缓冲模式C 标准库提供的 fopen/fread/fwrite/printf 等函数是在系统调用之上做了一层封装核心就是缓冲区管理。根据目标文件的类型标准 IO 库自动选择三种缓冲策略之一全缓冲fully buffered数据写满缓冲区默认 4096 字节或根据文件系统最优块大小才真正调用系统调用写入内核。普通文件的读写默认是全缓冲行缓冲line buffered遇到换行符\n就 flush。终端设备的输出默认是行缓冲所以 printf(hello\n) 能立刻显示无缓冲unbuffered每次写都立即转向系统调用最典型的就是 stderr保证错误信息不因程序崩溃而丢失用setvbuf可以手动修改缓冲模式这在做嵌入式日志输出、或者需要实时落盘时很常用。注意这里说的全缓冲/行缓冲是用户态 libc 的缓存和内核中的文件页缓存是两层东西。很多教程把这两个混在一起讲导致读者对write 到底什么时候落盘一知半解。下面我把分工说清楚标准 IO 缓冲解决的是用户态到内核态的系统调用次数内核页缓存解决的是内存到磁盘的 IO 次数。3.2 printf fork 为什么会出现双份输出这个问题几乎是面试必问也是实际开发里踩过的大坑。#include stdio.h #include unistd.h #include sys/wait.h int main() { printf(hello ); fork(); wait(NULL); return 0; }如果 stdout 是终端你只看到一个 hello。但如果把输出重定向到文件./a.out out.txt再打开文件一看里面会出现两个 hello。原因printf 往用户态缓冲区写入了 hello 但因为没有换行符数据仍然呆在缓冲区里。fork 时子进程复制了父进程的整个地址空间包括这份缓冲区内容。于是父进程退出时 flush 一份子进程退出时 flush 一份文件里就有两遍了。终端下行缓冲遇到没有换行的 printf 不会立刻输出但程序退出时会 flush。重定向到文件后是全缓冲同样的逻辑。这个案例告诉我们写日志模块时如果程序要 fork 子进程一定要在 fork 之前fflush(NULL)清掉所有标准 IO 缓冲区否则日志出现重复就是家常便饭。3.3 什么时候必须绕过标准 IO标准 IO 方便但不是万能。以下几种场景建议直接用系统调用追求极致性能的高并发网络服务。每请求一个 buffer 就够用read/write减少拷贝。很多高性能中间件比如 Nginx 的部分路径、Redis 的持久化就直接用系统调用需要精细控制偏移量和高低水位。文件读写有时不希望有标准 IO 那层缓冲介入比如 PIPE 两端即时交互数据标准 IO 的缓冲会造成莫名延迟涉及epoll、fcntl设置非阻塞时fd 与系统调用配合更灵活标准 IO 层的 FILE 指针会引入额外状态机搅乱心智当然绝大多数场景下标准 IO 是更优选择它自动处理了缓冲、格式化、错误处理写起来也快得多。我个人的习惯是业务代码用标准 IO框架底层用系统调用。4. 重定向与 dup/dup2shell 的 和 | 背后是什么4.1 重定向的本质是修改描述符指向很多人用了很多年 shell每天都敲 log.txt却没想过它的底层机制。重定向的本质是一个进程在启动之前先把文件描述符 1或 2指向目标文件然后 exec 执行命令。比如ls out.txtshell 大概做了这些事情open(out.txt, O_WRONLY|O_CREAT|O_TRUNC, 0644)拿到 fd 3调用 dup2(3, 1)把 fd 3 复制到 fd 1 上即让描述符 1 指向 out.txt 对应的文件对象close(3)释放旧的 fdexec 执行 lsls 的 stdout 也就是 fd 1实际写到 out.txt因为 ls 自己根本不知道 stdout 是不是终端它只管往 fd 1 写所以重定向对大部分程序都是透明的。这也解释了为什么有些程序非要自己打开 /dev/tty 才能交互就是因为这类程序希望绕过重定向强制往终端输入输出。4.2 dup2 重定向输出的完整代码自己实现一个 shell 风格重定向核心代码并不复杂#include stdio.h #include fcntl.h #include unistd.h #include stdlib.h int main() { int fd open(out.txt, O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd 0) { perror(open); exit(1); } // 重定向 stdout 到文件 if (dup2(fd, STDOUT_FILENO) 0) { perror(dup2); exit(1); } close(fd); // 原始 fd 已经不需要了 printf(这句话会写到 out.txt 里\n); fprintf(stderr, 这句话仍会出现在终端\n); return 0; }这里有个细节很多人困惑为什么 dup2 之后要 close(fd)因为 dup2(fd, 1) 之后fd 1 和 fd 3 指向同一个文件对象两者没有区别。为了不浪费描述符资源也为了防止后面误操作 fd 3 影响 stdout标准做法是关闭原 fd。但注意此时不能关闭 fd 1 本身否则 stdout 就没了。再补充一个 dup 和 dup2 的区别dup 返回一个新的最小未使用 fd而 dup2 可以指定要赋值的目标 fd。dup2 的另一个特性是当 oldfd 不等于 newfd 时如果 newfd 已打开dup2 会先把它关闭再复制这个行为让重定向变得很安全。4.3 管道与进程间通信的 IO 视角shell 里的|管道符号本质是创建一个内存中的管道文件把一个进程的 stdout 接到另一个进程的 stdin。管道在内核里是一个环形缓冲区一端写一端读。cat large.txt | grep error | wc -l这条命令背后至少创建了两个管道。cat 的 fd 1 指向第一个管道的写端grep 的 fd 0 指向第一个管道的读端、fd 1 指向第二个管道的写端wc 的 fd 0 指向第二个管道的读端。值得注意的问题管道缓冲区是有容量上限的。传统管道默认 64KBLinux 上可通过 fcntl 修改当写端写入速度超过读端消费速度写进程会被阻塞在 write 调用上直到读端腾出空间。这就是制造管道阻塞类 bug 的根本原因。调试这种问题第一反应是看是不是管道满了而不是怀疑代码死循环。5. 内核缓冲区与 IO 性能为什么磁盘 IO 会明显变慢5.1 一次 write 系统调用经历了什么很多初学者对 write 有误解以为调用 write 就等于把数据写到磁盘了。实际上从用户态到磁盘中间隔了好几层用户态程序调用 write数据从用户缓冲区拷贝到内核的页缓存page cache内核把这次写操作标记为脏页并返回 write 成功脏页在之后由内核线程比如 pdflush / writeback异步刷到磁盘真正落盘完成后数据才算持久化换句话说write 返回成功只代表数据进了内核的页缓存不代表已经写到磁盘硬件上。如果这时候断电未落盘的数据就丢了。需要强制落盘的场景要调用fsync(fd)它会让内核阻塞等待脏数据刷盘后才返回。这也解释了热词里io性能明显下降了这一现象的常见根源如果业务每次写都调用 fsync性能就会断崖式下跌因为 SSD 的顺序写也扛不住每次刷盘。很多数据库的 WAL 日志、Redis 的 AOF 策略都是在吞吐和持久化之间做折中比如每秒 fsync 一次批量刷盘。5.2 页缓存、脏页比例与写放大内核缓冲区并不是越多越好页缓存占用过多内存会挤压应用可用内存所以内核有一整套调节参数vm.dirty_ratio脏页占系统内存的百分比上限默认 20%超过后内核强制同步写vm.dirty_background_ratio默认 10%后台写回线程开始刷盘vm.dirty_writeback_centisecs后台刷盘线程的唤醒间隔当你发现IO 性能明显下降了别急着找磁盘硬件的问题先看看是不是大量 dirty 页堆积导致强制同步写。cat /proc/meminfo | grep Dirty可以快速看脏页量如果长期接近比例上限要调整业务写入节奏或内核参数。对于磁盘性能测试dd命令是最常见的粗糙工具但很多人忽略了它的一些参数细节# 跳过页缓存直接读写磁盘测真实硬件性能 dd if/dev/sda of/dev/null bs1M count1024 iflagdirect # 默认走页缓存测的是缓存吞吐通常快得多不代表真实磁盘性能 dd if/dev/sda of/dev/null bs1M count1024加iflagdirect跳过页缓存对比两次速度差异就能大概判断瓶颈是在硬件还是在内核缓存策略。5.3 排查 IO 性能下降的实用三板斧遇到线上程序突然变慢我一般按下面这个顺序排查第一板斧strace -p pid看进程卡在哪个系统调用上。如果大量线程阻塞在 write 上说明写目标磁盘/管道/socket处理不过来。如果阻塞在 fsync说明磁盘刷盘太慢要么硬件老化要么交易量太大。第二板斧iostat -x 1看每个磁盘的 util、svctm、await。util 接近 100% 说明磁盘忙不过来await 明显高于 svctm 说明有排队可能是大量随机小 IO 导致 IOPS 打满。第三板斧lsof -p pid看进程打开了哪些文件确认是不是有日志文件无限增长、直接把磁盘空间耗尽df -h 看下或者在写一个被删除了的大文件这种情况 df 正常但磁盘一直不释放lsof 能看到 deleted 标记。实战教训曾经遇到一台机器磁盘空间明明没满但程序不断报 No space left on device最后 lsof 找到一个被删除的 40GB 日志文件文件句柄还开着磁盘空间一直被占用。所以大型服务必须做日志滚动logrotate而且删除日志前最好先 truncate 而非 rm避免句柄悬空。6. 面试高频题与避坑清单Linux IO 这样学才牢靠6.1 我整理的面试高频题目与速答要点结合自己准备面试的经历和被问过的题目整理了一份常见问题的清单每一道都值得亲手验证一遍问题关键答案要点什么是文件描述符进程文件描述符表的下标非负整数指向内核打开文件表有独立偏移量fd 和 FILE* 的区别fd 是系统调用层面的句柄FILE* 是标准 IO 库的封装包含用户态缓冲区read 返回 0 表示什么读取到 EOF注意不是读到空数据阻塞式 read 在无数据时不会返回 0write 完全可靠吗不可靠可能在写入中途返回需要循环写入且要处理 EINTRO_APPEND 为什么多进程安全偏移量移动和写入是原子操作见机动手fork 后缓冲区会重复输出吗会printf 未 flush 的缓冲区被子进程复制退出时重复 flushfork 前 fflush(NULL)dup2 和 dup 有什么区别dup2 可指定目标 fd自动关旧dup 最小未用分配fsync 有什么用强制把页缓存脏数据刷到磁盘提供持久性保证代价是性能下降标准 IO 缓冲有几种全缓冲、行缓冲、无缓冲文件默认全缓冲终端默认行缓冲stderr 无缓冲怎么排查进程卡在 IO 上strace 看系统调用iostat 看磁盘状态lsof 看文件句柄6.2 学习路径与实际操作建议如果让我给一条 Linux IO 的学习路线建议按这个顺序来第一步把文件描述符表和缓冲区模型印在脑子里尝试画出用户态缓冲区 - 内核页缓存 - 磁盘的完整链路图。注意这里的图用纸笔画就行关键是理解数据流动方向。第二步动手写代码验证。把文中的 forkprintf 示例、dup2 重定向示例、循环 read 的代码都编译运行一遍用 strace 观察系统调用。strace ./a.out能看到每一条系统调用和参数这是理解 IO 行为最快的方式。第三步用/usr/bin/time -v ./a.out看程序的 user time / system time对比标准 IO 和直接系统调用的时间差异。真实项目中IO 方式选错导致的性能差距可以达到数量级。第四步针对性做小实验用dd iflagdirect测量磁盘真实性能改变vm.dirty_ratio观察写入吞吐变化这样你对内核做缓冲才有切身体会。6.3 踩过的一些坑提前帮你们避开最后分享几个我实际踩过的坑真金白银换来的经验第一个坑是信号打断导致 IO 中断。早期写网络服务时不处理 EINTR压测时偶发连接断开排查了两天才发现是 read 被 SIGWINCH 这类无关信号打断代码没做重试。记住任何阻塞系统调用都要考虑 EINTR 分支。第二个坑是混合使用 fopen 和 open 操作同一个文件。标准 IO 的缓冲区和系统调用是两套机制不通过 fflush 就混着读会出现数据顺序错乱。要么全程标准 IO要么全程系统调用绝不混用。第三个坑是日志类的追加写没加 O_APPEND。我见过线上服务用 O_WRONLY 模式打开日志文件手动在日志模块里每次写之前 lseek 到文件末尾。一旦发生多线程或多进程同时写日志就会互相覆盖。换成 O_APPEND 之后问题彻底消失。第四个坑是忘记 close 导致 fd 泄漏。进程每打开一个文件就占一个描述符如果程序长期运行又不断 open 不 close最终 fd 耗尽报 too many open files。排查方法很简单ls /proc/pid/fd | wc -l统计打开数如果持续增长就是泄漏了。代码里尽量用 RAII 思想或类似机制保证每个 open 都有对应 close 路径。按照上面的步骤走一遍再配合几次实际问题的排查Linux 基础 IO 这块就算真正入门了。我自己回头看很多之前觉得玄学的现象——输出顺序乱、日志重复、性能突然下降、文件写不进去——归根结底都是对缓冲区和描述符的理解不到位。把这些基础打牢后续看网络编程、看存储框架都会顺畅得多。