不能直接用 std::queue 做无锁生产者消费者，因其 push/pop/size 非原子且 std::atomic 不支持非平凡类型；需用 2 的幂容量循环缓冲区，配原子下标与位掩码实现线性安全。
为什么不能直接用 std::queue 做无锁生产者消费者
因为 std::queue 的所有操作（push、pop、size）都不是原子的，内部有内存分配、指针更新、状态判断等多步操作。即使你把 std::queue 包在 std::atomic 里，也毫无意义——std::atomic 不支持非平凡类型（non-trivial type），编译直接报错：error: use of deleted function 'std::atomic<:queue>>::atomic()'</:queue>。
真正的无锁（lock-free）要求：所有线程对共享数据的读写，仅通过原子操作（如 load、store、compare_exchange_weak）完成，且不依赖互斥量或条件变量。
- 必须用固定大小的循环缓冲区（circular buffer），避免运行时内存分配
- 生产者和消费者各自维护独立的原子下标：
std::atomic<size_t> m_produce_idx</size_t>和std::atomic<size_t> m_consume_idx</size_t> - 下标运算必须用模运算或位掩码（推荐后者，更快且编译器可优化为 AND）
- 缓冲区容量必须是 2 的幂（如 1024、4096），才能安全使用位掩码
如何用原子下标 + 位掩码实现线性安全的环形队列
核心思想：把下标看作无限递增的序列号，但只取低 N 位作为实际数组索引；用高位隐含“版本”或“绕圈次数”，从而区分“满”和“空”状态（避免单独用标志位或牺牲一个槽位）。
假设缓冲区长度 CAPACITY = 1024，则掩码 MASK = CAPACITY - 1（即 0x3FF）。所有索引访问统一用 idx & MASK。
立即学习“C++免费学习笔记（深入）”；
关键约束：
- 生产者只能在
(m_consume_idx.load(std::memory_order_acquire) + CAPACITY) > m_produce_idx.load(std::memory_order_acquire)时写入（即“未满”） - 消费者只能在
m_consume_idx.load(std::memory_order_acquire) 时读取（即“非空”） - 所有原子读写需配对合适的 memory order：生产者写元素后用
store(..., std::memory_order_release)更新下标；消费者读下标前用load(std::memory_order_acquire)
class LockFreeRingBuffer {
static constexpr size_t CAPACITY = 1024;
static constexpr size_t MASK = CAPACITY - 1;
std::array<int, CAPACITY> m_buffer;
std::atomic<size_t> m_produce_idx{0};
std::atomic<size_t> m_consume_idx{0};
<p>public:
bool try_push(int val) {
auto current_prod = m_produce_idx.load(std::memory_order_acquire);
auto current_cons = m_consume_idx.load(std::memory_order_acquire);
if (current_prod - current_cons >= CAPACITY) return false; // 已满</p><pre class='brush:php;toolbar:false;'> m_buffer[current_prod & MASK] = val;
m_produce_idx.store(current_prod + 1, std::memory_order_release);
return true;
}
bool try_pop(int& out) {
auto current_cons = m_consume_idx.load(std::memory_order_acquire);
auto current_prod = m_produce_idx.load(std::memory_order_acquire);
if (current_cons >= current_prod) return false; // 为空
out = m_buffer[current_cons & MASK];
m_consume_idx.store(current_cons + 1, std::memory_order_release);
return true;
}};
std::memory_order 选错会导致什么现象
最常见错误是全用 std::memory_order_relaxed：编译器和 CPU 可能重排指令，导致消费者读到“新下标、旧数据”或“旧下标、新数据”，结果就是读到未初始化值、重复读、甚至崩溃。
正确配对逻辑：
- 生产者：写数据 →
store(新下标, release)：确保数据写入对其他线程可见 - 消费者：
load(下标, acquire)→ 读数据：确保后续读数据一定看到之前被 release 写入的内容 - 不能用
acquire去读生产者下标后，再用relaxed去读消费者下标——这会破坏同步关系 -
compare_exchange_weak场景（如 CAS 更新下标）必须明确指定 success/fail memory order，通常 success 用acq_rel，fail 用relaxed
如果你在调试中发现偶发读到 0 或随机大数，大概率是 memory order 失配，而不是逻辑错误。
性能陷阱：缓存行伪共享（false sharing）怎么破
m_produce_idx 和 m_consume_idx 如果在内存中挨得太近（比如同属一个 64 字节缓存行），多核并发读写会触发缓存一致性协议频繁同步，性能断崖式下降——实测吞吐可能比加锁还差。
解决方法只有两个字：隔离。
- 用
alignas(64)强制每个原子变量独占缓存行 - 或者在它们之间插入填充字段（
char pad[64]），但不如 alignas 清晰可靠 - 别忘了
m_buffer本身也要对齐（尤其当它很大时），否则首尾元素也可能跨缓存行争抢
一个没对齐的无锁队列，跑得越快，伪共享越严重——这不是理论风险，是真实压测中反复验证过的瓶颈点。
