双缓冲区需用原子指针交换而非复制，4KB–64KB大小，生产消费完全解耦；刷盘线程累计写后fsync，超时降级；日志接口无锁无分配，禁止同步暴露内部状态。
双缓冲区怎么配才不卡主线程
核心是让日志写入和磁盘刷盘完全解耦：一个缓冲区收日志（生产），另一个交由后台线程刷盘（消费），二者绝不共享同一块内存。用 std::array<char></char> 或 std::vector<char></char> 做缓冲单元，大小建议 4KB–64KB —— 太小导致频繁切换，太大则内存占用高且单次 write() 延迟上升。
关键操作不是“复制”，而是“交换指针”：std::atomic<bool></bool> 标记当前活跃缓冲区，std::atomic_thread_fence(std::memory_order_acquire) 保证可见性。别用 std::swap 或 std::move 在锁里搬数据，那会把异步拖成同步。
- 避免在日志记录路径中做格式化字符串拼接（如
std::to_string、std::format），全挪到缓冲前完成 - 缓冲区切换时，若后台线程还没刷完上一块，就丢日志 or 阻塞？推荐丢（加
std::atomic<uint64_t></uint64_t>计数丢弃量供监控），阻塞等于把 IO 拖回主线程 - 别用
std::string当缓冲载体 —— 小字符串优化（SSO）在多线程下可能触发堆分配竞争
异步刷盘线程怎么避免 write() 阻塞住整个日志系统
write() 系统调用本身不阻塞，但底层文件描述符若开在普通 ext4 上、没设 O_DIRECT 或 O_SYNC，实际是写进 page cache —— 真正的阻塞发生在 fsync() 或内核回写压力大时。所以刷盘线程必须带超时控制 + 错误降级。
推荐组合：open(path, O_WRONLY | O_APPEND | O_CLOEXEC) 开文件，每次 write() 后不立刻 fsync()，改为累计 N 条或满 M 字节再 fsync()；若 fsync() 耗时 > 100ms，记录警告并跳过本次（下次合并刷）。
立即学习“C++免费学习笔记（深入）”；
- 绝对不要在刷盘线程里用
std::ofstream—— 它内部有 mutex 且 flush 行为不可控 - Linux 下可考虑
io_uring提交IORING_OP_WRITE+IORING_OP_FSYNC，但需内核 ≥ 5.1，且错误码处理比write/fsync复杂得多 - Windows 对应用
CreateFile+FILE_FLAG_NO_BUFFERING+WriteFile，注意对齐要求（buffer 和 offset 必须扇区对齐）
日志类如何安全暴露接口又不泄漏内部状态
用户调用的入口函数（如 log_info()）必须是无锁、无分配、无异常抛出的。所有参数应已序列化为 std::string_view 或 const char* + size_t，内部只做 memcpy 到当前缓冲区。
禁止提供「获取当前缓冲区内容」或「强制立即刷盘」这类破坏异步契约的接口。如果真需要同步刷（比如进程退出前），走单独的 flush_and_wait()，且该函数应自旋等待后台线程空闲，而非抢锁拷贝缓冲区。
-
log_info(const char* fmt, ...)这种 C 风格接口容易隐式调用vsnprintf导致栈溢出或性能抖动，优先用log_info(std::string_view) - 构造函数里不做
mmap()或预分配大内存 —— 那会让初始化变慢，且首次日志延迟不可控 - 析构函数里必须调用
flush_and_wait()，否则可能丢失最后几条日志
多线程写同一个日志实例会崩吗
会，除非你从头就没让多个线程直接调用同一对象的非 const 成员函数。正确做法是：日志类本身无内部锁，靠外部使用模式约束 —— 比如每个线程持有一个 Logger*（实际指向全局单例），但所有写操作最终都走同一个无锁环形缓冲区的生产端。
更稳妥的是用 thread_local 缓冲区 + 定期批量提交（类似 LMAX Disruptor 的 multi-producer 模式），但实现复杂度陡增。对于大多数服务，用一个原子索引控制双缓冲切换，配合 __builtin_expect 优化分支预测，已经能撑住 10w+ QPS 日志写入。
- 别给日志类加
std::mutex—— 锁粒度太粗，log_info()变成串行瓶颈 - gcc/clang 下用
__builtin_assume(buf_ptr != nullptr)帮助编译器消除空指针检查开销 - ASan/TSan 会误报双缓冲区的跨线程读写，需用
__tsan_acquire/__tsan_release显式标注同步点
真正难的从来不是“怎么写进去”，而是“怎么在磁盘卡顿、内存紧张、CPU 抢占剧烈时，依然让 log_info() 的延迟稳定在微秒级 —— 这取决于缓冲区大小、切换策略、刷盘节奏三者的联合调优，没有银弹，只有压测曲线里反复抠出来的那个平衡点。
