前阵子在排查一个服务端问题现象特别诡异日志里同一行内容总会成对出现内容一模一样连时间戳附近的字段都完全一致。第一反应是逻辑里出现了重复调用可翻遍代码也没找到可疑路径。后来才发现问题出在 stdio 的输出缓冲区与 fork 的组合上。这类坑在 C/C 服务端开发里太常见了尤其是用 printf 做调试、再搭配 fork 派生子进程的时候。你可能已经听过fork 会复制进程地址空间这句话但很少会意识到复制地址空间的同时也复制了还没写出去的 stdio 缓冲区。这篇文章就把这个知识点拆开讲清楚从缓冲机制、真实复现、到修复方案和排查技巧一次说透。适合写 C/C 服务、做后台任务、或者被重复日志困扰的开发者。1. 先搞清楚 stdio 输出缓冲区到底怎么工作1.1 三种缓冲模式与默认行为C 标准库里的文件流默认都有用户态缓冲区一共有三种模式模式宏定义触发刷新条件典型场景全缓冲_IOFBF缓冲区写满、显式 fflush、正常退出刷新stdout 指向文件或管道行缓冲_IOLBF遇到换行符、显式 fflush、正常退出刷新stdout 指向交互终端无缓冲_IONBF每次输出都直接写stderr 默认就是这种这里有个容易忽略的点stdout 默认用哪种模式取决于它连接的是什么设备。如果 stdout 连接的是终端glibc 会把它设成行缓冲如果 stdout 被重定向到普通文件、管道、socket就会变成全缓冲。很多服务进程在容器里运行stdout 被日志采集进程用管道读走这时候你以为每一行日志都实时落盘了实际上数据全堆在用户态缓冲区里攒够了才写一次。1.2 缓冲区存在的意义减少系统调用没有缓冲区的话每次printf(...)都要调用一次write系统调用。系统调用意味着用户态切换到内核态、参数检查、数据拷贝成本不低。高频打印的场景下一次一次 write 会把性能拖垮。缓冲区做的事情就是攒批printf 先把数据写到进程内存里的一段区域等区域满了、或者遇到换行行缓冲、或者程序主动刷新再一次性调用 write 把整段数据交给内核。你可以把它理解成快递柜一件一件单独跑腿送太慢先堆在柜子里凑够一批再统一发货。性能上去了代价就是输出时机变得不直观。你以为打印了其实数据还躺在内存里根本没进内核更没到磁盘或管道对端。1.3 printf 加 \n 并不是可靠的刷新信号很多人习惯用printf(hello\n)以为加了换行就万事大吉。这个想法只在 stdout 连接终端的时候成立因为终端场景是行缓冲换行确实会触发刷新。但一旦 stdout 变成全缓冲比如你在命令行执行./app log.txt换行符只是数据里的一个普通字节缓冲区不会因此刷新。等 fork 之后这段带着换行的数据如果还留在缓冲区里问题就来了。记住换行刷新是行缓冲模式的特性不是 printf 的特性。判断依据永远是stdout 连接的是什么 fd。2. fork 之后为什么输出会重复2.1 fork 复制的不只是代码还有缓冲区fork 创建子进程时几乎复制了整个用户态地址空间包括所有 .data 段、.bss 段、堆、栈以及 glibc 在内存里维护的 FILE 结构体和里面的缓冲区。这句话要拆开理解FILE 结构体除了文件描述符、偏移、状态标志之外还有一个关键成员就是用户态缓冲区。这个缓冲区是通过 malloc 之类分配的本质上就是进程堆里的一块普通内存。fork 之后父进程和子进程各有一份内容完全相同的缓冲区。缓冲区里的数据是还没交给内核的数据。这些数据不属于文件描述符也不属于内核只是当前进程内存里的私有副本。所以 fork 不会帮你保留它们而是帮你复制了它们。2.2 最小复现 demo看下面这段代码#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(before fork\n); fork(); wait(NULL); return 0; }编译后直接运行./a.out输出一次before fork。但如果重定向到文件./a.out out.txt cat out.txt输出两次before fork。同样一份代码为什么结果不一样就是因为终端下行缓冲\n触发刷新printf的数据在 fork 之前已经写进内核了fork 复制不到任何残留。而重定向到文件后 stdout 变成全缓冲before fork\n还留在用户态缓冲区里fork 把这个缓冲区复制成两份两个进程退出时各自刷新一次就变成了两行。2.3 不是数据被切分而是同一份数据被写了两遍要特别注意重复输出不是父进程输出一半、子进程输出一半而是两个进程各自持有一份完整的、一模一样的残留数据退出时各自调用 write把同一段内容写了两遍。这里还涉及一个底层细节fork 之后父子进程共享同一个打开文件描述意味着它们共享同一个文件偏移。父进程先退出write 把数据写到偏移 N 处偏移前进到 Nlen。子进程后退出它写的数据会从当前偏移继续写所以不会覆盖父进程写的内容而是紧跟在后面追加一遍。结果就是你看到的两行连续相同内容。如果父子进程各自重新 open 了同一路径的文件那文件偏移是独立的还可能互相覆盖。但最常见的共享 stdout 重定向文件场景偏移是共享的所以现象就是追加重复。2.4 你以为的 fork 执行了两次其实是缓冲区很多刚踩坑的人会误判成fork 没起作用还是 fork 被调用了两次。区分办法很简单在 fork 之后打印当前进程的 PID比如#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(before fork\n); pid_t pid fork(); printf(after fork, pid %d\n, getpid()); if (pid 0) { wait(NULL); } return 0; }如果看到的是两行before fork但after fork各自带有不同的 PID那就说明 fork 只调用了一次重复的是缓冲区。如果after fork也出现了两遍且 PID 不同那说明 fork 后的代码在两个进程里各自执行了一次这是正常现象不是重复。3. exit 和 _exit 的差异决定了重复是否发生3.1 exit 会刷新缓冲区_exit 不会这是和缓冲区重复强相关的第二个关键点main 里的 return 0最终会调用 exit 系列函数它会刷新所有 stdio 流。所以父进程和子进程正常退出时都会把继承来的缓冲数据写出去。如果你想在子进程里避免刷新父进程留下来的缓冲可以用_exit()或_Exit()。它们直接进入内核终止进程不经过 glibc 的清理步骤不会刷新 stdio 缓冲区。#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(before fork\n); pid_t pid fork(); if (pid 0) { wait(NULL); return 0; } _exit(0); }这样重定向到文件时子进程不会把父进程残留的缓冲区再写一遍输出就只有父进程那一次。3.2 但 _exit 也会丢掉子进程自己的输出_Exit 不是万能的。如果子进程 fork 之后自己又 printf 了内容直接 _exit 会导致这些新输出全部丢失因为它们也停留在用户态缓冲区里。pid_t pid fork(); if (pid 0) { printf(child output\n); _exit(0); // 这行可能不会出现在文件里 }如果你确实需要子进程输出正确的做法是在子进程里先fflush(NULL)再退出或者使用exit(0)。用exit(0)的话子进程自己的输出会被刷新但父进程残留的缓冲也会被一起刷新又会出现重复。所以核心不是用 exit 还是 _exit而是fork 之前必须保证缓冲区是空的。3.3 父子进程谁先退出会影响结果但不能避免重复有人会想让父进程 wait 一下等子进程先退出是不是就只输出一次了不会。wait 只改变执行顺序不会清空两个进程各自手里的缓冲区副本。子进程退出时它手里的那份残留数据照样会写出去哪怕父进程还没退出重复依然存在。只有一种情况可以绕开fork 之前或者 fork 之后立即把缓冲区清空让任何进程手里都没有残留数据可写。4. 修复方案从应急到根治4.1 最直接的方法fork 前执行 fflush(NULL)fflush(NULL)一次刷新所有打开的 stdio 流。这是最符合直觉、也是最稳妥的做法printf(some log\n); fflush(NULL); pid_t pid fork();这样 fork 发生时用户态缓冲区是空的子进程继承到的也是一份空缓冲区。之后父子进程各自产生的输出各自负责刷新不会出现复制残留的问题。注意fflush(NULL) 要在 fork 之前调用不要在 fork 之后只在一个进程里调用。只刷新一个进程另一个进程手里的残留还是在的。4.2 改变缓冲模式setvbuf 或 stdbuf如果程序里大量使用 printf又不愿意到处加 fflush可以在程序启动时把 stdout 设为无缓冲或行缓冲setvbuf(stdout, NULL, _IONBF, 0);或者行缓冲setvbuf(stdout, NULL, _IOLBF, 0);无缓冲最安全每次 printf 都直接 write缺点是性能差高频率日志场景下系统调用开销会非常明显。行缓冲能兼顾性能和实时性但前提是遇到换行符合你的输出节奏。如果不方便改代码可以用系统自带的 stdbuf 命令临时验证stdbuf -o0 ./a.out out.txt stdbuf -oL ./a.out out.txt-o0表示 stdout 无缓冲-oL表示行缓冲。注意 stdbuf 依赖动态链接和 LD_PRELOAD 机制静态编译的程序不一定有效但作为排查工具非常好用。4.3 子进程 exec 后通常不用太担心缓冲区如果子进程 fork 之后立刻 exec 执行新程序exec 成功时用户态地址空间会被新程序替换旧缓冲区数据直接丢弃不会产生重复输出。但 exec 之前如果子进程还调用了任何 stdio 函数或者 exec 本身失败了情况又回到原点。稳妥的做法依然是fork 前 fflush然后子进程 execexec 失败时用_exit而不是exit离开避免把残留缓冲再写一遍。4.4 日志场景下的正解让子进程使用自己的输出通道生产环境的日志系统一般不建议直接沿用父进程的 FILE 对象。更常见的做法是 fork 之后子进程重新打开日志文件、单独创建自己的日志 fd或者把日志交给独立的日志线程/进程处理。这样做的原因不只是缓冲区重复还有文件偏移、锁状态、日志轮转等一系列问题。父子进程共享同一个打开文件描述和偏移写日志时可能出现互相交错、覆盖日志边界、锁竞争等问题。与其事后补丁不如让每个进程拥有自己独立的输出通道。5. 多线程和 fork 碰到一起麻烦更大5.1 fork 只复制当前线程多线程程序里调用 fork子进程里只保留调用 fork 的那个线程其他线程全部消失。这本身就很危险如果消失的线程当时正持有某个锁子进程里的对应锁可能永远处于锁定状态。stdio 内部是有锁的glibc 为了保证多线程下 printf 不交错会在每次输出时对 FILE 结构体加锁。如果 fork 发生时另一个线程刚好正在 printf锁被该线程持有。fork 之后这个锁在子进程里被复制成了已持有状态但持有锁的线程已经不存在了。子进程里再调用 printf就会卡在抢锁上。5.2 用 pthread_atfork 解决锁状态不一致POSIX 提供了pthread_atfork机制可以注册三个回调prepare、parent、child。典型做法是在 prepare 里把所有相关锁锁上确保 fork 发生时没有其他线程在操作这些资源parent 和 child 回调里再分别解锁或重新初始化锁。static void prepare(void) { flockfile(stdout); } static void parent(void) { funlockfile(stdout); } static void child(void) { funlockfile(stdout); } pthread_atfork(prepare, parent, child);这只是其中一个方向。真实的服务里还需要考虑日志库自己的锁、内存分配器的锁等等。很多复杂的日志库内部已经实现了 atfork 处理但你自己手写的简易日志模块不会。5.3 多线程 缓冲区重复的叠加效果即使绕开了死锁多线程程序里父进程的 stdout 缓冲区里可能堆积了多个线程的输出。fork 时这些数据被完整复制给子进程子进程退出再刷新一遍重复的内容可能是一整段混合日志排查起来更头疼。所以多线程服务里我通常建议一条铁律不要在持有 stdio 锁或其他库锁的情况下 fork如果必须 fork先让所有线程停到安全点再处理输出缓冲。6. 常见问题与排查技巧实录6.1 快速判断是不是缓冲区问题遇到重复输出先用这几条做个初步判断只在重定向到文件、管道、容器日志驱动时出现终端直接运行正常大概率是缓冲模式切换造成的。重复的内容和源字符串逐字节一致连换行位置都一样而不是被截断或交错。在关键 printf 后手动加fflush(stdout)重复消失。用strace -f -e write ./a.out观察能看到两个进程各自调用了一次 write写入内容相同缓冲区问题的可能性就非常大了。这几条都命中基本可以把注意力集中到 fork 和缓冲区的组合上。6.2 printf 调试代码提交前要做一次扫描很多人调试时临时加 printf问题修完直接提交。如果这些 printf 出现在 fork 函数之前线上日志就可能出现莫名其妙的重复。我的习惯是提交前全局搜一遍printf凡是和 fork、exec、daemon、子进程相关的输出要么删掉要么改成正式日志接口。调试用的输出太随意很容易在生产环境留下隐患。6.3 使用日志采集的容器里尤其要注意容器环境里进程的 stdout 往往被容器运行时接成一个管道或 socket不是 tty。这就意味着即使代码在本地终端跑得好好的一旦进入容器stdout 就变成全缓冲。很多服务从裸机迁移到容器后突然出现日志延迟、日志重复根因往往在这里。建议容器里的服务进程stdout/stderr 要么显式重定向到日志文件并配合 fflush要么设置行缓冲要么直接使用不支持 stdio 缓冲的日志库。6.4 用环境变量和 stdbuf 快速验证别当成长期方案stdbuf 是排查利器但它本质是 LD_PRELOAD 注入的对静态链接、部分加固环境可能失效。它改变的是整个程序的缓冲策略一些依赖原始缓冲行为的库可能会表现异常。长期方案还是在代码里明确控制缓冲和刷新时机而不是靠外部工具兜底。6.5 遇到间隔性重复输出考虑数据量超过缓冲区的情况如果 printf 输出的数据量很大超过缓冲区大小那么在 fork 之前一部分数据已经通过 write 刷出去了只有最后没凑满的一段残留会被复制。这时候看到的现象可能不是严格重复而是某一段日志出现两次前面大部分日志只有一份。这种部分重复更容易让人误判成逻辑问题。排查时可以把输出数据量缩小或者把 stdout 改成无缓冲再对比结果。7. 最后再给你一个可直接抄的检查清单把这次踩坑的经验整理成清单遇到输出类问题照着过一遍fork 之前所有 stdio 流是否还有未刷新数据不确定就调用fflush(NULL)。子进程退出路径是否正确不需要刷新父进程残留时用_exit需要输出子进程自己的数据时先fflush再exit。stdout 到底连接的是 tty 还是管道/文件不要依赖\n触发刷新。程序里有没有多线程在调用 fork如果有检查锁状态考虑pthread_atfork。日志类输出是否通过独立日志通道完成而不是父子进程共享同一个 FILE*容器场景下stdout 是否被日志驱动改成了全缓冲我在实际项目里还养成了一条比较笨但有效的规矩任何在 fork 之前产生的输出都必须明确语义。要么它是正式日志走日志库并主动刷新要么它只是调试残留直接删掉。绝不允许顺手打一行的模糊状态存在因为缓冲区会在你最想不通的时候把一行输出变成两行再把两小时排查时间变成一下午。最后再补一个小技巧如果你用的是 Bash可以临时用script -c ./a.out /dev/null来模拟 tty 环境对比管道/文件环境下的输出差异几秒钟就能确认缓冲模式是否在作祟。这个地方踩过几次坑之后你再看 fork 相关的代码第一反应就会变成先看看它前面有没有 printf。 
长河君 · 2026/10/22 21:48:50 · 阅读 1.2k fork 后日志重复输出？问题出在 stdio 缓冲区
前阵子在排查一个服务端问题现象特别诡异日志里同一行内容总会成对出现内容一模一样连时间戳附近的字段都完全一致。第一反应是逻辑里出现了重复调用可翻遍代码也没找到可疑路径。后来才发现问题出在 stdio 的输出缓冲区与 fork 的组合上。这类坑在 C/C 服务端开发里太常见了尤其是用 printf 做调试、再搭配 fork 派生子进程的时候。你可能已经听过fork 会复制进程地址空间这句话但很少会意识到复制地址空间的同时也复制了还没写出去的 stdio 缓冲区。这篇文章就把这个知识点拆开讲清楚从缓冲机制、真实复现、到修复方案和排查技巧一次说透。适合写 C/C 服务、做后台任务、或者被重复日志困扰的开发者。1. 先搞清楚 stdio 输出缓冲区到底怎么工作1.1 三种缓冲模式与默认行为C 标准库里的文件流默认都有用户态缓冲区一共有三种模式模式宏定义触发刷新条件典型场景全缓冲_IOFBF缓冲区写满、显式 fflush、正常退出刷新stdout 指向文件或管道行缓冲_IOLBF遇到换行符、显式 fflush、正常退出刷新stdout 指向交互终端无缓冲_IONBF每次输出都直接写stderr 默认就是这种这里有个容易忽略的点stdout 默认用哪种模式取决于它连接的是什么设备。如果 stdout 连接的是终端glibc 会把它设成行缓冲如果 stdout 被重定向到普通文件、管道、socket就会变成全缓冲。很多服务进程在容器里运行stdout 被日志采集进程用管道读走这时候你以为每一行日志都实时落盘了实际上数据全堆在用户态缓冲区里攒够了才写一次。1.2 缓冲区存在的意义减少系统调用没有缓冲区的话每次printf(...)都要调用一次write系统调用。系统调用意味着用户态切换到内核态、参数检查、数据拷贝成本不低。高频打印的场景下一次一次 write 会把性能拖垮。缓冲区做的事情就是攒批printf 先把数据写到进程内存里的一段区域等区域满了、或者遇到换行行缓冲、或者程序主动刷新再一次性调用 write 把整段数据交给内核。你可以把它理解成快递柜一件一件单独跑腿送太慢先堆在柜子里凑够一批再统一发货。性能上去了代价就是输出时机变得不直观。你以为打印了其实数据还躺在内存里根本没进内核更没到磁盘或管道对端。1.3 printf 加 \n 并不是可靠的刷新信号很多人习惯用printf(hello\n)以为加了换行就万事大吉。这个想法只在 stdout 连接终端的时候成立因为终端场景是行缓冲换行确实会触发刷新。但一旦 stdout 变成全缓冲比如你在命令行执行./app log.txt换行符只是数据里的一个普通字节缓冲区不会因此刷新。等 fork 之后这段带着换行的数据如果还留在缓冲区里问题就来了。记住换行刷新是行缓冲模式的特性不是 printf 的特性。判断依据永远是stdout 连接的是什么 fd。2. fork 之后为什么输出会重复2.1 fork 复制的不只是代码还有缓冲区fork 创建子进程时几乎复制了整个用户态地址空间包括所有 .data 段、.bss 段、堆、栈以及 glibc 在内存里维护的 FILE 结构体和里面的缓冲区。这句话要拆开理解FILE 结构体除了文件描述符、偏移、状态标志之外还有一个关键成员就是用户态缓冲区。这个缓冲区是通过 malloc 之类分配的本质上就是进程堆里的一块普通内存。fork 之后父进程和子进程各有一份内容完全相同的缓冲区。缓冲区里的数据是还没交给内核的数据。这些数据不属于文件描述符也不属于内核只是当前进程内存里的私有副本。所以 fork 不会帮你保留它们而是帮你复制了它们。2.2 最小复现 demo看下面这段代码#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(before fork\n); fork(); wait(NULL); return 0; }编译后直接运行./a.out输出一次before fork。但如果重定向到文件./a.out out.txt cat out.txt输出两次before fork。同样一份代码为什么结果不一样就是因为终端下行缓冲\n触发刷新printf的数据在 fork 之前已经写进内核了fork 复制不到任何残留。而重定向到文件后 stdout 变成全缓冲before fork\n还留在用户态缓冲区里fork 把这个缓冲区复制成两份两个进程退出时各自刷新一次就变成了两行。2.3 不是数据被切分而是同一份数据被写了两遍要特别注意重复输出不是父进程输出一半、子进程输出一半而是两个进程各自持有一份完整的、一模一样的残留数据退出时各自调用 write把同一段内容写了两遍。这里还涉及一个底层细节fork 之后父子进程共享同一个打开文件描述意味着它们共享同一个文件偏移。父进程先退出write 把数据写到偏移 N 处偏移前进到 Nlen。子进程后退出它写的数据会从当前偏移继续写所以不会覆盖父进程写的内容而是紧跟在后面追加一遍。结果就是你看到的两行连续相同内容。如果父子进程各自重新 open 了同一路径的文件那文件偏移是独立的还可能互相覆盖。但最常见的共享 stdout 重定向文件场景偏移是共享的所以现象就是追加重复。2.4 你以为的 fork 执行了两次其实是缓冲区很多刚踩坑的人会误判成fork 没起作用还是 fork 被调用了两次。区分办法很简单在 fork 之后打印当前进程的 PID比如#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(before fork\n); pid_t pid fork(); printf(after fork, pid %d\n, getpid()); if (pid 0) { wait(NULL); } return 0; }如果看到的是两行before fork但after fork各自带有不同的 PID那就说明 fork 只调用了一次重复的是缓冲区。如果after fork也出现了两遍且 PID 不同那说明 fork 后的代码在两个进程里各自执行了一次这是正常现象不是重复。3. exit 和 _exit 的差异决定了重复是否发生3.1 exit 会刷新缓冲区_exit 不会这是和缓冲区重复强相关的第二个关键点main 里的 return 0最终会调用 exit 系列函数它会刷新所有 stdio 流。所以父进程和子进程正常退出时都会把继承来的缓冲数据写出去。如果你想在子进程里避免刷新父进程留下来的缓冲可以用_exit()或_Exit()。它们直接进入内核终止进程不经过 glibc 的清理步骤不会刷新 stdio 缓冲区。#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(before fork\n); pid_t pid fork(); if (pid 0) { wait(NULL); return 0; } _exit(0); }这样重定向到文件时子进程不会把父进程残留的缓冲区再写一遍输出就只有父进程那一次。3.2 但 _exit 也会丢掉子进程自己的输出_Exit 不是万能的。如果子进程 fork 之后自己又 printf 了内容直接 _exit 会导致这些新输出全部丢失因为它们也停留在用户态缓冲区里。pid_t pid fork(); if (pid 0) { printf(child output\n); _exit(0); // 这行可能不会出现在文件里 }如果你确实需要子进程输出正确的做法是在子进程里先fflush(NULL)再退出或者使用exit(0)。用exit(0)的话子进程自己的输出会被刷新但父进程残留的缓冲也会被一起刷新又会出现重复。所以核心不是用 exit 还是 _exit而是fork 之前必须保证缓冲区是空的。3.3 父子进程谁先退出会影响结果但不能避免重复有人会想让父进程 wait 一下等子进程先退出是不是就只输出一次了不会。wait 只改变执行顺序不会清空两个进程各自手里的缓冲区副本。子进程退出时它手里的那份残留数据照样会写出去哪怕父进程还没退出重复依然存在。只有一种情况可以绕开fork 之前或者 fork 之后立即把缓冲区清空让任何进程手里都没有残留数据可写。4. 修复方案从应急到根治4.1 最直接的方法fork 前执行 fflush(NULL)fflush(NULL)一次刷新所有打开的 stdio 流。这是最符合直觉、也是最稳妥的做法printf(some log\n); fflush(NULL); pid_t pid fork();这样 fork 发生时用户态缓冲区是空的子进程继承到的也是一份空缓冲区。之后父子进程各自产生的输出各自负责刷新不会出现复制残留的问题。注意fflush(NULL) 要在 fork 之前调用不要在 fork 之后只在一个进程里调用。只刷新一个进程另一个进程手里的残留还是在的。4.2 改变缓冲模式setvbuf 或 stdbuf如果程序里大量使用 printf又不愿意到处加 fflush可以在程序启动时把 stdout 设为无缓冲或行缓冲setvbuf(stdout, NULL, _IONBF, 0);或者行缓冲setvbuf(stdout, NULL, _IOLBF, 0);无缓冲最安全每次 printf 都直接 write缺点是性能差高频率日志场景下系统调用开销会非常明显。行缓冲能兼顾性能和实时性但前提是遇到换行符合你的输出节奏。如果不方便改代码可以用系统自带的 stdbuf 命令临时验证stdbuf -o0 ./a.out out.txt stdbuf -oL ./a.out out.txt-o0表示 stdout 无缓冲-oL表示行缓冲。注意 stdbuf 依赖动态链接和 LD_PRELOAD 机制静态编译的程序不一定有效但作为排查工具非常好用。4.3 子进程 exec 后通常不用太担心缓冲区如果子进程 fork 之后立刻 exec 执行新程序exec 成功时用户态地址空间会被新程序替换旧缓冲区数据直接丢弃不会产生重复输出。但 exec 之前如果子进程还调用了任何 stdio 函数或者 exec 本身失败了情况又回到原点。稳妥的做法依然是fork 前 fflush然后子进程 execexec 失败时用_exit而不是exit离开避免把残留缓冲再写一遍。4.4 日志场景下的正解让子进程使用自己的输出通道生产环境的日志系统一般不建议直接沿用父进程的 FILE 对象。更常见的做法是 fork 之后子进程重新打开日志文件、单独创建自己的日志 fd或者把日志交给独立的日志线程/进程处理。这样做的原因不只是缓冲区重复还有文件偏移、锁状态、日志轮转等一系列问题。父子进程共享同一个打开文件描述和偏移写日志时可能出现互相交错、覆盖日志边界、锁竞争等问题。与其事后补丁不如让每个进程拥有自己独立的输出通道。5. 多线程和 fork 碰到一起麻烦更大5.1 fork 只复制当前线程多线程程序里调用 fork子进程里只保留调用 fork 的那个线程其他线程全部消失。这本身就很危险如果消失的线程当时正持有某个锁子进程里的对应锁可能永远处于锁定状态。stdio 内部是有锁的glibc 为了保证多线程下 printf 不交错会在每次输出时对 FILE 结构体加锁。如果 fork 发生时另一个线程刚好正在 printf锁被该线程持有。fork 之后这个锁在子进程里被复制成了已持有状态但持有锁的线程已经不存在了。子进程里再调用 printf就会卡在抢锁上。5.2 用 pthread_atfork 解决锁状态不一致POSIX 提供了pthread_atfork机制可以注册三个回调prepare、parent、child。典型做法是在 prepare 里把所有相关锁锁上确保 fork 发生时没有其他线程在操作这些资源parent 和 child 回调里再分别解锁或重新初始化锁。static void prepare(void) { flockfile(stdout); } static void parent(void) { funlockfile(stdout); } static void child(void) { funlockfile(stdout); } pthread_atfork(prepare, parent, child);这只是其中一个方向。真实的服务里还需要考虑日志库自己的锁、内存分配器的锁等等。很多复杂的日志库内部已经实现了 atfork 处理但你自己手写的简易日志模块不会。5.3 多线程 缓冲区重复的叠加效果即使绕开了死锁多线程程序里父进程的 stdout 缓冲区里可能堆积了多个线程的输出。fork 时这些数据被完整复制给子进程子进程退出再刷新一遍重复的内容可能是一整段混合日志排查起来更头疼。所以多线程服务里我通常建议一条铁律不要在持有 stdio 锁或其他库锁的情况下 fork如果必须 fork先让所有线程停到安全点再处理输出缓冲。6. 常见问题与排查技巧实录6.1 快速判断是不是缓冲区问题遇到重复输出先用这几条做个初步判断只在重定向到文件、管道、容器日志驱动时出现终端直接运行正常大概率是缓冲模式切换造成的。重复的内容和源字符串逐字节一致连换行位置都一样而不是被截断或交错。在关键 printf 后手动加fflush(stdout)重复消失。用strace -f -e write ./a.out观察能看到两个进程各自调用了一次 write写入内容相同缓冲区问题的可能性就非常大了。这几条都命中基本可以把注意力集中到 fork 和缓冲区的组合上。6.2 printf 调试代码提交前要做一次扫描很多人调试时临时加 printf问题修完直接提交。如果这些 printf 出现在 fork 函数之前线上日志就可能出现莫名其妙的重复。我的习惯是提交前全局搜一遍printf凡是和 fork、exec、daemon、子进程相关的输出要么删掉要么改成正式日志接口。调试用的输出太随意很容易在生产环境留下隐患。6.3 使用日志采集的容器里尤其要注意容器环境里进程的 stdout 往往被容器运行时接成一个管道或 socket不是 tty。这就意味着即使代码在本地终端跑得好好的一旦进入容器stdout 就变成全缓冲。很多服务从裸机迁移到容器后突然出现日志延迟、日志重复根因往往在这里。建议容器里的服务进程stdout/stderr 要么显式重定向到日志文件并配合 fflush要么设置行缓冲要么直接使用不支持 stdio 缓冲的日志库。6.4 用环境变量和 stdbuf 快速验证别当成长期方案stdbuf 是排查利器但它本质是 LD_PRELOAD 注入的对静态链接、部分加固环境可能失效。它改变的是整个程序的缓冲策略一些依赖原始缓冲行为的库可能会表现异常。长期方案还是在代码里明确控制缓冲和刷新时机而不是靠外部工具兜底。6.5 遇到间隔性重复输出考虑数据量超过缓冲区的情况如果 printf 输出的数据量很大超过缓冲区大小那么在 fork 之前一部分数据已经通过 write 刷出去了只有最后没凑满的一段残留会被复制。这时候看到的现象可能不是严格重复而是某一段日志出现两次前面大部分日志只有一份。这种部分重复更容易让人误判成逻辑问题。排查时可以把输出数据量缩小或者把 stdout 改成无缓冲再对比结果。7. 最后再给你一个可直接抄的检查清单把这次踩坑的经验整理成清单遇到输出类问题照着过一遍fork 之前所有 stdio 流是否还有未刷新数据不确定就调用fflush(NULL)。子进程退出路径是否正确不需要刷新父进程残留时用_exit需要输出子进程自己的数据时先fflush再exit。stdout 到底连接的是 tty 还是管道/文件不要依赖\n触发刷新。程序里有没有多线程在调用 fork如果有检查锁状态考虑pthread_atfork。日志类输出是否通过独立日志通道完成而不是父子进程共享同一个 FILE*容器场景下stdout 是否被日志驱动改成了全缓冲我在实际项目里还养成了一条比较笨但有效的规矩任何在 fork 之前产生的输出都必须明确语义。要么它是正式日志走日志库并主动刷新要么它只是调试残留直接删掉。绝不允许顺手打一行的模糊状态存在因为缓冲区会在你最想不通的时候把一行输出变成两行再把两小时排查时间变成一下午。最后再补一个小技巧如果你用的是 Bash可以临时用script -c ./a.out /dev/null来模拟 tty 环境对比管道/文件环境下的输出差异几秒钟就能确认缓冲模式是否在作祟。这个地方踩过几次坑之后你再看 fork 相关的代码第一反应就会变成先看看它前面有没有 printf。