校招C++20并发系列08-安全生产多线程队列：并发容器替代STL实战

📺 配套视频：校招C++20并发系列08-安全生产多线程队列：并发容器替代STL实战

从互斥锁到无锁并发：TBB并发队列实战解析

在并行编程中，数据结构的抽象能力至关重要。我们期望像使用 std::vector 或 std::queue 这样简单的 STL 容器一样，直接在多线程环境中操作它们。然而，标准的 STL 容器并非为并发设计，当多个线程同时尝试修改（如 push_back）时，直接调用会导致未定义行为或数据竞争。

解决这一问题的传统方案是使用互斥锁（Mutex）进行保护，但这往往带来显著的性能开销。本期教程将对比"基于互斥锁保护的 STL 容器"与"原生支持并发的 TBB 容器"，深入探讨为何专用的并发容器能带来巨大的性能提升。

基线实现：互斥锁保护的 std::queue

首先，我们构建一个基准测试场景：总共向队列中添加 25 个元素，由 8 个不同的线程并发执行。为了均匀分配负载，每个线程负责处理一部分迭代任务。由于 std::queue 不具备线程安全性，我们必须引入 std::mutex 来确保写入操作的原子性。

以下是基线代码的核心逻辑：

cpp 复制代码

#include <iostream>
#include <thread>
#include <queue>
#include <mutex>
#include <random>
#include <vector>

// 全局共享队列和互斥锁
std::queue<int> q;
std::mutex mtx;

void worker_thread() {
    // 模拟生成随机数据项
    std::random_device rd;
    std::mt19937 gen(rd());
    std::uniform_int_distribution<> dis(1, 100);

    for (int i = 0; i < 25 / 8; ++i) { // 每个线程处理部分元素
        int value = dis(gen);
        
        // 关键步骤：获取锁以保护临界区
        std::lock_guard<std::mutex> lock(mtx);
        
        // 安全地将值推入非线程安全的 std::queue
        q.push(value);
    }
}

int main() {
    std::vector<std::jthread> threads;
    // 启动 8 个线程
    for (int i = 0; i < 8; ++i) {
        threads.emplace_back(worker_thread);
    }
    
    // 等待所有线程完成
    for (auto& t : threads) {
        t.join();
    }
    return 0;
}

在这个实现中，每次 push 操作都需要经历"申请锁 -> 执行插入 -> 释放锁"的过程。虽然逻辑正确，但在高并发场景下，大量线程竞争同一把锁会导致严重的上下文切换和等待时间，这就是所谓的"锁竞争瓶颈"。

易错点：切勿忘记在循环内部加锁，或者错误地在循环外部加锁导致整个函数串行化，这会彻底丧失多线程的优势。

进阶方案：TBB concurrent_queue

Intel Threading Building Blocks (TBB) 提供了专为并发设计的容器，其中 concurrent_queue 是一个典型的例子。它从底层数据结构上就考虑了多线程访问的需求，通常采用细粒度锁、无锁算法或分段机制来减少竞争。

我们将上述代码中的 std::queue 替换为 TBB 的 tbb::concurrent_queue，并移除所有的互斥锁相关代码：

cpp 复制代码

#include <tbb/concurrent_queue.h> // 引入 TBB 并发队列头文件
#include <thread>
#include <random>
#include <vector>

// 使用 TBB 提供的并发队列
tbb::concurrent_queue<int> tq;

void worker_thread_tbb() {
    std::random_device rd;
    std::mt19937 gen(rd());
    std::uniform_int_distribution<> dis(1, 100);

    for (int i = 0; i < 25 / 8; ++i) {
        int value = dis(gen);
        
        // 直接推送，无需任何锁保护
        // concurrent_queue 内部已处理线程同步
        tq.push(value);
    }
}

int main() {
    std::vector<std::jthread> threads;
    for (int i = 0; i < 8; ++i) {
        threads.emplace_back(worker_thread_tbb);
    }
    
    for (auto& t : threads) {
        t.join();
    }
    return 0;
}

这种写法不仅代码更简洁，消除了显式的锁管理负担，更重要的是，它利用了底层优化过的并发原语，避免了粗粒度锁带来的性能损耗。

性能对比与编译指南

为了验证性能差异，我们需要分别编译这两个版本。编译时需启用 C++20 标准（用于 std::jthread）以及 O3 优化级别。

对于基线版本，只需链接 pthread 库：

bash 复制代码

g++ -std=c++20 -O3 baseline.cpp -o baseline -lpthread

对于 TBB 版本，除了上述参数外，还必须链接 TBB 库：

bash 复制代码

g++ -std=c++20 -O3 tbb_example.cpp -o tbb_example -ltbb

在实际计时运行后，结果呈现出显著差异：

基线版本耗时 ：通常在 3.2 秒至 3.6 秒 之间。这是因为 8 个线程频繁竞争同一个 std::mutex，大部分时间花在等待锁而非实际计算上。
TBB 版本耗时 ：通常在 1.2 秒至 1.3 秒左右。相比基线版本，速度提升了近一倍甚至更多。

这种性能飞跃并非偶然。STL 容器的锁保护是粗粒度的，而 concurrent_queue 通过内部机制（如 CAS 操作或分段锁）实现了更高效的并发控制。当然，这并不意味着在所有应用中都能获得 50% 的提升，因为大多数业务逻辑受限于 I/O 或其他瓶颈，不会在紧密循环中进行海量元素的推送。但在 CPU 密集型且高频并发的场景中，选择正确的并发容器至关重要。

小结：不要试图用一把大锁包裹所有共享数据。当发现锁竞争成为性能瓶颈时，应考虑使用专门的并发数据结构。

速查表

特性	std::queue + Mutex	tbb::concurrent_queue
线程安全性	需手动加锁保护	原生支持多线程并发
性能表现	低（锁竞争激烈，耗时 ~3.4s）	高（细粒度/无锁优化，耗时 ~1.3s）
代码复杂度	高（需管理锁生命周期）	低（直接调用 push/pop）
适用场景	简单同步、低频修改	高频并发生产/消费模型
依赖库	仅标准库 (`<mutex>`)	需链接 TBB (`-ltbb`)