直接用 std::deque 不行，因其所有操作非原子、非线程安全，多线程下会触发数据竞争；真正可行的是基于 Michael-Scott 或 Vyukov 的无锁设计，依赖 std::atomic + 内存序 + 环形缓冲区 + 分离 head/tail 指针。
为什么直接用 std::deque 不行？
因为 std::deque 的所有操作（push_front、pop_back 等）都不是原子的，更不保证线程安全。多个生产者/消费者同时操作时，会触发数据竞争，导致崩溃或静默错误——哪怕加了互斥锁，也违背“无锁”前提。
真正可行的方案是基于 Michael-Scott 或 Dmitry Vyukov 的无锁 deque 设计，核心依赖 std::atomic + 内存序控制 + 循环缓冲区 + 分离的 head/tail 指针。主流实现如 boost::lockfree::deque（注意：它仅支持固定容量且非完全无锁）或自行实现的 ringbuffer + 双指针方案。
- 必须用
std::atomic<intptr_t></intptr_t>或std::atomic<size_t></size_t>存储索引，不能用普通整型 - 所有读写必须指定内存序：
memory_order_acquire（读）、memory_order_release（写）、memory_order_acq_rel（CAS） - 避免 ABA 问题：简单用
std::atomic自增索引不够，需配合 tag bits 或 hazard pointer（对 FIFO 场景，若只允许单生产者单消费者，可简化）
单生产者单消费者（SPSC）下最简可行实现
这是唯一能避开 ABA 和内存重排陷阱、又保持高性能的起点。此时无需 CAS，只需两个原子指针 + 缓冲区大小为 2 的幂（便于位运算取模）。
template<typename T, size_t CAPACITY>
class spsc_lockfree_deque {
static_assert((CAPACITY & (CAPACITY - 1)) == 0, "CAPACITY must be power of 2");
alignas(64) std::atomic<size_t> head_{0}; // producer index
alignas(64) std::atomic<size_t> tail_{0}; // consumer index
T buffer_[CAPACITY];
<p>public:
bool try_push<em>front(const T& item) {
auto h = head</em>.load(std::memory_order<em>relaxed);
auto t = tail</em>.load(std::memory_order<em>acquire);
if ((h - t) == CAPACITY) return false; // full
buffer</em>[h & (CAPACITY - 1)] = item;
head_.store(h + 1, std::memory_order_release);
return true;
}</p><pre class="brush:php;toolbar:false;">bool try_pop_back(T& out) {
auto t = tail_.load(std::memory_order_relaxed);
auto h = head_.load(std::memory_order_acquire);
if (t == h) return false; // empty
out = std::move(buffer_[t & (CAPACITY - 1)]);
tail_.store(t + 1, std::memory_order_release);
return true;
}};
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
注意：try_push_front 和 try_pop_back 是 FIFO 行为（头进尾出），若真要双端操作（如 push_front/pop_front + push_back/pop_back），必须升级为双指针+双缓冲或改用带版本号的 CAS —— 复杂度陡增，且多数任务队列其实只需要一端入、一端出。
多生产者多消费者（MPMC）时绕不开的坑
一旦允许多线程同时 push_front 和 push_back，就必须处理两个关键冲突：
- head 和 tail 指针的并发更新：必须用
compare_exchange_weak，且循环重试；失败后需重新 load 当前值，不能直接 ++ - 缓冲区边界检查变成竞态点：比如两个线程同时判断 “是否满”，都得到 false，然后都写入同一位置
- 内存伪共享（false sharing）：
head_和tail_若在同个 cache line，会严重拖慢性能 —— 必须用alignas(64)隔开
实际项目中，除非业务明确要求高吞吐双端插入/删除（如实时音视频帧调度），否则建议退一步：用单个无锁 ringbuffer + 任务类型字段（例如 enum class task_type { normal, urgent }），把“前端插入”逻辑移到业务层，避免在原子操作里做分支判断。
别忽略平台和编译器约束
无锁代码不是写完就能跑。x86 上 std::atomic 的 relaxed 序基本等价于普通读写，但 ARM/AArch64 默认不保证 store-store 重排，必须显式用 memory_order_release；Clang/GCC 对 atomic_thread_fence 的优化行为也有差异。
- 务必用
-march=native或至少-march=haswell编译，确保生成lock xadd等原语 - 禁止在无锁结构里存储 non-trivial 类型（如含虚函数、自定义析构的类）—— 移动构造必须是 trivial，否则
std::move可能触发锁或异常，破坏无锁假设 - 调试时禁用优化（
-O0）会导致内存序失效，测试必须用-O2 -DNDEBUG
真正稳定的无锁 deque 往往不是从零手写，而是基于 proven 实现（如 folly::DistributedMutex 配套的 folly::MPMCQueue 改造，或 moodycamel::ConcurrentQueue 的定制版）—— 自研只适合极特殊场景，且必须经过 ThreadSanitizer + libcds test suite 验证。
