双缓冲通过两个vector和原子指针实现无锁写入，生产者零同步写入当前缓冲区，publish时原子交换读写指针；需注意内存对齐防伪共享、多生产者下publish需CAS保护，且非万能，依赖切换策略与内存控制。
双缓冲区本身不直接“减少写冲突”，它把写冲突转移到缓冲区切换那一刻，并用原子操作兜底——所以关键不是避免写，而是把写和读彻底隔开，让绝大多数时间互不干扰。
为什么 std::queue + mutex 在高并发日志场景下会卡住
多个线程同时调用 push() 时，std::queue 的每次插入都要抢同一把 std::mutex。锁争用随线程数指数级上升，尤其在日志高频打点（如每毫秒数百次）时，pthread_mutex_lock 成为性能瓶颈，top 里能看到大量线程阻塞在 futex_wait 上。
- 锁粒度太粗：整个队列共用一把锁，哪怕写入的是不同日志消息
- 写操作本身极快（只是拷贝指针或字符串视图），但锁持有时间被放大
- 消费者线程也得抢锁读取，进一步加剧竞争
双缓冲如何用两个 vector + 原子指针实现无锁写入
核心是让生产者只往一个缓冲区写，且全程不加锁；切换动作由原子指针交换完成，耗时纳秒级。
- 定义两个
std::vector<:string></:string>：buffer_a和buffer_b - 用
std::atomic<:vector>*> write_buffer</:vector>指向当前可写缓冲区 - 写线程调用
push_back()时，直接操作write_buffer.load()返回的指针，零同步开销 - 当缓冲区满或定时触发（如每 10ms），调用
publish()：用exchange()原子地把write_buffer和read_buffer互换
注意：publish() 不清空旧缓冲区，清空动作留给消费者线程在 consume() 中做，避免切换时长尾延迟。
立即学习“C++免费学习笔记（深入）”；
多生产者场景下必须加锁的唯一位置
如果多个线程都可能调用 publish()（比如每个线程自己判断缓冲区是否该提交），那么 publish() 内部必须用 CAS 循环，否则会丢数据或错乱。
- 错误写法：
write_buffer = read_buffer.load()—— 可能被其他线程覆盖 - 正确写法：用
compare_exchange_strong()确保原子性，失败则重试 - 更稳妥的做法是只允许单个线程（如主线程或定时器线程）执行
publish()，其他线程只负责push() - 若真需多线程 publish，建议改用环形缓冲区（ring buffer）+ 原子索引，比双缓冲更适配 MPMC
容易被忽略的内存对齐与伪共享问题
write_buffer 和 read_buffer 两个原子变量如果落在同一缓存行（64 字节），会导致 CPU 频繁无效化对方的缓存副本，性能反不如加锁。
- 必须用
alignas(64)分别对齐两个原子指针变量 - 缓冲区对象（
buffer_a/buffer_b）本身也要考虑对齐，避免与指针变量共享缓存行 - 实测中，未对齐时 32 核机器上吞吐量下降 30% 以上
双缓冲不是银弹——它用两倍内存换掉 95% 的锁开销，但切换时机、对齐、以及谁来负责 publish，这三个点没控好，反而比朴素队列更慢。
