双缓冲区不提升IO吞吐量，真正决定write()落盘速度的是系统调用频次、缓冲区对齐、page cache管理和fsync时机；需禁用O_SYNC，采用64KB定长缓冲区、writev()批量提交、三状态机控制切换，并确保LogEntry结构体二进制对齐。
双缓冲区本身不提升 IO 吞吐量，真正决定 write() 落盘速度的是系统调用频次、缓冲区对齐、page cache 管理和 fsync 时机——所有“快”都来自这四点控制，而非缓冲区数量。
为什么 std::atomic 交换缓冲区指针后仍会丢日志
常见错误是只交换指针，却没保证写入线程已完整提交当前 buffer 的最后一条日志。比如 append() 正在拷贝最后 12 字节时被切换，消费者线程拿到的 buffer 就含部分未完成的 struct 边界数据。
- 必须在切换前插入
std::atomic_thread_fence(std::memory_order_release)，确保所有 prior 写操作对消费者可见 - buffer 内部按定长
LogEntry结构体对齐（如 1040 字节），used记录的是已填满 entry 数，不是字节偏移；避免字节撕裂 - 切换逻辑不能只依赖原子指针，要配合三状态机：
READY_TO_WRITE→SWITCHING→READY_TO_FLUSH，用compare_exchange_weak跃迁，防止生产者在SWITCHING期间继续写
write() 性能卡点在哪？为什么 O_SYNC 必须禁用
O_SYNC 会让每次 write() 都等磁盘确认，彻底废掉双缓冲意义——实测单条日志 write() + O_SYNC 平均耗时 1.2ms，而批量 64KB write() 不带 sync 只需 8μs。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 文件必须以
O_APPEND | O_WRONLY | O_CREAT打开，**禁用O_SYNC和O_DSYNC** - 用
writev()替代多次write()：把多个LogEntry的iovec数组一次提交，减少上下文切换 - 刷盘线程调用
posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)主动丢弃 page cache，防 cache 污染影响后续业务读写 - 每累计 4KB 数据或空闲超 1s 触发一次
fsync()，别在每条日志后调
缓冲区大小设成多少才不拖慢主线程又不丢日志
64KB 是多数场景下的甜点值：太小（如 4KB）导致每 100 条日志就切一次，原子状态跃迁开销占比飙升；太大（如 4MB）则单次 write() 可能阻塞毫秒级，且内存占用不可控。
立即学习“C++免费学习笔记（深入）”；
- 推荐固定为
65536字节（64KB），用std::array<char></char>而非std::vector<char></char>—— 后者push_back()可能触发realloc，破坏无锁前提 - 若日志体普遍大于 1KB，可升到 128KB，但需同步调整
LogEntry结构体大小上限，防止单条写入就触发切换 - 永远不要让业务线程等待缓冲区空闲；
push()失败时直接 fallback 到fwrite()同步写（保底），而不是自旋或重试
最易被忽略的是：缓冲区内容必须是二进制结构体布局（如 ts + level + msg[1024]），而非拼接后的文本字符串——前者可直接 write() 零拷贝落盘，后者每次都要格式化+内存分配，吞吐直接打七折。
