多线程日志场景下追加模式多次fopen同一文件的跨平台行为问询

缓冲区归属 #

MacOS、FreeBSD、Linux三个平台的标准C库（glibc、FreeBSD libc、Darwin libSystem内置libc）实现中，每个FILE*指针都会持有独立的用户态缓冲区，行缓冲模式下该规则同样生效。即使打开的是同一个文件，不同FILE*对应的行缓冲区完全隔离，不存在共享逻辑。

数据风险说明 #

• 数据丢失风险：仅在进程异常终止（比如被SIGKILL信号杀死、调用abort强制终止）时，才可能出现未刷入内核的缓冲区数据丢失。正常流程下只要主动调用fclose，或者进程正常退出触发C库的自动刷缓逻辑，缓冲区数据都会写入内核，不会丢失。
• 内容交错风险：分两种场景判定：
  1. 单条日志长度小于行缓冲区大小，且每次写入都是以换行符结尾的完整行：该场景下三个平台都不会出现行内容交错。因为行缓冲模式下C库会在遇到换行符时自动调用write系统调用，而追加模式的write操作在内核态是原子的——只要单条写入的长度不超过PIPE_BUF（三个平台的PIPE_BUF最小值为512字节，常见默认值为4096字节），内核会保证整段数据一次性写入文件，不会和同文件的其他追加写操作穿插。
  2. 单条日志长度大于行缓冲区大小，或者单次写入没有以换行符结尾：该场景下会触发多次write调用，不同线程的写入内容大概率会出现交错，追加模式下不会出现数据覆盖，但会存在内容穿插混乱的问题。

优化建议 #

如果要完全规避内容交错风险，不建议给每个线程分配独立的FILE*，可以改为所有线程共用同一个FILE*，依赖C库对FILE*内置的线程锁保证写入原子性，也可以自行加锁控制写入流程。另外尽量控制单条日志长度小于PIPE_BUF，可以完全规避内核态的写入穿插问题。

内容的提问来源于stack exchange，提问作者Arran Cudbard-Bell