双缓冲消息队列需避免std::queue+mutex的高争用瓶颈，应采用原子三态切换、posix_memalign对齐分配、writev批量落盘及fdatasync精准刷盘。
双缓冲消息队列不是开两块 std::queue 加个 std::mutex 就能扛住高并发日志——实测在 16 核机器上，50k msg/s 就开始抖动，磁盘稍慢就会卡死业务线程。
为什么 std::queue + mutex 会拖垮吞吐
多线程高频写日志时，std::queue::push() 和 std::queue::pop() 共用同一把锁，不仅引发频繁上下文切换，还会导致 CPU 缓存行在多个核间反复无效化（false sharing）。更致命的是：消费者线程一旦被 fsync() 卡住，生产者就立刻阻塞，业务逻辑直接被拖挂。
- 别用
std::deque或std::vector做底层存储——push_back()可能触发realloc()，破坏无锁前提 - 禁用
boost::lockfree::queue的 MPMC 模式——内部原子 slot 争抢严重，伪共享比 mutex 还难压 - 若必须用 boost，只选
boost::lockfree::spsc_queue，但得前置聚合层：各线程先攒进thread_local std::vector，再批量转入
怎么用 std::atomic 实现安全无锁切换
仅靠 std::atomic<char></char> 交换指针是危险的：业务线程刚 memcpy 一半日志结构体，指针就被切走，消费者读到撕裂数据，解析崩溃或字段错位。
- 必须用
std::atomic<int></int>表达三态：0=READY_TO_WRITE、1=SWITCHING、2=READY_TO_FLUSH - 业务线程写入前检查
state_.load() == 0；若为1，最多自旋 100 次，之后 fallback 到thread_local char[4096] - 切换时先
compare_exchange_weak(state_, 0, 1)，成功后立即原子交换 buffer 指针，并插入std::atomic_thread_fence(std::memory_order_release) -
log_entry结构体必须alignas(8)或alignas(16)，避免跨 cache line 写入
writev() 批量落盘前的关键优化点
即使缓冲区无锁，write() 本身仍是瓶颈——缺页、调度抢占、page cache 污染都会放大延迟。重点不在“怎么快写”，而在“写什么”和“什么时候写”。
- 用
writev()批量提交，攒够 4–8KB 再落盘；单次write()写 32 字节，系统调用开销占比超 70% -
log_entry定义为二进制结构体（如struct LogEntry { uint64_t ts; uint8_t level; uint16_t len; char data[]; }），直接write()整块内存，跳过字符串拼接 - 打开文件时禁用
O_SYNC和O_DSYNC——它们会让每次write()等磁盘确认，双缓冲彻底失效 -
fdatasync()替代fsync()，只刷数据页不刷元数据，延迟低 30%～50%，且只在三种时机触发：buffer 满、空闲超 1s、显式flush()
posix_memalign 对齐分配与预映射物理页
用 new char[65536] 或 std::vector<char></char> 分配 buffer，首次 write() 可能触发缺页异常，延迟从微秒级跳到毫秒级，尤其在 4MB 大 buffer 场景下不可控。
- 必须调用
posix_memalign(&buf_a_, 4096, size_)，确保地址按 4KB 对齐 - 分配后立即
mlock(buf_a_, size_)锁定物理页（需CAP_IPC_LOCK权限）；失败则memset(buf_a_, 0, size_)强制首次映射 - 两块 buffer 生命周期一致，禁止任何
realloc、resize、reserve路径 -
write()传入的指针必须是posix_memalign返回的原始地址，偏移后内核返回-EINVAL
真正卡住性能的从来不是缓冲区数量，而是状态跃迁是否严格、内存是否对齐、系统调用是否批量、刷盘时机是否可控——任何一个环节松动，吞吐就掉一个数量级，还容易丢日志或段错误。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
