std::queue非线程安全，因push/pop引发内存重分配会导致未定义行为；无锁队列需原子操作+cas+内存序控制，如boost::lockfree::queue或手写spsc队列，须注意容量、内存对齐与伪共享。
为什么 std::queue 不能直接用于多线程环境
它不是线程安全的——哪怕只读操作，在底层迭代器遍历时也可能因另一线程调用 push 或 pop 导致内存重分配，引发未定义行为。标准库所有容器都默认不保证并发访问安全，这点和 Java 的 ConcurrentLinkedQueue 有本质区别。
常见错误现象：double free、segmentation fault、数据丢失或重复消费，且问题在压力测试前往往不暴露。
- 不要给
std::queue加全局互斥锁来“假装无锁”——这违背了无锁（lock-free）的设计目标，性能瓶颈仍在锁上 - 若只是读多写少，可考虑
std::shared_mutex配合std::queue，但这属于“有锁优化”，不算无锁队列 - 真正无锁队列必须依赖原子操作（
std::atomic）+ CAS（compare_exchange_weak）+ 内存序控制（如memory_order_acquire）
用 boost::lockfree::queue 快速落地的注意事项
Boost 提供了生产可用的无锁队列实现，比手写安全得多，但参数和行为容易踩坑。
使用场景：高吞吐日志缓冲、事件分发、跨线程任务投递等对延迟敏感的场合。
立即学习“C++免费学习笔记（深入）”；
- 必须指定固定容量：
boost::lockfree::queue<int> q(1024);</int>—— 它是环形缓冲，不支持动态扩容，越界时push返回false，不会抛异常 - 默认构造（无参）会创建无界队列，底层用
std::allocator动态分配节点，此时不是严格意义上的 lock-free（节点分配/释放仍需锁），要避免 - 注意内存序：它的
push/pop默认使用memory_order_seq_cst，在 ARM 或 RISC-V 上可能有额外开销；若业务允许，可通过模板参数定制
std::atomic 手写单生产者单消费者（SPSC）队列的关键点
这是最常被复现的无锁结构，适合嵌入式或极致性能场景，但仅限 SPSC 模式——多生产者或消费者会破坏原子性假设。
核心原理：两个 std::atomic_size_t 分别记录读写位置，通过 CAS + 取模实现循环写入，所有操作必须无分支、无内存分配。
- 数组大小必须是 2 的幂（如 1024），才能用位运算替代取模：
index & (capacity - 1)，否则 CAS 可能因溢出失败 - 读写索引必须用
std::memory_order_acquire和std::memory_order_release配对，否则编译器/CPU 可能重排指令导致读到旧值 - 禁止在队列元素类型中使用非 trivial 析构函数（如含
std::string成员），因为无锁逻辑无法安全调用析构；应存储指针或 POD 类型
无锁 ≠ 无等待，更不等于“自动高性能”
无锁队列解决的是“某个线程不因其他线程阻塞而停摆”，但不保证每个操作都快。实际性能受缓存一致性协议（如 MESI）、伪共享（false sharing）、CAS 自旋次数影响极大。
容易被忽略的地方：
- 读写索引变量若放在同一 cache line，会导致频繁的 cache line bouncing，性能可能比加锁还差——务必用
alignas(64)隔离关键原子变量 - 在低负载时，自旋等待（spin-wait）浪费 CPU；高负载时，CAS 冲突率上升，退化为忙等；需要结合
std::this_thread::yield()或指数退避 - 调试困难：GDB 很难抓到无锁逻辑中的竞态瞬间，建议用
ThreadSanitizer编译，并在 CI 中强制开启
