C++高吞吐量日志写入优化：如何规避文件锁提升写入性能

未生效原因说明 #

你使用的fputs_unlocked、fflush_unlocked仅能规避glibc层面对FILE*流的用户态锁，你观测到的内核态文件锁是内核inode级别的页缓存写入锁，和用户态锁完全无关，因此更换接口不会有性能提升。

避免文件锁的可行方案 #

• 异步单线程写入：将日志写入逻辑收敛到唯一的独立线程执行，业务线程仅负责将格式化完成的日志内容推入无锁队列，写线程单独持有文件句柄执行写入、刷盘逻辑，全程无多线程资源竞争，可完全规避所有层面的文件锁，该方案性能收益最高，无锁队列的开销比文件锁低2~3个数量级。
• 按线程拆分日志文件：如果不想引入异步逻辑，直接为每个线程分配独立的日志文件，文件名增加线程ID后缀，每个线程仅操作自己专属的文件句柄，没有跨线程竞争自然不会触发内核锁冲突，后续可通过离线脚本合并多份日志归档。
• 直接使用系统调用写入：绕过glibc的FILE*流封装，直接用open系统调用加O_APPEND模式获取文件描述符，使用write写入日志，刷盘用fdatasync替代fsync（仅刷数据不刷文件元数据，速度更快）。单线程场景下该逻辑无需加任何锁，多线程场景下O_APPEND能保证单次write的原子性，但仍会有内核锁竞争，还是建议配合单线程写逻辑使用。

其他日志流程优化点 #

• 批量刷盘：如果业务允许最大10ms级的刷盘延迟，可将单条刷盘调整为攒够固定大小（推荐是磁盘页大小的整数倍，比如4KB/16KB）或者达到固定超时阈值再统一刷盘，能大幅降低刷盘调用次数，性能提升非常明显。如果业务强要求单条日志落盘，可在日志协议中增加批量确认机制，在不影响业务正确性的前提下做批量聚合。
• 前置格式化逻辑：所有日志的日期、级别、线程ID、参数拼接等格式化操作全部放在业务调用线程完成，写线程仅负责将完整的日志字符串写入磁盘，降低写线程的CPU占用，提升写入吞吐量。
• 预分配磁盘空间：创建新日志文件时，提前用fallocate预分配几百MB的磁盘空间，避免每次写入时触发磁盘块分配的元数据锁开销，也能减少磁盘碎片化。
• 直接IO绕过页缓存：如果日志写入量极大，内核页缓存的回写逻辑反而会带来额外的锁开销和内存占用，可以在open时增加O_DIRECT标志直接写入磁盘，注意直接IO要求写入的内存地址、大小、偏移量都对齐磁盘扇区大小（通常为512B或4KB），需要自行做内存对齐处理。
• 复用成熟日志库：不需要自行实现完整的日志逻辑，直接使用spdlog、glog等成熟高性能日志库，默认已经实现了异步写入、无锁队列、批量刷盘等优化，比自研实现的性能更高，稳定性也更好。

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