std::deque 本身不是线程安全的，多线程同时读写会引发数据竞争；必须用互斥锁（如 std::mutex）保护，或选用 boost::lockfree::deque 等无锁结构，但后者限制多、难度高。
std::deque 本身不是线程安全的，别直接裸用
几乎所有标准容器（包括 std::deque）都只保证「单线程内多次调用成员函数是安全的」，但不保证「多线程同时读写同一对象」。一旦两个线程分别调用 push_front() 和 pop_back()，就可能踩到数据竞争——没有定义行为，崩溃、丢数据、内存损坏都可能发生。
常见错误现象：Segmentation fault 在 deque::_M_check_len 或 __deque_buf_size 内部触发；调试时发现 size() 返回负值或极大值；Valgrind 报 Invalid read/write。
- 不要给多个线程共享一个未加锁的
std::deque实例 - 即使只读+只写分离（比如 A 线程只 push，B 线程只 pop），仍需同步：因为
push_front()和pop_back()都会修改内部指针和 size，底层缓冲区管理不是原子的 - std::deque 的迭代器失效规则复杂，竞态下迭代器可能指向已释放的 buffer，导致静默错误
用 std::mutex + std::deque 是最稳妥的起步方案
对绝大多数业务场景，封装一层互斥锁比手写无锁结构更可靠、更易维护。关键不是“快”，而是“正确”和“可验证”。
使用场景：吞吐量中等（比如每秒几千次操作）、延迟不极端敏感（微秒级不关键）、需要快速上线且后续可替换优化。
立即学习“C++免费学习笔记（深入）”；
- 把
std::mutex和std::deque封在一个类里，所有 public 方法都先 lock，操作完再 unlock - 避免在锁内做耗时操作（比如 I/O、长循环、调用用户回调），否则会卡住其他线程
- 用
std::lock_guard<:mutex></:mutex>自动管理，别手写 unlock —— 异常路径下容易漏掉 - 如果要支持超时弹出，用
std::timed_mutex和try_lock_for()，但注意std::deque::empty()也得在锁内判断，不能先检查再锁
class ThreadSafeDeque {
std::deque<int> data_;
mutable std::mutex mtx_;
public:
void push_front(int x) {
std::lock_guard<std::mutex> lk(mtx_);
data_.push_front(x);
}
bool try_pop_back(int& out) {
std::lock_guard<std::mutex> lk(mtx_);
if (data_.empty()) return false;
out = data_.back();
data_.pop_back();
return true;
}
};
无锁 deque（如 boost::lockfree::deque）性能高但限制极多
boost::lockfree::deque 是少数真正无锁的双端队列实现，但它不是 std::deque 的 drop-in 替代品。它的设计目标是确定性低延迟，代价是灵活性大幅降低。
参数差异和兼容性影响：
- 必须指定最大容量（编译期或运行期固定），超出则
push_*失败返回 false —— 无法动态扩容 - 元素类型必须是 trivially copyable，不能含虚函数、非平凡构造/析构函数
- 不提供
size()或empty()的精确值（只能近似或遍历计数），因为无锁下 size 统计本身就是竞态点 - 内存模型依赖
std::atomic的顺序约束，默认用memory_order_relaxed，某些场景需手动加强（比如生产者-消费者配对时用acquire/release） - Boost 版本需 ≥ 1.58，且开启 C++11 支持；Clang/GCC 对原子指令生成有差异，x86 上较稳，ARM 上需额外 fence
自研无锁 deque 极度危险，除非你已读过 Herlihy & Shavit
双端队列的无锁实现是公认的高危区域。它比无锁栈、无锁队列难得多，核心难点在于：两端都可增删，意味着 head/tail 指针都要原子更新，且中间节点的内存生命周期管理极易出错（ABA 问题、提前释放、悬空指针）。
容易踩的坑：
- 用
std::atomic<node></node>做头尾指针，但没处理好节点回收 ——hazard pointer或RCU不到位，导致读线程访问已释放内存 - 认为 CAS 成功就等于操作完成，忽略了中间状态（比如 push_front 正在修改 head 指针但 next 指针还没连好）
- 测试只跑单线程 or 两线程轻负载，上线后在 16 核机器上稳定复现 crash —— 无锁 bug 具有强硬件依赖性
- 没考虑内存序组合：
store用 relaxed，load用 acquire，但漏掉某处 release 语义，导致重排序破坏逻辑
真要动手，先确认是否真的被锁争用卡死（perf record -e cache-misses,cpu-cycles 看 mutex 争用率），再评估是否值得投入数月去验证一个可能只快 20% 的结构。多数时候，瓶颈根本不在 deque 本身。
