多线程文件IO是否需要互斥锁？pthread随机写入基准测试疑问

嘿，这个问题我太熟了——你遇到的其实是标准IO（stdio）缓冲机制和多线程独立打开文件带来的经典坑，不是你代码其他部分的问题，当前场景下确实需要同步机制（比如mutex），或者换一种文件操作方式。

你每个线程都单独调用fopen(fileToWrite, "a+")，这意味着每个线程都拥有自己独立的FILE结构体和用户态缓冲区——这就是问题的根源：

• stdio的文件位置指针是用户态的：a+模式下，每个线程的FILE会维护自己的文件位置指针，这个指针和内核维护的实际文件位置是不同步的。比如线程A刚获取了当前文件末尾位置，准备往自己的缓冲里写数据；这时候线程B已经写完自己的缓冲并刷新到内核，文件实际大小已经变大了。等线程A再把缓冲里的数据刷到磁盘时，它会用自己之前记录的旧位置去写，直接覆盖掉线程B刚写入的内容，而被覆盖的大小刚好就是stdio缓冲区的块大小（也就是你看到的“丢失量是块大小整数倍”）。
• 内核的O_APPEND原子性帮不上忙：你可能以为a+对应内核的O_APPEND，但O_APPEND只保证系统调用write()是原子追加的。而stdio的写入是先写到用户缓冲，满了才调用write()，这个过程中用户态的位置指针已经和内核脱节了，所以原子性失效。

当你加上mutex后，同一时间只有一个线程能执行文件写入操作：线程会完整地完成“写入缓冲→刷新缓冲→更新文件位置”的流程，不会有其他线程中途修改内核的文件位置，所以每个线程的写入都能准确追加到文件末尾，不会出现覆盖丢失的情况。

如果有人说不需要mutex，大概率是指改用底层系统调用而非stdio的场景：

• 你可以让主线程用open(fileToWrite, O_WRONLY | O_CREAT | O_APPEND, 0644)打开文件，然后把文件描述符传给所有线程，线程直接调用write()写入。因为O_APPEND模式下，内核会保证每次write()都原子性地追加到文件末尾，不需要用户态的锁。
• 或者如果坚持用stdio，不要每个线程都fopen，而是主线程打开一次FILE*，传给所有线程，然后用mutex保护对这个共享FILE*的所有操作（包括fwrite、fflush等）——这样也能避免多个独立缓冲的冲突。

你的代码本身没有其他问题，当前的场景（多线程独立fopen同一文件做追加写入）确实需要mutex来保证写入的正确性。如果想去掉mutex，就得换用共享文件描述符+系统调用，或者共享FILE*（仍然需要锁保护，因为FILE结构体不是线程安全的）。

内容的提问来源于stack exchange，提问作者sapy