深入理解Linux文件IO：文件描述符、重定向与缓冲机制详解

1. 先回答文件是什么从设备到文件的抽象1.1 一切皆文件但这句话到底是什么意思我刚开始学Linux的时候周围人反复跟我强调一句话Linux下一切皆文件。那时候我只把它当成一句口号记下来真正理解它是在我尝试写一个用C语言操作键盘的小程序之后。当时我突发奇想想直接从设备文件里读键盘输入。查了一圈资料发现Linux把键盘抽象成了/dev/input/eventX这样的字符设备文件鼠标也有对应的设备文件网卡虽然特殊一点但也能用socket的方式抽象成fd。这让我意识到一切皆文件不是修辞手法而是一个实实在在的工程抽象——不管底层是磁盘上的普通文件、键盘这种字符设备、还是内存里的管道在内核眼里它们统统可以用同一套接口去访问。这套接口的核心就是文件描述符File Descriptor简称fd。对用户态的程序来说fd就是一个数字对内核来说fd是打开文件表里的索引通过这个索引能找到一个struct file对象。而struct file里真正厉害的地方在于它装着一组函数指针这些指针指向不同文件类型各自的读写实现。也就是说你调用read(fd, ...)的时候内核根据fd找到对应的函数指针然后调用它指向的具体实现——对普通文件就调普通文件的读函数对设备文件就调设备驱动的读函数。这就是为什么我可以在用户态用一个统一的open/read/write/close四件套去操作各种不同的资源。搞明白了这点后续看任何IO相关的代码都不会再觉得迷茫。1.2 文件描述符一张通往内核的机票有人把fd比作文件句柄也有人把它比作门牌号我更喜欢把它想成一张机票。你手里拿着这张机票上面写着一个数字检票口的工作人员内核看到这个数字就知道该带你去哪个登机口对应的文件对象。这张机票本身只是一个整数通常是int类型而且数值是从小到大分配的。每个进程默认打开三个fd0号是标准输入stdin1号是标准输出stdout2号是标准错误stderr。这三个fd不是天生的是父进程在创建子进程时继承下来的至于它们指向什么取决于你这个进程是在终端里启动的还是在某个脚本里被重定向的。我印象最深的一次经历是我用Shell执行echo hello 1/dev/null然后想知道程序里看到的1号fd到底是什么。用strace跟踪后发现Shell在执行echo之前先打开/dev/null拿到一个fd然后通过dup2把这个fd复制到了1号位置。也就是说子进程的1号fd确实指向/dev/null而不是终端。这个操作背后的细节我在后面讲重定向原理的时候会详细拆开。2. open系统调用打开文件的全部细节2.1 函数签名与参数拆解所有文件操作的第一步都是open。它的函数签名长这样#include sys/types.h #include sys/stat.h #include fcntl.h int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode);pathname文件路径可以是相对路径也可以是绝对路径。flags访问模式标志决定你要怎么打开这个文件。mode创建新文件时的权限位只有flags里带了O_CREAT的时候才需要传。open成功返回一个非负的fd失败返回-1并设置errno。有一个所有初学者都会踩的坑判断失败不能只写if (fd)因为成功返回的fd有可能是0。应该写if (fd 0)或者if (fd -1)。我自己也在这个坑里摔过一次。当时我写了一个小程序判断文件是否打开成功用了if (!fd)结果后来才知道如果程序把0号fd关闭了再打开一个文件时内核会分配最小的可用fd——也就是0。这直接导致我的程序逻辑反了文件明明打开成功了我却认为它失败了。2.2 flags的三种必选模式与小细节flags里有一组访问模式是必须三选一的O_RDONLY只读打开O_WRONLY只写打开O_RDWR读写打开注意这三个值不是简单的组合关系。O_RDONLY的值是0O_WRONLY是1O_RDWR是2。所以在内核内部有专门的位运算来提取这个模式而不是直接flag 0x3这样简单粗暴地判断。这一点在阅读内核源码时容易困惑先记住结论就好。除了访问模式还有一批常用的辅助标志标志作用使用场景O_CREAT文件不存在则创建写日志、保存新文件O_TRUNC打开时把文件长度截断为0覆盖写入O_APPEND每次写入追加到末尾日志系统O_CLOEXEC执行exec时自动关闭fd防止fd泄漏到子进程O_NONBLOCK非阻塞打开管道、设备文件O_EXCL与O_CREAT一起用文件已存在则报错防止覆盖、创建锁文件2.3 mode参数与umask的相互作用如果flags里带了O_CREAT那第三个参数mode就派上了用场。它看起来是一个权限位比如0644表示用户读写、组读、其他人读但实际生效的权限并不完全等于这个值。比如我在终端里执行umask返回的是0022。这意味着我创建一个新文件时最终权限是mode ~umask也就是0644 ~0022算出来还是0644。但如果umask是0027那0644 ~0027就会变成0640。这个机制是安全设计系统不允许你创建一个比当前umask允许范围更开放的文件。所以写代码的时候不要指望传一个0666就能创建出人人可读写的文件——umask不答应。我习惯在创建文件时显式传0666或0644然后配合默认umask使用而不是写死更宽松的权限。因为即使你写了0777内核也会被umask限制住不如老老实实按常规写。2.4 一个完整的open示例下面这段代码演示了打开和创建文件的完整姿势#include stdio.h #include fcntl.h #include unistd.h #include errno.h #include string.h int main(void) { // O_CREAT | O_WRONLY | O_TRUNC不存在就创建存在就清空 // 最终权限是 0644 ~umask int fd open(/tmp/my_demo.log, O_CREAT | O_WRONLY | O_TRUNC, 0644); if (fd -1) { fprintf(stderr, open failed: %s\n, strerror(errno)); return 1; } write(fd, hello fd\n, 9); close(fd); return 0; }3. read/write/close数据搬运的三板斧3.1 read的返回值三种情况要分清楚read的签名是ssize_t read(int fd, void *buf, size_t count);它做的事情是从fd对应的文件里读出最多count个字节放进buf。返回值要分三种情况看待返回正数表示实际读到的字节数可能小于count此时必须用返回值而不是count来计算后续逻辑。返回0表示读到文件末尾EOF或对端关闭连接。返回-1表示出错还要看errno。如果errno是EINTR表示被信号打断这时候可以重试。操作普通磁盘文件时read一般都能按你给的字节数读完但在管道、socket、终端设备上部分读是家常便饭。你要是默认一次read就能取回全部数据程序迟早出bug。写网络程序的时候我用过一个通用读取函数本质就是循环调用read累积到目标长度逻辑类似这样ssize_t read_full(int fd, void *buf, size_t count) { size_t done 0; while (done count) { ssize_t n read(fd, (char *)buf done, count - done); if (n 0) { break; // EOF不完整 } if (n 0) { if (errno EINTR) { continue; } return -1; } done n; } return (ssize_t)done; }3.2 write的部分写问题write的签名是ssize_t write(int fd, const void *buf, size_t count);往fd里写最多count个字节。平时写普通文件write基本都能一次写完但在管道、socket、终端上也有部分写的可能。所以我写日志或文件拷贝程序时也会套一层write_full的循环确保要写的数据全部写完才返回成功而不是写一次就看结果。注意write返回0的情况极其罕见如果返回0多半是传入了0长度。3.3 一个简易cp命令的完整实现把上面的知识串起来你可以用不到30行代码实现一个简易版cp#include stdio.h #include fcntl.h #include unistd.h #include errno.h #include string.h int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, usage: %s src dst\n, argv[0]); return 1; } int in open(argv[1], O_RDONLY); if (in -1) { perror(open src); return 1; } int out open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0644); if (out -1) { perror(open dst); close(in); return 1; } char buf[4096]; ssize_t n; while ((n read(in, buf, sizeof(buf))) 0) { ssize_t written 0; while (written n) { ssize_t m write(out, buf written, n - written); if (m -1) { perror(write); close(in); close(out); return 1; } written m; } } if (n -1) { perror(read); } close(in); close(out); return 0; }代码本身很简单但细看有几个点值得注意缓冲区用了4096字节也就是4KB。这个值不是随便拍的4KB在绝大多数文件系统上正好等于一个文件系统块大小用这个大小做读写往往能获得比较好的性能。读文件时用循环因为单次read可能不会把缓冲区填满。写文件时又做了一层循环防止部分写导致数据不完整。我拿这个程序拷过一个大文件实测性能跟系统自带的cp差了一个数量级原因主要是系统cp用了sendfile之类的高级系统调用避免了数据在用户态和内核态之间来回拷贝。这个优化方向我留到后面的基础IO【下】里再展开。3.4 close的细节比想象中更重要close的签名很简单int close(int fd);。但有几个细节如果不了解会在实际工程里踩大坑。第一close只是把当前进程的fd从打开文件表里移除不代表文件对象被彻底释放。如果同一个文件被打开多次拿到了多个fd或者通过dup/fork复制了fd那么只有所有fd都关闭了文件对象才会真正释放。第二在fork之后父进程和子进程共享同一个文件偏移量。如果不小心在两个进程里同时写同一个文件并且没做好同步写出来的数据会互相覆盖。第三close返回错误时最常见的原因是EINTR或者EBADF。EBADF表示你传入的fd根本不存在这个好查EINTR表示close被信号打断这种情况是否需要重试有争议但我在工程实践中倾向直接忽略并继续因为fd在close返回EINTR时其实已经标记为关闭了。4. 系统调用与C库函数所见并非所得4.1 printf和write的真面目很多初学者对printf和write的关系感到困惑。用一个非常简单的话来总结printf是C标准库提供的高级接口write是操作系统提供的系统调用。我在一道面试题里遇到过这样的场景程序里写了一个printf(hello)紧接着执行fork()你猜屏幕上会出现几个hello答案是2个而且让人摸不着头脑。原因在于printf往标准输出写数据时如果输出目标是终端那标准库默认采用行缓冲模式也就是遇到换行符就把缓冲区内容刷出去。但如果你是用重定向把标准输出指向了磁盘文件标准库会改用全缓冲模式printf(hello)里的数据会留在C库缓冲区里等缓冲区满了或者程序正常退出才真正刷到内核。fork复制进程的时候会把C库缓冲区里的内容也复制一份。于是父亲和儿子手里都有一份hello还没写出去等到程序退出时两个人各自把缓冲区里的内容交给内核屏幕上自然就出现了两个hello。这个问题我在写守护进程或日志程序的时候也遇到过。解决方案很简单在fork之前调fflush(NULL)把所有用户态缓冲区强制清掉。4.2 fflush和fsync两种刷新不是一回事提到刷新这里有个很关键的区分。fflush是把C库的用户态缓冲区数据交给内核fsync是把内核页缓存里的数据真正落盘。也就是说一个数据从printf到真正写进磁盘要经过这么几层printf把数据写进C库缓冲区用户态。缓冲区满、换行、程序退出或调fflush时数据通过write系统调用进入内核页缓存。内核在某个合适的时机比如脏页达到阈值、显式调用fsync或fdatasync时把页缓存写回磁盘。所以我给项目写数据库WAL日志时一定是write之后立刻调fsync否则系统一断电日志丢了都不知道怎么回事。这是保证数据持久化的底线。4.3 dup2Shell重定向背后的功臣再看一个非常经典的问题为什么在Shell里执行echo hello file就能把输出写到文件里答案藏在dup2这个系统调用里。dup2(oldfd, newfd)的作用是让newfd指向和oldfd同一个内核文件对象。如果newfd原本已经打开着其他文件内核会自动把它先关闭。Shell执行重定向的完整流程是这样的fork()创建子进程。子进程里open(file, O_WRONLY | O_CREAT | O_TRUNC, 0644)拿到一个fd假设是3。dup2(3, 1)让1号fd指向新打开的file对应的文件对象。close(3)关掉原来那个3号fd。exec执行echo hello。由于1号fd已经指向文件echo的输出自然就写进了文件里。注意dup2之后原来1号fd指向的文件也就是终端引用计数减一只要没有其他fd指向它了终端输出就被切断了。这也是为什么21能把标准错误和标准输出合并到同一个地方——它本质上是dup2(1, 2)。我自己在写自动化脚本时经常用这个技巧。比如想在一个程序里临时把标准输出重定向到日志文件又怕忘了恢复可以这样做int saved dup(1); // 备份当前标准输出 int fd open(/tmp/log, O_WRONLY | O_CREAT | O_APPEND, 0644); dup2(fd, 1); // 重定向 // 此时程序里的printf都会写到 /tmp/log close(fd); // 别忘了关闭 // 在你需要恢复的地方 dup2(saved, 1); close(saved);注意这里我用了dup而不是直接dup2来备份因为dup会返回一个新的、最小的fd不会破坏原来的1号fd。5. 文件描述符的分配规则0、1、2与最小未用原则5.1 为什么新打开的文件总是占最小可用的fd这个话题是我在排查一个诡异bug时彻底搞明白的。有一次我写了一个定时跑批任务任务内部要打开一个配置文件结果日志里出现了很多open: no such file之类的错误。我查了很久最后用strace一看才发现问题在于这个任务的标准输入被某个上层脚本关闭了导致0号fd没有被占用。当我的程序第一次open配置文件的时候内核把fd0分配给了它。我的代码里虽然没有直接拿0号fd做坏事但这个奇怪的现象让我意识到fd的分配规则是内核总是返回当前进程中最小的未使用fd。也就是说如果0号fd被关闭新打开的文件就会占据0号位置。这个规则也解释了为什么标准库函数执行fclose(stdin)之后再打开一个文件那个文件会自动成为0号标准输入。在某些老旧的网络服务代码里有人会故意close(0); open(/dev/null, O_RDONLY);来把标准输入指向/dev/null目的就是防止程序误把用户输入当成标准输入流。5.2 从fd分配看Shell各种重定向符号明白了fd分配规则再回头看Shell的重定向符号就非常顺畅了写法含义底层动作 file标准输出重定向到fileopen然后dup2到1号fd2 file标准错误重定向到fileopen然后dup2到2号fd file追加模式重定向open时带O_APPEND12标准输出合并到标准错误dup2(2, 1)21标准错误合并到标准输出dup2(1, 2)0 file标准输入重定向为fileopen然后dup2到0号fd搜索热词里出现了linux常用命令大全linux常用100个命令这一类其实很多命令的底层都离不开这些文件描述符操作。比如grep xxx /tmp/log 2/dev/null本质就是把错误输出丢进黑洞cat file | grep xxx本质就是用管道把cat的1号fd和grep的0号fd串在一起。我觉得对IO的理解一旦深入到fd这一层你看Shell脚本的眼界会完全不一样。之前很多命令是死记硬背现在就能自己推演出正确的写法。5.3 用strace旁观一次真实IO纸上谈兵没意思我建议你亲自动手跑一次下面这个命令strace -e traceopen,openat,close,dup,dup2,read,write -f bash -c echo hello /tmp/demo.txt你会看到Shell进程做了一连串操作先打开/tmp/demo.txt拿到一个fd通常是3然后dup2(3, 1)把标准输出指过去最后执行echo程序里其实做的就是write(1, hello\n, 6)这回事。我每次向别人解释Linux重定向都会现场演示一遍strace输出比讲一小时的原理都管用。有时候不光是学习工程排查也用得上这个手段程序行为不符合预期时先看它syscall层面到底做了什么80%的问题能暴露出来。6. 我踩过的几个坑和相应的排查思路6.1 日志不落盘被缓冲坑了我早期写过一个日志模块输出格式是log_xxx但生产环境上日志总是不及时出现在文件里程序一退出数据又完整了。当时本能的反应是我写入的代码没生效实际上是我自己把所有输出都用printf写了而标准库在重定向到文件时选择了全缓冲缓冲区没满就不往内核写。排查过程先看程序运行时的strace发现在运行期间根本没有write系统调用被触发。然后怀疑是日志级别配置问题查了一圈发现不是。最后在代码里临时加了个setvbuf(stdout, NULL, _IONBF, 0)程序立刻真实调用了write数据也及时落盘了。从此我在写正式项目时无论日志还是通用输出都明确指定缓冲模式绝不做 默认行为 的赌徒。6.2 重复关闭fd导致的诡异崩溃另一个典型问题是对同一个fd调用了两次close。第一次close没有问题第二次close就可能把内核里恰好分配给别的文件的fd给关了造成比内存泄漏难查一百倍的bug。判断方法也很简单close(fd)之后立刻把fd置为-1或者在程序里加一个全局的fd管理表。C语言没有自动管理fd的机制这个习惯务必练起来。6.3 为什么终端执行和脚本执行表现不一样这是一个从新手期一直困扰我到学会看缓冲机制的问题同一段代码在终端里跑表现正常放到脚本里或者通过输出重定向再跑输出顺序就乱了。原因还是缓冲模式。终端上stdout是行缓冲遇到换行就输出重定向到文件后是全缓冲而stderr永远是无缓冲。如果程序先fprintf(stderr, error)再printf(normal)在终端里因为行缓冲每个输出大致保持顺序重定向到文件后normal可能因为缓冲还没满而暂时留在缓冲区导致它在文件里出现在error后面很晚才出现。解决思路还是那句话要么在关键位置fflush(NULL)要么一开始就给stdout设置无缓冲或行缓冲。程序行为不应该依赖运行环境来决定这一点是我从几个头疼的告警日志问题里总结出来的血泪经验。6.4 思考问题时的两条思路遇到文件IO相关的问题我自己已经形成两条排查思路分享出来供你参考先看syscall再看业务逻辑。strace -f -e tracefile,desc能在几秒内告诉你进程打开了哪些文件、在哪些fd上做了什么、有没有dup2被调用。内核行为一目了然。先看缓冲再看并发。如果数据没及时出现优先怀疑缓冲如果数据出现了但顺序不对或内容损坏再考虑是不是多进程/多线程共享fd、是不是fork后偏移量共享导致的互相覆盖。这两条思路帮我解决过至少几十个跟基础IO相关的生产问题。Linux基础IO这个主题看似简单但它是整个操作系统运行的地基值得花时间彻底搞透。这篇先讲到这里。后半部分我会把重定向、管道、文件系统的IO栈、缓冲区优化这些内容展开讲尤其是sendfile、mmap这类高效IO方式它们在真实工程里的价值远比你想象的大。