双缓冲落盘需满足“写不卡、切不丢、刷不抖”：禁用std::vector（防realloc导致指针失效），用固定内存（如std::array或posix_memalign对齐）；原子切换须配合内存栅栏、状态机与边界同步；flush优先writev()而非io_uring，禁用O_SYNC；主线程退出前须确保final fsync完成。
双缓冲落盘不是加两块内存就能提速，关键在「写不卡、切不丢、刷不抖」——只要 buffer 切换时发生 memcpy、用 std::vector 动态扩容、或在 write() 前没做 page cache 优化，性能反而比单缓冲还差。
为什么 std::vector 不能当双缓冲底层数组
它会在 push_back() 触发 reallocate，导致指针失效；而双缓冲依赖原子指针交换所有权，一旦 buffer 地址变了，后台线程可能还在读旧地址，直接越界或读到脏数据。
- 必须用固定大小的
std::array<char></char>或裸char*配posix_memalign(4096, size)（尤其用io_uring时，不对齐会返回-EINVAL） - 大小建议 64KB～128KB：太小（如 4KB）导致每秒切换上百次，原子操作开销反超收益；太大（如 1MB）则单次
write()可能阻塞几毫秒，拖慢 flush 线程响应 - 别在构造函数里 new[] + delete[]：异常抛出时易泄漏；用 RAII 封装（如自定义
AlignedBuffer类），析构走free()
std::atomic 交换 buffer 时怎么防撕裂
只交换指针不够——业务线程可能刚写一半就切走，消费者读到半截日志。必须配合写入边界同步和状态机。
- 写入前用
std::atomic_thread_fence(std::memory_order_release)，确保所有日志字节已写入当前 buffer - 切换前检查
used.load()是否 ≥ 容量阈值（如 90%），否则不触发翻转；满才调current_buf.exchange(next_buf) - 推荐三状态原子机：
std::atomic<int> state_{0}</int>（0=可写、1=切换中、2=待刷），用compare_exchange_weak跃迁，避免std::atomic_flag无法表达中间态的问题
flush 线程用 write() 还是 io_uring 提交
除非你已稳定运行 kernel 6.0+ 且线上有完整 io_uring 监控链路，否则优先用专用线程 + write() —— 它不引入 ring buffer 管理复杂度，strace -e write 一眼可见瓶颈，且 writev() 批量提交效果接近 io_uring。
立即学习“C++免费学习笔记（深入）”；
- 打开文件必须用
O_WRONLY | O_CREAT | O_APPEND，**禁用**O_SYNC和O_DSYNC（它们让每次write()等磁盘确认，双缓冲彻底失效） - 每轮 flush 先
writev()多个log_entry结构体（二进制直写，不拼字符串），再按需fsync()：满 buffer、空闲超 1s、或显式flush()调用时触发 - 若用
io_uring，sqe必须每次重置user_data和flags，失败时（如-EAGAIN）不能立即重试，得挂到 pending 队列等下一轮 submit
主线程退出时最后几条日志为什么总丢
不是 flush 线程没跑完，而是 join() 只等线程结束，不等日志落盘完成。消费者线程可能刚取走 buffer 正准备 write()，主线程就 join() 返回了。
- 加
std::atomic<bool> shutdown_requested{false}</bool>，主线程退出前设为true并cond_.notify_one() - 消费者循环里用
cv.wait_for(lock, 100ms, [&]{ return shutdown_requested || !buffers_.empty(); })，唤醒后先清空队列、再file.flush()、最后fsync() - 最关键的一步：主线程
join()前，必须确认消费者已完成最后一次fsync()—— 可加一个std::atomic<bool> flushed_final{false}</bool>，消费者末尾置 true，主线程 while(!flushed_final) std::this_thread::yield()
