不能直接用std::queue做日志缓冲区，因其底层deque易内存重分配且非无锁，加mutex会导致高并发下QPS降3–5倍；应采用原子游标控制的2的幂容量环形队列，配内存序、缓存行对齐与批写入优化。
为什么不能直接用 std::queue 做日志缓冲区
因为 std::queue 默认底层是 std::deque，每次 push/pop 都可能触发内存重分配或迭代器失效；更关键的是它不是无锁的——你得自己加 std::mutex，而锁在高并发日志场景下会成为性能瓶颈，实测 QPS 下降 3–5 倍。真正要压榨吞吐，必须绕过标准容器的通用性设计，用固定大小、预分配、原子索引控制的环形结构。
怎么用 std::atomic 实现无锁环形队列的核心逻辑
核心就两点：一个生产者原子游标 tail_，一个消费者原子游标 head_，两者都用 std::atomic，所有操作只做 fetch_add 和 load（不带锁的 read-modify-write）。注意必须用 memory_order_acquire/memory_order_release 配对，否则编译器/CPU 可能乱序导致读到未写完的日志条目。
关键细节：
- 队列容量必须是 2 的幂（比如 65536），这样可用位运算
index & (capacity - 1)替代取模，避免除法开销 -
tail_和head_的差值不能等于容量，所以实际可用槽位是capacity - 1，留一个空位用于判满 - 不要用
std::atomic标记“是否正在写入”，那反而引入伪共享；靠游标差值 + 内存序就足够判断状态
如何让日志落地线程安全地消费环形队列而不卡住主线程
后台线程不能死等 head_ == tail_，要用 std::this_thread::yield() 或短时 std::this_thread::sleep_for(1ns) 避免空转耗 CPU；但也不能睡太久，否则日志堆积。推荐用 std::atomic_flag 做轻量级唤醒信号——生产者在成功入队后置位 flag，消费者循环中检查 flag，为 true 就尝试消费，然后 clear。
落地时注意：
- 避免在消费循环里频繁调用
fwrite或std::ofstream::write，攒批写入（比如每 32 条或累计 ≥4KB） - 文件句柄必须在后台线程初始化并复用，不要每次写都 open/close —— 系统调用代价远高于内存拷贝
- 如果启用了日志滚动，轮转动作（rename + reopen）必须由后台线程独占执行，且要确保当前正在写的 buffer 已全部消费完毕（即
head_ == tail_）再切换
为什么 __builtin_expect 和缓存行对齐对性能影响这么大
环形队列的 head_ 和 tail_ 如果落在同一缓存行（通常是 64 字节），会产生 false sharing：两个线程分别改不同变量，却因 CPU 缓存一致性协议反复同步整行，吞吐直接腰斩。解决方法是用 alignas(64) 分别对齐这两个原子变量，并用 [[maybe_unused]] char pad[64]; 隔开。
另外，消费循环里判断 “是否有新数据” 是高频分支，用 if (__builtin_expect(tail_.load() != head_.load(), 0)) 显式告诉编译器「大概率没数据」，能让 CPU 分支预测器更准，实测在低负载时减少约 8% 的指令周期浪费。
真正的难点不在代码长度，而在验证——你得用 TSAN（ThreadSanitizer）跑压力测试，同时观察 cache miss rate 和 atomic 指令 retired 数，否则看似“无锁”，实则被硬件悄悄锁住了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
