spsc无锁环形队列最适合异步日志缓冲区，因业务线程（生产者）与后台刷盘线程（消费者）构成典型单生产单消费模型，可消除锁开销、实现亚微秒级写入延迟。
直接用环形队列做异步日志缓冲区，核心是让业务线程“写得快、不等、不卡”，同时后台线程“读得稳、不丢、不乱”。它不是简单套个 ringbuffer 就行，而是要围绕日志场景做针对性设计。
选对环形缓冲类型：SPSC 无锁结构最实用
日志系统里，业务线程是生产者，后台刷盘线程是消费者——典型单生产者单消费者（SPSC）模型。这时候该用无锁环形缓冲（Lock-Free Ring Buffer），而不是带锁的通用队列。
- 避免互斥锁开销，写入延迟可压到亚微秒级（实测
- Rust 的 ringbuf 库、C++ 常用的 moodycamel::ConcurrentQueue（SPSC 模式）或自研原子指针版都适合
- 必须确保 head/tail 指针更新是原子操作，且编译器不重排关键内存访问（用 std::atomic_thread_fence 或 Ordering::Relaxed/Release/Acquire 控制）
双缓冲交换机制：解耦写入与消费，避免竞争
只有一块环形缓冲区，业务线程在写、后台线程在读，容易出现“边写边读”导致数据不一致。工业级做法是引入双缓冲（Double Buffering）：
- 前台缓冲区（Front Buffer）：专供业务线程快速 push，只做内存拷贝，不格式化、不落盘
- 后台缓冲区（Back Buffer）：由刷盘线程独占读取、格式化、写入文件或控制台
- 当前台缓冲区写满，或定时（如每 10ms）触发一次 swap —— 原子交换两块缓冲区的 ownership，前台变后台，后台清空复用
这样业务线程永远不等待 I/O，也不和后台线程争同一块内存区域。
容量与覆盖策略：按爆发量预设，但分级保关键日志
环形缓冲大小不能拍脑袋定。它得扛住“最坏情况下的日志风暴”，比如异常集中爆发时每秒 50 条 ERROR 日志，持续 2 秒，那就至少预留 100 条空间（再加冗余）。
- 缓冲区满时，不能简单 FIFO 覆盖——否则刚打的 FATAL 日志可能被下一条 DEBUG 覆盖掉
- 给日志打优先级标记：ERROR/FATAL 标为“不可覆盖”，DEBUG/INFO 允许被覆盖
- 后台线程消费时，也按优先级排序输出，确保高危信息优先落盘
配套细节决定真实延迟：内存池 + 批量刷盘 + 零拷贝
光有环形队列还不够，几个关键配套点直接影响端到端延迟：
- 预分配内存池：LogEntry 对象不走 new/delete，从固定池中取，避免堆分配抖动
- 批量刷盘：后台线程攒够 N 条（如 64 或 128）再调用 write()，减少系统调用次数
- 零拷贝传递：如果日志内容是字符串字面量或短生命周期栈变量，尽量用 string_view 或 memcpy 到缓冲区，避免额外字符串构造
- 文件滚动控制：用 size-based 滚动（如单文件 ≤ 100MB），配合 mmap 写入或 O_DIRECT，进一步降低内核路径延迟
