答案是锁粒度粗、临界区过长及消费者争抢导致性能骤降，应改用双缓冲+原子指针实现无锁写入，或 RingBuffer 配合严格内存序优化吞吐。
为什么 std::mutex 一加就拖慢整个服务
不是锁本身慢，而是日志写入（fwrite、fflush）和锁持有时间被绑死在一起。业务线程调用 log() 时，得等磁盘 I/O 完成才能释放 mtx_，期间所有其他日志线程全在 futex_wait 上挂起。实测在 32 核机器上，10 个线程并发打点，吞吐直接从 20 万次/秒跌到 3 万次/秒。
- 锁粒度太粗：一个
std::mutex护住整个文件句柄，哪怕两条日志写的是不同缓冲区，也得排队 - 临界区过长：把格式化（
vsnprintf）、写入（fwrite）、刷盘（fflush）全塞进锁里，放大阻塞时间 - 消费者也被卡：如果还有日志轮转或异步消费逻辑，它也得抢同一把锁读取队列
用双缓冲 + 原子指针实现无锁写入
核心是让生产者完全不碰锁：两个 std::vector<LogEntry> 轮流写，用 std::atomic<LogEntry**> 指向当前活动缓冲区。切换动作靠 exchange()，耗时纳秒级，且不阻塞任何线程。
- 写入路径零锁：每个线程只往当前缓冲区 push_back，只要没满就直接拷贝结构体（
LogEntry必须是 trivially copyable） - 切换时机由日志线程控制：当缓冲区快满或超时（如 1ms），就原子交换指针，把旧缓冲交给消费者处理
- 注意伪共享：两个缓冲区首地址间隔至少 128 字节，否则 CPU 缓存行冲突会让原子操作变慢
- 不能用
std::string成员：否则拷贝构造会触发堆分配，破坏无锁前提；改用固定长度字符数组或std::string_view
RingBuffer + memory_order_release/acquire 的三步入队
比双缓冲更省内存、吞吐更高，但要求容量是 2 的幂（如 4096），且必须用原子头尾指针配对内存序——否则消费者可能读到半写入的 LogEntry。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 检查是否满：必须用
tail.load(std::memory_order_acquire)，不能缓存旧值，否则多个生产者同时判“未满”会写崩同一槽位 - 填内容必须在
head.store(..., std::memory_order_release)之前完成，且禁止重排；推荐加std::atomic_thread_fence(std::memory_order_release) -
std::atomic<int>比std::atomic<size_t>更安全：避免无符号溢出后变成 0 导致静默 wraparound - 批量消费时，用
head.load(acquire)和tail.load(acquire)算出可用区间，一次性 memcpy 出来再处理，减少原子操作次数
什么时候还该保留锁，只是换种用法
并非所有场景都适合无锁。如果日志量不大（如每秒 async_logger），直接用封装好的异步模式更稳。
立即学习“C++免费学习笔记（深入）”；
- 用
std::scoped_lock替代嵌套std::lock_guard：避免死锁风险，尤其涉及多个资源（如文件句柄 + 轮转状态）时 - 锁内只做最简操作：格式化到栈缓冲区（
char buf[512]），然后把指针+长度丢进无锁队列，I/O 全部移出临界区 - 别忽略
fflush()：FILE* 默认行缓冲，不显式刷盘，进程崩溃时最后一段日志就丢了；但也不要每条都刷——折中方案是每 100 条或每 10ms 刷一次
真正难的不是选 RingBuffer 还是双缓冲，而是确定哪部分数据必须严格有序（比如错误堆栈）、哪部分可以接受微小乱序（比如调试日志），以及如何让日志线程的消费速度始终跑赢生产速度——后者一旦跟不上，缓冲区就会持续膨胀，最终 OOM。
