双缓冲区本身不提升IO吞吐量，真正起作用的是避免业务线程陷入write()等待、批量合并系统调用和绕过page cache干扰；需用三状态原子机（READY_TO_WRITE/SWITCHING/READY_TO_FLUSH）安全切换缓冲区，并配合posix_memalign对齐分配、mlock预映射、O_DIRECT打开文件及fdatasync+元数据文件+内存屏障保障崩溃一致性。
双缓冲区本身不提升 IO 吞吐量，真正起作用的是「避免业务线程陷入 write() 等待」+「批量合并系统调用」+「绕过 page cache 干扰」。盲目堆 buffer 大小或硬上 io_uring 反而容易丢日志、卡死或触发 EINVAL。
buffer 切换必须用三状态原子机，不能只靠 atomic
常见错误是用 std::atomic 标记“当前 buffer 是否可写”，结果生产者刚 memcpy 一半，消费者就原子置 true 并开始 read，读到未完成的 log entry。真实场景需要三个状态：
-
READY_TO_WRITE：业务线程可安全追加 -
SWITCHING：正在交换指针，禁止任何写入或读取 -
READY_TO_FLUSH：刷盘线程可安全只读消费，且该 buffer 内容已全部对齐写入（需std::atomic_thread_fence(std::memory_order_release)）
切换必须用 compare_exchange_weak 跳转，失败时业务线程应 fallback 到 thread_local char[4096] 临时缓存，而不是自旋等待——否则高负载下 CPU 占满，但吞吐不升反降。
write() 前必须预对齐 + 避免 page fault
即使用了双缓冲，write() 第一次访问某段内存仍可能触发缺页异常，尤其在大 buffer（如 16MB）场景下，延迟不可控。实操要点：
- buffer 内存必须用
posix_memalign(4096, size)分配，不能用new char[n]或std::vector - 分配后立即用
mlock()锁住物理页（若权限允许），或至少用memset(buf, 0, size)触发首次映射 - 打开日志文件时禁用
O_SYNC和O_DSYNC，它们会让每次write()等磁盘确认，彻底废掉双缓冲意义 - 刷盘线程调用
write()时，传入的buf指针必须是posix_memalign返回的原始地址，不能偏移（否则内核校验失败返回-EINVAL）
io_uring 提交前要重置 sqe，且必须检查 -EAGAIN 不重试
很多实现复用同一个 io_uring_sqe 结构体，只改 addr 和 len，但漏掉 user_data 和 flags 重置，导致 completion 回调乱序或丢失。关键约束：
- 每次提交前必须显式设置：
sqe->user_data = (uint64_t)buffer_id;，sqe->flags = IOSQE_ASYNC; - 提交返回
-EAGAIN时，绝不能立刻重试——ring buffer 已满，应把该 buffer 挂入 pending 队列，等下一轮io_uring_submit()成功后再推 - 文件必须用
O_DIRECT | O_WRONLY打开，O_APPEND与io_uring的IORING_OP_WRITE不兼容，会静默失败 - 内核版本低于 5.11 时，
IORING_SETUP_IOPOLL对普通文件无效，别指望它加速落盘
崩溃不丢日志的底线是 fsync + 元数据文件 + 内存屏障
仅靠 io_uring 提交成功 ≠ 日志已落盘。断电瞬间，数据可能还卡在控制器缓存或磁盘缓存里。保底手段只有三样同时生效：
- 每次刷完一块 buffer 后，必须调用
fdatasync()（比fsync()少 flush metadata，更快） - 维护一个独立的元数据文件（如
log.meta），每次fdatasync()成功后，原子更新其中的「最后 commit offset」 - 更新元数据前，插入
std::atomic_thread_fence(std::memory_order_seq_cst)，确保 buffer 数据写入顺序先于元数据更新
这三者缺一不可。少一个，重启后就可能看到日志文件末尾多出半条记录，或整个最后一块 buffer 彻底消失。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
