双缓冲队列需避免std::queue+mutex的高锁竞争，应采用预分配环形缓冲区与三状态原子机（READY_TO_WRITE→SWITCHING→READY_TO_FLUSH）实现无锁生产与异步刷盘。
双缓冲队列为什么不能直接用 std::queue + mutex
因为锁竞争会吃掉 70%+ 的吞吐——尤其在多线程高频打日志时，std::queue::push() 和 std::queue::pop() 都要抢同一把互斥量。更糟的是，生产者可能被消费者阻塞（比如磁盘卡顿），反过来拖垮业务线程。
真正可行的路径是：生产者只写入内存缓冲区（无锁），消费者独占线程异步刷盘；缓冲区本身必须支持原子切换，即“双缓冲”——一块供写，一块供刷，通过指针原子交换完成翻转。
- 别用
std::deque或std::vector做缓冲底层数组：它们的push_back()可能触发 reallocate，不是无锁安全的 - 必须用预分配的环形缓冲区（
std::array或裸char*+ 原子索引），大小固定、不扩容 - 切换缓冲区时，不能只交换指针，还要确保旧缓冲区里所有日志项已完整写入（需对齐到结构体边界，避免字节撕裂）
如何用 std::atomic 保证双缓冲安全翻转
核心是两个缓冲区指针 + 一个原子状态标识。常见错误是仅靠 std::atomic<t></t> 切换，却忽略“正在写入中”的语义——如果生产者刚写一半就翻转，消费者会读到脏数据。
推荐用三状态机：READY_TO_WRITE → SWITCHING → READY_TO_FLUSH，由 std::atomic<int></int> 控制，配合 compare_exchange_weak 实现状态跃迁。
立即学习“C++免费学习笔记（深入）”；
- 生产者写入前检查状态是否为
READY_TO_WRITE；若为SWITCHING，自旋等待或 fallback 到临时栈缓冲（防死锁） - 消费者确认当前缓冲区已满或超时后，先置
SWITCHING，再原子交换缓冲区指针，最后置READY_TO_FLUSH - 切忌用
std::atomic_flag模拟锁——它无法表达多状态，容易漏掉“刷盘中”这个关键中间态
落盘性能瓶颈往往卡在 write() 系统调用和 fsync()
即使缓冲区无锁，每次 write() 仍陷入内核，频繁小写（如每条日志 fsync() 更是毫秒级延迟，不能每条都调。
实操上必须分层控制：缓存合并 + 延迟刷盘 + 可选强制同步。
- 用
writev()批量提交多个日志项，减少系统调用次数；避免拼接字符串，直接把struct log_entry的二进制布局write()出去 -
fsync()只在缓冲区满、或空闲超 1s、或显式调用flush()时触发；绝不放在每条log()调用末尾 - 打开文件时务必加
O_APPEND | O_WRONLY | O_CREAT，但**禁用**O_SYNC和O_DSYNC——它们会让每次write()都等磁盘确认，彻底废掉双缓冲意义
std::string_view 日志参数带来的隐式拷贝陷阱
很多库对外暴露 log(std::string_view msg)，看起来零拷贝，但实际可能因生命周期问题被迫深拷贝：比如传入临时 std::to_string(x).c_str()，或 lambda 捕获的局部字符串。
真正的高性能日志必须接受“可延迟求值”的参数，而非立即持有内容。
- 不要在日志入口函数里做格式化，把
std::format或fmt::format_to推迟到消费者线程（需传递格式串 + 参数元信息） - 若坚持用
std::string_view，必须文档注明：“调用方须确保其指向内存在日志写入完成前有效”，否则只能内部 memcpy 到缓冲区——这又回到内存分配问题 - 更稳妥的做法是提供两套接口：
log_raw(const char*, size_t)（零拷贝，用于已序列化场景）和log_fmt(fmt::format_string, Args&&...)（带格式化，但格式化发生在消费者线程）
双缓冲的本质不是“快”，而是“解耦”。一旦开始在生产者线程做任何非原子操作（格式化、分配、锁、系统调用），就等于主动交出性能控制权。最易被忽略的点：缓冲区大小不是越大越好——超过 L3 缓存（通常 1–2MB）反而增加 cache miss，建议单缓冲设为 256KB～512KB。
