std::queue 本身不线程安全，多线程读写需加锁；应封装带 std::mutex 成员的线程安全队列类，所有操作加锁，empty() 必须加锁，推荐用 try_pop 和 condition_variable 实现阻塞式 pop。
std::queue 本身不线程安全，必须加锁
直接用 std::queue 在多线程里读写——比如一个线程 push、另一个线程 pop——会触发未定义行为。它内部没有同步机制，底层容器（如 std::deque）的迭代器失效、内存重分配等操作在并发下极易崩溃或读到脏数据。
常见错误现象包括：程序随机 crash、pop 返回垃圾值、empty() 和实际大小不一致、死锁（如果锁粒度没设计好）。
- 别试图靠“只读不写”或“生产者/消费者严格错开时间”来规避——编译器重排、CPU缓存不一致会让这种假设瞬间失效
- 锁对象必须和队列实例生命周期一致；不能用局部
std::mutex或静态锁保护多个不同队列 - 优先用
std::lock_guard自动管理，避免手动unlock()遗漏
封装一个带锁的 queue 模板类最稳妥
自己封装一层比每次调用都手写锁更安全、不易漏。关键点是把 std::mutex 作为成员变量，所有访问队列的操作都包裹在临界区内。
示例核心结构：
立即学习“C++免费学习笔记（深入）”；
template<typename T>
class ThreadSafeQueue {
private:
std::queue<T> q_;
mutable std::mutex mtx_;
public:
void push(const T& val) {
std::lock_guard<std::mutex> lock(mtx_);
q_.push(val);
}
bool try_pop(T& val) {
std::lock_guard<std::mutex> lock(mtx_);
if (q_.empty()) return false;
val = std::move(q_.front());
q_.pop();
return true;
}
bool empty() const {
std::lock_guard<std::mutex> lock(mtx_);
return q_.empty();
}
};
-
try_pop比直接pop更安全：避免空队列时抛异常或未定义行为 -
empty()必须加锁——否则返回true后另一线程立刻push，紧接着try_pop就会失败 - 不要提供
front()独立接口：它和pop()分离会导致典型的“检查后使用”（TOCTOU）竞态
用 std::condition_variable 实现阻塞式 pop
纯 try_pop 需要轮询，浪费 CPU。想让消费者线程在空时自动挂起、有数据时被唤醒，就得加 std::condition_variable。
关键改动点：
- 把
std::mutex和std::condition_variable一起用，wait必须传入已锁定的std::unique_lock -
notify_one()放在push末尾（有新数据就通知一个等待者），notify_all()仅在需唤醒全部消费者时用（比如关闭信号） - wait 的 lambda 条件必须是
!q_.empty()，不能只靠notify——因为存在虚假唤醒
阻塞 pop 示例：
void wait_and_pop(T& val) {
std::unique_lock<std::mutex> lock(mtx_);
cond_.wait(lock, [this]{ return !q_.empty(); });
val = std::move(q_.front());
q_.pop();
}
注意 move 语义和异常安全
如果 T 的移动构造函数可能抛异常（比如自定义分配器失败），pop 过程中在 q_.pop() 之后才移动，就可能导致队列状态已变但值未取出——下次再 pop 会跳过这个元素。
- 稳妥做法：先
front()取引用，再pop()，最后移动赋值（确保移动失败不影响队列结构） - 或者用
std::optional<t></t>返回，避免输出参数 + 引用带来的生命周期混淆 - 如果
T不支持移动（只有拷贝），确认拷贝构造不会抛异常；否则考虑用std::shared_ptr<t></t>存储，把异常风险隔离在堆上
真正难的不是加锁，而是覆盖所有边界：空队列、满队列（如果有限容）、异常路径、销毁时还有线程在等、生产者突然停止……这些地方最容易被忽略。
