R中多进程并行调用fwrite写入文件是否必须使用锁？

仅用append=T不加锁的可行性前提 #

POSIX标准定义了O_APPEND模式下的写入原子性，但该特性仅在单次系统调用的写入内容大小不超过文件系统的原子写入阈值时生效：

• 多数Linux发行版默认阈值为4KB，部分高性能并行文件系统（如Lustre、BeeGFS）阈值可到64KB甚至1MB，具体阈值取决于你的集群环境配置
• data.table的fwrite会先将待写入数据序列化到内存缓冲区，再通过单次write系统调用写入磁盘；只要单次调用fwrite写入的总数据量低于上述阈值，写入过程就是原子的，不会出现多线程内容穿插的问题

你小规模测试未发现错误，是因为测试阶段单次写入量未超过阈值，且并发场景覆盖不全；但百万级仿真、3000线程并发的场景下，一旦出现单次写入量超过阈值的情况，写入错乱的概率会指数级上升，常见的不易察觉的问题包括：行内容截断/拼接、列数错位、特殊符号乱码，这类问题如果不做逐行校验几乎无法发现，会直接污染仿真结果。

性能瓶颈优化方案 #

不用在「单文件加锁等待」和「合并3000个小文件」之间二选一，可通过以下折中方案兼顾效率和正确性：

• 分组写入中间文件：将3000个线程分为20~50组，每组共享一个中间写入文件，组内加锁或者控制单次写入阈值，最终仅需合并几十份文件，耗时可忽略不计，同时完全避免锁冲突
• 控制写入粒度对齐阈值：先测试你所在集群的原子写入阈值，方法为开100个并发进程持续向同一文件append固定长度的字符串，连续跑100万次后检查是否存在损坏行，确定阈值后将fwrite的buffMB参数调整为略低于阈值，保证单次写入永远满足原子性要求，可完全不用加锁
• 替换锁实现：将flock的文件级全局锁替换为更轻量的字节范围锁，仅锁定你要写入的文件末尾区间，锁冲突概率会大幅降低

结论 #

如果可以严格控制单次fwrite的写入量低于集群文件系统的原子写入阈值，仅使用append=T无需加锁也能保证写入正确性；如果无法控制单次写入量，优先选择分组写入中间文件再合并的方案，性能远高于单文件加全局锁的实现。

内容的提问来源于stack exchange，提问作者Hans Jürgen