c++怎么实现线程安全的队列_c++ std::queue结合std::mutex封装【方法】

std::queue本身不是线程安全的,需手动加锁;应通过组合而非继承封装,并用mutex+condition_variable实现阻塞等待;底层容器选择影响性能与异常安全。

std::queue 本身不是线程安全的,必须手动加锁

标准库的 std::queue 只是容器适配器,底层默认用 std::deque,它不提供任何同步机制。多个线程同时调用 push()pop()(尤其是 front() + pop() 这种两步操作)会引发数据竞争,导致未定义行为——哪怕只是读写不同元素也不行,因为内部结构可能被并发修改。

封装时别直接继承 std::queue,用组合 + 私有成员更安全

继承 std::queue 会暴露其所有接口(包括不带锁的 size()empty()),容易误用;而且标准容器不是为多态设计的,没有虚析构函数。正确做法是把 std::queuestd::mutex 都作为私有成员:

template
class ThreadSafeQueue {
private:
    std::queue queue_;
    mutable std::mutex mutex_;

public:
    void push(const T& item) {
        std::lock_guard lock(mutex_);
        queue_.push(item);
    }

    bool try_pop(T& item) {
        std::lock_guard lock(mutex_);
        if (queue_.empty()) return false;
        item = std::move(queue_.front());
        queue_.pop();
        return true;
    }

    bool empty() const {
        std::lock_guard lock(mutex_);
        return queue_.empty();
    }
};
  • try_pop() 返回 bool 表示是否成功取出,避免在空队列上调用 front() 崩溃
  • mutable std::mutex 允许 const 成员函数(如 empty())也能加锁
  • 移动语义用 std::move(queue_.front()) 减少拷贝开销

注意 wait-and-pop 场景:用条件变量替代忙等

如果消费者线程希望“阻塞等待直到有数据”,不能靠循环调用 try_pop()(浪费 CPU)。必须引入 std::condition_variable

template
class BlockingQueue {
private:
    std::queue queue_;
    mutable std::mutex mutex_;
    std::condition_variable cond_;

public:
    void push(const T& item) {
        std::lock_guard lock(mutex_);
        queue_.push(item);
        cond_.notify_one(); // 通知一个等待中的消费者
    }

    T wait_and_pop() {
        std::unique_lock lock(mutex_);
        cond_.wait(lock, [this]{ return !queue_.empty(); });
        T item = std::move(queue_.front());
        queue_.pop();
        return item;
    }
};
  • cond_.wait() 自动释放锁并挂起线程,被唤醒后重新获取锁再继续执行
  • 必须用 std::unique_lock(而非 std::lock_guard),因为 wait() 需要临时释放锁
  • notify_one()notify_all() 更轻量,除非多个消费者需要同时响应同一事件

std::queue 的底层容器会影响性能和异常安全

std::queue 默认用 std::deque,但你可以指定其他容器(如 std::vectorstd::list):

  • std::vector 作底层容器时,push() 在满容量时可能触发重新分配,抛出 std::bad_alloc —— 这个异常会在持有锁期间发生,需确保析构函数不抛异常(std::mutex 的析构是 noexcept,但自定义逻辑要小心)
  • std::dequepush_back()pop_front() 平均常数时间,适合队列场景;std::list 虽然也支持,但缓存局部性差,通常更慢
  • 若元素类型构造/析构开销大,考虑用 std::queue<:unique_ptr>> 减少移动成本

真正难的不是加锁,而是想清楚哪些操作必须原子、哪些可以放宽(比如 size() 返回近似值)、以及如何让等待逻辑不被虚假唤醒或丢失通知打断——这些细节比语法更重要。