不能直接用std::queue做异步日志队列，因其非线程安全，多线程push/pop会触发数据竞争；即使单生产者单消费者，其内部迭代器和size()在并发下也不安全，且锁机制会成为高吞吐场景下的性能瓶颈。
为什么不能直接用 std::queue 做异步日志队列
多线程往 std::queue 里 push / pop 时必须加锁，否则会触发数据竞争——哪怕只用一个生产者、一个消费者，std::queue 的内部迭代器和 size() 行为在并发下也不安全。更关键的是，锁本身会成为日志路径上的性能瓶颈：每条日志都要进一次 mutex，高吞吐场景下容易卡住业务线程。
无锁队列的目标是让日志写入（producer）几乎不阻塞，消费（consumer）线程独立拉取、格式化、落盘。真正要解决的不是“有没有锁”，而是「内存可见性」「ABA 问题」「内存序约束」这三个底层问题。
实操建议：
- 别自己手写无锁队列——除非你已熟读《The Art of Multiprocessor Programming》第6章并做过 full fence 测试
- 优先选用经过验证的实现：
moodycamel::ConcurrentQueue（单生产/单消费极快，支持批量 pop）、boost::lockfree::queue（需注意其默认不支持动态扩容） - 避免用
std::shared_ptr<logentry></logentry>包裹日志内容：引用计数操作本身有原子开销，且可能触发堆分配 —— 改用固定大小的struct+ 内联缓冲（如char msg[512]）
如何用 moodycamel::ConcurrentQueue 构建日志收集器
moodycamel::ConcurrentQueue 是目前 C++ 生态中对单生产者/单消费者（SPSC）场景优化最彻底的无锁队列，它利用缓存行对齐、batched enqueue/dequeue、memory_order_relaxed 等手段把单次 push 控制在 10–20 个 cycle 内。
关键配置与使用要点：
- 队列容量必须在构造时指定（如
ConcurrentQueue<logentry></logentry>），运行时不可扩容；容量太小会导致enqueue返回 false，必须立刻处理丢日志或降级逻辑 - 不要在日志线程里调用
size()或peek()：它们不是 O(1)，且会引入额外内存屏障 - 用
try_dequeue_bulk批量消费比单条try_dequeue高 3–5 倍吞吐，尤其适合日志聚合写入文件 - 确保
LogEntry是 trivially copyable：禁用虚函数、非 POD 成员、自定义构造/析构；否则ConcurrentQueue的 memcpy 语义会出错
struct LogEntry {
uint64_t ts;
uint32_t level;
char msg[512];
// no constructor, no destructor, no vtable
};
日志线程如何避免被慢 IO 拖垮主循环
异步日志的核心陷阱不是“怎么发”，而是“发出去后怎么不被拖死”。如果消费线程在 fwrite 或 sync 时卡住 10ms，而生产端持续以 10w QPS 写入，队列很快填满，enqueue 开始失败。
应对策略：
- 消费线程不做格式化：只做 raw dump（如把
LogEntry直接 memcpy 到 mmap 文件页），格式化交给另一个后台线程或离线工具 - 设置硬水位（hard watermark）：当队列占用 > 80% 时，主动丢弃 DEBUG 级日志，或切换到 ring buffer 模式覆盖最老日志
- 用
O_NONBLOCK | O_APPEND打开日志文件，配合writev()批量写入，避免单条write()的 syscall 开销 - 慎用
fsync()：每条日志都 fsync 是性能杀手；可改用定时 flush（如每 100ms 调用一次）+ crash-safe 格式（如追加 length-prefix header）
哪些地方最容易导致无锁失效或崩溃
无锁 ≠ 无脑快。几个典型翻车点：
-
ConcurrentQueue的 producer/consumer 必须严格绑定到固定线程：不能在 A 线程 new queue，B 线程调用enqueue，C 线程调用try_dequeue—— 它依赖 thread-local 缓存指针，跨线程调用未定义行为 - LogEntry 中若含指针（如
const char* file），必须确保该内存生命周期长于日志消费完成时刻；推荐用编译期字符串字面量（"log.cpp"）或静态池管理 - 在信号处理函数（如 SIGSEGV handler）里调用
enqueue是危险的：部分无锁实现依赖 TLS 或 malloc，而信号上下文禁止调用多数 libc 函数 - 32 位系统上要注意
size_t和指针宽度不一致，某些 boost::lockfree 实现会在此类平台误判 capacity
真正难的从来不是把日志塞进队列，而是确保从 enqueue 返回那一刻起，所有字段的字节值对消费者线程 100% 可见，且不会被编译器或 CPU 重排打乱顺序——这需要你逐行核对每个原子操作的 memory order 参数，而不是抄一段代码就跑。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
