C++线程安全FIFO队列实现：从std::queue到生产级封装

做服务端后台时间长了，你会发现一个特别有意思的现象：不管业务多复杂，最后落到数据结构上，翻来覆去就是那几种。队列、栈、树、哈希表，再加个图，基本上能覆盖九成以上的需求。而这里面，FIFO（First In First Out，先进先出）队列又是存在感最强的一个——日志采集、任务调度、流量削峰、生产者消费者模型，几乎每个模块里都躺着至少一个FIFO。

但越是基础的东西，越容易被人轻视。很多人一提FIFO，第一反应就是“直接用std::queue不就行了”，真到了线上才发现，裸奔的std::queue在单线程下确实没毛病，一旦有多个线程往里塞数据、往外取数据，各种偶发崩溃、数据丢失、死锁问题全来了。所以我一直建议：项目里应该有一个统一的、经过充分测试的FIFO组件，而不是每个模块各写各的。今天我就把自己在实际项目里沉淀的一套C++ FIFO实现拿出来，从基础原理到线程安全版本，完整走一遍，源码可以直接抄，注释也尽量写清楚。

这篇文章适合谁看？我觉得分三类：一是刚接触C++、想搞清楚队列底层原理的入门者，代码能帮你把抽象概念落到具体实现上；二是写业务代码、希望找到一套可靠FIFO封装直接复用的开发者，线程安全版本基本能做到开箱即用；三是对并发编程感兴趣的进阶读者，我会重点讲锁的粒度、条件变量的使用细节，这些是普通文档里不太会写的东西。

1. 先从需求倒推：你真的只需要一个std::queue吗

1.1 很多人对FIFO的最大误解：FIFO不等于std::queue

先把这个概念掰开揉碎说清楚。FIFO是一种逻辑语义，它的核心约束只有一条：先进入队列的元素，必须先被取出。至于底层用什么存储结构、内存怎么分配，那是实现细节。

std::queue是什么？它是C++标准库提供的一个容器适配器，默认基于std::deque实现。它确实天然满足FIFO语义：push_back进尾部，pop_front从头取。问题是，它只解决了“单线程环境下的先进先出”，它不负责线程安全，也不负责阻塞等待，更没有容量上限管理、超时控制、优雅退出这些生产环境里必须考虑的事情。

所以我建议你建立一个认知：std::queue是构建FIFO的“原材料”，而不是完整方案。就像你有了砖头和水泥，不等于就有了房子。

1.2 裸用std::queue的典型困境

我在代码评审里见过最多的几类问题，几乎全部来自裸用std::queue：

第一类是空队列pop。这是个非常隐蔽的坑。std::queue的pop()函数在队列为空时是未定义行为，不同编译器和标准库实现的表现还不一样。我的一个项目里曾经出现过一个诡异现象：空队列pop之后，程序没有立刻崩溃，而是过了一段时间莫名其妙地数据错乱，排查了很久才发现是有个线程在队列为空的时候执行了pop，把内存搞坏了。

第二类是多线程读写同一个queue实例。std::queue内部没有加任何锁，两个线程同时push或者一个线程push、一个线程pop，会导致deque内部结构损坏，轻则数据丢失，重则直接segment fault。这种bug在测试环境很难复现，因为需要恰好卡在特定时序上，但一旦线上流量上来，就会随机爆发。

第三类是轮询带来的CPU浪费。不少刚接触并发的同学，会用一个while循环不断检查queue.empty()，空了就继续循环。这样做的后果是，空转时CPU占用率直接拉满一个核。我在测试机上用perf查过，一个简单的空转等待队列，能让CPU单核占用冲到100%，而且业务吞吐量还低得可怜。

1.3 手写封装能解决什么

与其把这些问题散落在各个业务模块里，不如在公共层写一个队列组件，统一解决三件事：

• 把“空队列”状态和“全队列”状态都变成可预期的返回结果，而不是未定义行为；
• 把锁的控制收敛到队列内部，业务方不需要自己加锁，降低误用风险；
• 提供阻塞读、非阻塞读、超时读三种模式，让调用方按需选择。

下面表格可以比较直观地展示裸queue、手动加锁queue和封装后队列的差异：

我的结论很直接：如果是几十行代码的练习项目，用什么都没差别；如果是上了规模、多人协作、需要长期维护的工程，FIFO组件化是必然选择。

2. 接口设计里的细节：每一步都该想清楚为什么

我最初写这个FIFO的时候，想得特别简单，就四个方法：push、pop、front、empty。写完之后在真实业务里接进去，才发现接口设计不够用。这里我把迭代过程中踩过的坑和最终沉淀下来的接口设计思路讲一讲。

2.1 Push语义：入队的返回值要不要保留

早期版本，我的push是这样的：

cpp复制void push(const T& value);

为什么后来改成返回bool？因为真实业务里会有“队列满了怎么办”的问题。

生产者消费者模式中，生产速度大于消费速度时，队列会持续膨胀。如果你不设上限，内存迟早被吃光。如果设上限，push的时候就需要知道“这次到底成功了没有”。

注意，这里有一个设计决策：满了之后是阻塞等待，还是立即返回失败，还是丢弃最老的数据？

三种策略都有人用，但语义完全不同：

• 阻塞等待：适合必须保证数据不丢失的场景，例如数据库写入请求；
• 立即返回失败：适合可以暂时丢弃或者走旁路处理的场景，例如展示用的实时指标数据；
• 丢弃最老的数据（覆盖式）：适合对“最新状态”敏感、对“历史全量”不敏感的场景，例如缓存里的最新位置上报。

我最终实现的版本把选择权留给调用方：队列内部提供tryPush和push两种方法。tryPush满了就返回false，push在队列满时会阻塞。这样写业务代码的人按需取用，不会误用一个不合适的策略。

2.2 Pop语义：front和pop为什么要分开

很多人第一次接触std::queue会困惑一个问题：为什么pop不直接返回被弹出的元素？

最直接的原因是异常安全。如果pop返回值，那么拷贝或移动返回值时一旦抛出异常，元素已经被移出队列，数据就永久丢失了。标准库的解决方式是前端引用加pop两步走：

cpp复制auto value = q.front();
q.pop();

但这两步之间，如果有多个消费者线程，就会出现竞态：线程A拿到front引用后，线程B突然把元素pop掉了，线程A手里的引用失效。

线程安全版本里，Pop倾向于直接通过出参或者返回值把元素完整地搬出来。我们保留一个关键约束：一旦成功pop，元素已经安全地转移到调用方变量中，后续再发生什么都不影响数据完整性。

2.3 Empty和Size在并发下的真正含义

并发队列中最容易被误用的方法就是empty和size。

试想一个场景：线程A调用empty发现队列不为空，于是准备pop；但就在这一瞬间，线程B把队列里最后一个元素抢走了；线程A执行pop时实际是空队列，如果不做保护，就触发未定义行为。

所以线程安全版里，empty和size不应该被用于“判断之后能否pop”这种逻辑，它们的信息价值在于统计、监控、日志展示。而“能否pop”本身，必须由pop方法通过加锁状态下的真实判断来回答。

我甚至考虑过不提供size接口，只让内部统计。后来想想，对外提供统计能力，能方便业务侧做队列积压告警，所以还是保留。控制台监控、Prometheus指标采集，都依赖size的值。

2.4 存储结构的选择：为什么从std::queue换成了std::deque

关于底层容器，我的选择过程比较简单：

std::queue默认用std::deque，但由于std::queue把底层容器的接口给限制住了，很多操作还不如直接用std::deque灵活。我在实际封装时，干脆直接用std::deque做成员变量，自己控制头尾操作。原因如下：

• std::deque支持头尾双端操作，既可以push_back、pop_front实现标准FIFO，也可以在需要覆盖式更新时pop_front + push_back，非常顺手；
• std::deque不像std::vector那样要求元素在内存里连续排列，因此头部弹出时不需要搬移后续所有元素，时间复杂度是常数级；
• std::vector虽然在尾部push性能好，但头部pop是O(n)的复杂度，数据量大时性能会退化，不适合做队列底层。

选型这块，还有一个小知识点需要普及：如果你需要极致的缓存命中率，或者数据量固定且已知上限，那可以进一步改成环形缓冲区。环形缓冲区的内存预分配，不会有频繁的动态扩容，在嵌入式场景、网络收发缓冲里非常常见。但它的缺点是容量固定，满了之后需要自己处理覆盖或阻塞，灵活性低一些。面向通用业务，deque是最稳妥的选择。

3. 完整可编译的基础版源码与关键逻辑拆解

3.1 源码：单线程基础版FIFO

先看一个干净的、单线程环境下可用的版本。这个版本也适合用来学习FIFO的核心逻辑：

cpp复制#include <deque>
#include <stdexcept>

template<typename T>
class FifoQueue {
public:
    explicit FifoQueue() = default;

    // 入队，把元素追加到队尾
    void push(const T& value) {
        data_.push_back(value);
    }

    void push(T&& value) {
        data_.push_back(std::move(value));
    }

    // 尝试弹出队头元素，并存入 out
    // 队列为空时返回 false，不修改 out
    bool tryPop(T& out) {
        if (data_.empty()) {
            return false;
        }
        out = std::move(data_.front());
        data_.pop_front();
        return true;
    }

    // 查看队头元素，队列为空时抛异常
    T& front() {
        if (data_.empty()) {
            throw std::runtime_error("FifoQueue: queue is empty");
        }
        return data_.front();
    }

    const T& front() const {
        if (data_.empty()) {
            throw std::runtime_error("FifoQueue: queue is empty");
        }
        return data_.front();
    }

    void clear() {
        data_.clear();
    }

    bool empty() const {
        return data_.empty();
    }

    size_t size() const {
        return data_.size();
    }

private:
    std::deque<T> data_;
};

这段代码没什么黑魔法，核心就是围绕std::deque的push_back和pop_front，让数据进出方向固定。我想强调的是tryPop的设计：队列为空时返回false，而不是让调用方先检查empty再pop，因为从“检查empty”到“真正pop”之间，永远存在竞态窗口，哪怕单线程里是安全的，这个习惯也要从一开始就养成。

3.2 Push的两组重载：为什么需要右值引用版本

C++11之后，移动语义成了绕不开的话题。如果只提供const T&版本的push，那么调用方传入临时对象，或者通过std::move传入对象时，数据会被拷贝一次而不是移动。

对于string、vector这种持有堆内存的类型，拷贝意味着完整的内存复制，开销可以说非常扎眼。加上T&&版本的重载，等于让代码在不改变调用方写法的前提下，自动获得移动带来的性能优势：

cpp复制FifoQueue<std::string> q;
std::string url = "http://example.com/data";
q.push(url);               // 拷贝，url 还能继续用
q.push(std::move(url));    // 移动，url 处于有效但未指定状态
q.push("http://example.com/temp");  // 隐式构造临时对象后移动

实践里，我见过不少人写完这个移动版本后还有个疑虑：模板只写了T&&，如果一个左值传过来怎么办？这里其实是完美转发没发挥作用。T&&出现在非模板方法里，是普通的右值引用重载，而非转发引用。左值传参时，编译器会优先匹配const T&版本，不会出现左右不分的问题。

3.3 容量管理和clear的时机

基础版没有限制容量。好处是代码简单，坏处是生产环境风险大。上一节也提过，队列无上限时，生产者如果短时间爆发，内存会快速膨胀。在64位系统上，一个存满字符串指针的deque，膨胀到一千万条数据时，轻轻松松占到几百MB甚至几个GB。

不过，我不建议直接在基础版里堆容量控制逻辑。更好的做法是让基础版保持“最小可用”，把容量管理放到线程安全版本，因为加锁之后的阻塞、唤醒，才能真正实现“满了等一等”的语义。基础版加容量限制，满了到底报错还是忽略？单线程下什么策略都有点别扭。

clear的时机同样值得思考。clear会释放deque里所有的元素，但底层内存块不一定立刻还给操作系统，deque的实现通常会保留已分配的内存以便复用。如果需要真正释放内存，可以借助一个“空deque交换大法”：

cpp复制void releaseMemory() {
    std::deque<T> empty;
    data_.swap(empty);
}

这个技巧在实际项目里常用来应对“高峰期积压了海量消息，低峰期希望把内存还回去”的场景。我自己的服务里加了一个定时任务，队列的空闲时间超过阈值就调用releaseMemory，效果挺明显。

3.4 从单消费者到多消费者的演进思路

基础版FIFO扩展成多消费者模型，关键不在于多跑几个线程，而在于“多个线程同时从队列头部取数据”时，如何保证同一个数据不会被两个线程同时取走。

我的建议是先不在基础版上打补丁，而是跳到下一节线程安全版的实现思路。因为你迟早会发现，单靠“锁 + 非阻塞pop”在多消费者下还是不够，消费者空闲时应该让自己睡过去，有新数据时再被唤醒。这个逻辑恰好就是条件变量大显身手的地方。

4. 线程安全版：真正能进生产环境的FIFO

4.1 核心思想：锁 + 条件变量 + 状态统一保护

线程安全FIFO的本质，是让“检查状态”和“修改状态”变成一个不可分割的原子操作。

举例来说，pop的时候不能先检查empty再pop，而是要在lock_guard的保护下检查empty，如果确实为空，立刻解锁并返回失败，或者进入等待状态；如果有数据，直接从队头取一个元素，整个判断和取数的过程同一把锁保护。

基础结构是这样：

cpp复制std::mutex mtx_;
std::condition_variable cv_;
std::deque<T> data_;

push线程负责“生产”：往data_里塞数据，然后通知一个等待中的消费者。

cpp复制void push(const T& value) {
    {
        std::lock_guard<std::mutex> lock(mtx_);
        data_.push_back(value);
    }
    cv_.notify_one();
}

注意大括号的作用。锁的粒度要尽量小：数据入队这个动作需要保护，但notify操作不需要锁。如果你在持有的锁内notify，其实也不会出错，但多花一点点开销，属于“不优雅的可用状态”。我在实践中倾向于先把临界区结束再通知，这样既清晰又高效。

4.2 完整源码：线程安全FIFO队列

下面给出一个可以直接抄走的版本：

cpp复制#include <deque>
#include <mutex>
#include <condition_variable>
#include <chrono>
#include <optional>

template<typename T>
class ThreadSafeFifo {
public:
    ThreadSafeFifo() = default;

    // 禁止拷贝
    ThreadSafeFifo(const ThreadSafeFifo&) = delete;
    ThreadSafeFifo& operator=(const ThreadSafeFifo&) = delete;

    // 入队
    void push(const T& value) {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            data_.push_back(value);
        }
        cv_.notify_one();
    }

    void push(T&& value) {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            data_.push_back(std::move(value));
        }
        cv_.notify_one();
    }

    // 队尾批量入队
    template<typename InputIt>
    void pushRange(InputIt first, InputIt last) {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            for (; first != last; ++first) {
                data_.push_back(std::move(*first));
            }
        }
        cv_.notify_all();
    }

    // 阻塞式弹出：队列为空时等待，直到有数据
    T pop() {
        std::unique_lock<std::mutex> lock(mtx_);
        cv_.wait(lock, [this]() { return closed_ || !data_.empty(); });
        if (closed_ && data_.empty()) {
            throw std::runtime_error("ThreadSafeFifo: queue closed and empty");
        }
        T value = std::move(data_.front());
        data_.pop_front();
        return value;
    }

    // 非阻塞式弹出
    bool tryPop(T& out) {
        std::lock_guard<std::mutex> lock(mtx_);
        if (data_.empty()) {
            return false;
        }
        out = std::move(data_.front());
        data_.pop_front();
        return true;
    }

    // 超时阻塞式弹出
    std::optional<T> popFor(std::chrono::milliseconds timeout) {
        std::unique_lock<std::mutex> lock(mtx_);
        if (!cv_.wait_for(lock, timeout, [this]() { return closed_ || !data_.empty(); })) {
            return std::nullopt;
        }
        if (closed_ && data_.empty()) {
            return std::nullopt;
        }
        T value = std::move(data_.front());
        data_.pop_front();
        return std::optional<T>(std::move(value));
    }

    // 关闭队列，并唤醒所有阻塞中的线程
    void close() {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            closed_ = true;
        }
        cv_.notify_all();
    }

    // 重新打开队列
    void open() {
        std::lock_guard<std::mutex> lock(mtx_);
        closed_ = false;
    }

    bool empty() const {
        std::lock_guard<std::mutex> lock(mtx_);
        return data_.empty();
    }

    size_t size() const {
        std::lock_guard<std::mutex> lock(mtx_);
        return data_.size();
    }

    void clear() {
        std::lock_guard<std::mutex> lock(mtx_);
        data_.clear();
    }

private:
    mutable std::mutex mtx_;
    std::condition_variable cv_;
    std::deque<T> data_;
    bool closed_ = false;
};

4.3 实现细节逐一说明

这段代码每个方法单独看都不复杂，但合起来有四个细节容易被忽略。

第一个是close()。它是优雅停机的关键。服务要退出时，如果消费者线程还阻塞在cv_.wait()上，你不唤醒它，它永远等不到数据，进程也没法正常结束。close先把closed_置为true，再notify_all，等消费者醒过来检查条件时发现队列已关闭且没有数据，就会抛异常或者返回空，线程得以退出。如果没有close机制，程序只能靠进程强制退出，这在生产环境里是不允许的。

第二个是条件变量的谓词写法。我用了wait(lock, predicate)这种带谓词的形式，而不是先wait再单独判断。为什么？因为条件变量存在“虚假唤醒”的可能。所谓虚假唤醒，就是没有线程notify，wait也有极低概率自己返回。正因如此，wait返回后必须重新检查“条件是否真的满足”。带谓词的wait内部会自动做循环检查，省得自己写while。

第三个是pop()的返回值。这里用传值返回，配合移动构造。当T是vector、string这类支持移动语义的类型时，这个pop的代价很低，不会产生深层拷贝。如果你使用的T是拷贝昂贵的类型，而且不支持移动，那pop的性能会打折扣，这种情况建议在评论区之前想清楚，最好给元素类型加上移动构造函数。

第四个是popFor()的std::optional返回值。C++17之后，optional很适合表达“有值或没值”的状态。你可能会问，为什么不用超时bool + 出参？两种风格都能工作，但optional在语义上更干净，调用方可以直接判断nullopt来判断是否超时。考虑到C++20之后还有std::expected，将来可以进一步把这个接口改成返回错误码，但目前optional完全够用。

4.4 消费者线程怎么写才标准

有了ThreadSafeFifo，最简单的一个消费者线程长这样：

cpp复制ThreadSafeFifo<std::string> queue;

void consumerThread() {
    while (true) {
        std::string item;
        try {
            item = queue.pop();  // 阻塞等待
        } catch (const std::runtime_error& e) {
            // 队列已关闭且无数据，退出循环
            break;
        }
        process(item);
    }
}

另外一个常见写法是用popFor加轮询超时，配合心跳检测：

cpp复制void consumerThreadWithHeartbeat() {
    while (running_) {
        auto item = queue.popFor(std::chrono::milliseconds(1000));
        if (item.has_value()) {
            process(*item);
        } else {
            sendHeartbeat();  // 定时上报存活状态
        }
    }
}

这两种模式各有适用场景。第一种适合进程生命周期与队列绑定较紧的情况；第二种适合主流程还需要照顾其他定时任务的情况。我现在的项目里，这两种模式都存在，不同业务按需选择。

4.5 容量限制升级

生产环境里几乎没有人愿意让队列无限增长。在ThreadSafeFifo的基础里可以继续加一个maxSize_成员，push时检查当前大小，超过阈值就等待消费者腾出空间。

实现原理如下：

cpp复制void pushWithLimit(const T& value) {
    std::unique_lock<std::mutex> lock(mtx_);
    // 等待队列有空位
    cv_not_full_.wait(lock, [this]() {
        return closed_ || data_.size() < maxSize_;
    });
    if (closed_) {
        throw std::runtime_error("ThreadSafeFifo: queue closed");
    }
    data_.push_back(value);
    cv_not_empty_.notify_one();
}

这里需要两个条件变量，一个用于“不空”，一个用于“不满”。如果只有一个条件变量，push和pop会互相唤醒，白白增加无效竞争。

容量的设置要结合服务实际承受能力。我通常会根据两个指标算：最大积压数量等于“峰值生产速率 × 允许的最大处理延迟”。比如峰值每秒产生1万条消息，而业务能容忍的延迟是2秒，那容量设到2万到3万就差不多了。设得太小，系统会频繁阻塞生产者；设得太大，内存峰值又不好控，需要权衡。

5. 用代码说话：测试怎么跑、坑怎么避

5.1 一段顺序性测试

实现完FIFO之后，第一步不是跑到业务里联调，而是写一段无脑但有效的顺序性测试。

cpp复制#include <iostream>
#include <cassert>

void testOrder() {
    ThreadSafeFifo<int> queue;
    for (int i = 0; i < 10000; ++i) {
        queue.push(i);
    }
    for (int i = 0; i < 10000; ++i) {
        int value = 0;
        bool success = queue.tryPop(value);
        assert(success);
        assert(value == i);
    }
    assert(queue.empty());
    std::cout << "order test passed" << std::endl;
}

这个测试保证的是：出队顺序严格等于入队顺序。如果这一关都过不了，后面一切免谈。

真正的强度来自并发压力测试。我会起N个生产者线程，每个线程往队列里塞一批带编号的数据；起M个消费者线程，把取出来的数据丢到一个线程安全的汇总结构里，最后检查数字是否无遗漏、无重复、顺序是否符合预期。

这里有个容易出bug的点：汇总结构本身也要线程安全，很多人只测了队列，没注意到自己的统计代码反而引入了数据竞争。

5.2 空队列、满队列、关闭后的行为

边界测试不能省，尤其是“关闭之后调tryPop”这类情况。你希望它返回false，而不是抛异常，或者更糟——卡死。

最后一行一定要重点测试：close不能清空已有数据。正确逻辑是close之后消费者继续pop剩余的数据，直到取空后才面临异常。否则服务下线的瞬间可能丢掉积压的所有消息。

5.3 锁的粒度对性能的影响

我在自己的压测里对比过粗粒度锁和细粒度锁。粗粒度写法是通知操作也放在锁内：

cpp复制void pushLockInsideNotify(const T& value) {
    std::lock_guard<std::mutex> lock(mtx_);
    data_.push_back(value);
    cv_.notify_one();
}

细粒度写法是文章里推荐的写法：数据入队后立即解锁，再通知。两者在通知开销本身不大的情况下，性能差异并不明显，大概在5%到10%之间。但如果消费者的wait条件不复杂、锁竞争激烈，细粒度版本优势会放大。更重要的是，通知放在锁外能减少一种“无谓唤醒”：通知发生时消费者尝试拿锁，可生产者还占着锁，消费者必须等锁释放才能开始处理。虽然不影响正确性，但在高并发下会引入额外延迟。

还有一种更极端的优化是批量弹出：一次pop多个元素时，只在开头和结尾各拿一次锁，中间批量处理数据。这在消息队列组件里很常见，能显著减少锁竞争次数。如果你的业务是一次pop一条、然后立即处理一条，锁的开销占比其实不高；如果业务是攒一批数据然后批量处理，那批量pop的效果会非常明显。

5.4 两个容易忽略的重灾区

第一是中优先级反转。一个低优先级的线程持有互斥锁，同时一个高优先级线程在等待这个锁，调度器可能会让低优先级线程长期得不到CPU，进而一直释放不了锁，高优先级线程也拿不到锁。这就是优先级反转。C++标准库的std::mutex不负责解决这个问题。Linux下可以用pthread_mutexattr_setprotocol来设置优先级继承协议，但标准库层面没有统一接口。如果你在实时性要求很高的系统上使用多线程FIFO，这个问题需要认真做一次评估。

第二是异常安全。当T的移动构造函数可能抛异常时，pop过程存在风险。假设我们先把队头元素move到局部变量，如果移动构造抛了异常，那么元素可能被移动了一半，已经在队列里变成残缺状态。大多数实际类型（如vector、string、shared_ptr）的移动构造都声明为noexcept，不会抛异常。如果你封装了某些奇怪的业务类型，最好确认它的移动构造是noexcept的。C++标准里，vector在扩容时只有T的移动构造是noexcept才移动，否则退化为拷贝，逻辑是完全一致的。

6. 贴一个能跑通的完整示例：生产者消费者实现

聊了这么多概念，不如放一个完整的可运行示例。下面的代码，把一个ThreadSafeFifo用于典型的生产者消费者模型：

cpp复制#include <iostream>
#include <thread>
#include <vector>
#include <atomic>
#include "thread_safe_fifo.h"  // 对上文源码的引用

std::atomic<int> produced_count{0};
std::atomic<int> consumed_count{0};

void producer(ThreadSafeFifo<int>& q, int id, int total) {
    for (int i = 0; i < total; ++i) {
        int value = id * 100000 + i;
        q.push(value);
        produced_count.fetch_add(1, std::memory_order_relaxed);
    }
}

void consumer(ThreadSafeFifo<int>& q, int id) {
    while (true) {
        int value = 0;
        bool ok = q.tryPop(value);
        if (ok) {
            consumed_count.fetch_add(1, std::memory_order_relaxed);
            // 模拟业务处理
        } else {
            std::this_thread::yield();
        }
    }
}

int main() {
    ThreadSafeFifo<int> q;

    std::vector<std::thread> producers;
    std::vector<std::thread> consumers;

    const int kProducerNum = 4;
    const int kConsumerNum = 4;
    const int kProducePerThread = 100000;

    for (int i = 0; i < kProducerNum; ++i) {
        producers.emplace_back(producer, std::ref(q), i, kProducePerThread);
    }
    for (int i = 0; i < kConsumerNum; ++i) {
        consumers.emplace_back(consumer, std::ref(q), i);
    }

    for (auto& t : producers) {
        t.join();
    }

    // 为了能退出，这里需要等待队列被消费完。
    // 生产者的场景结束后，一般在业务里会由主线程决定何时close。
    std::this_thread::sleep_for(std::chrono::seconds(1));
    for (auto& t : consumers) {
        // 生产结束后，使用close让消费者退出
        // 为了直观，这里先不再演示，只做简单join
        t.detach();
    }

    std::cout << "produced: " << produced_count.load()
              << ", consumed: " << consumed_count.load() << std::endl;
    return 0;
}

这个示例不是最终生产代码，但足够展示怎么起多个生产者和多个消费者。真实项目里，消费者线程一般循环到队列close才退出，生产者的生命周期也不完全等于主线程生命周期，需要由服务框架统一管理。

7. 工程落地后的三层进阶建议

7.1 第一层：什么时候可以继续沿用封装

如果你的业务数据量不大，队列峰值也就几千条，线程数量不超过两位数，ThreadSafeFifo已经完全够用。不必一开始就上无锁队列，因为无锁队列不仅仅是代码复杂，还容易在ABA问题、内存回收上掉进深坑。

顺便解释下ABA问题，它来自CAS操作的经典陷阱：线程A读到指针X，然后被调度走；线程B把X指向的内存释放后重新分配，恰好又得到一个地址相同的指针X；线程A恢复执行后CAS比较地址发现还是X，以为一切没变，实际上对应的对象已经被替换或破坏。无锁队列处理这个问题需要额外的标记位或延迟回收机制，非常麻烦。所以凡是能用互斥锁解决问题，我都倾向于先用互斥锁。

7.2 第二层：从阻塞队列走向无锁队列的临界点

业界有一种粗略经验：锁竞争激烈时，阻塞队列的吞吐量会受限于上下文切换和锁等待，当线程数非常多、临界区又短时，无锁队列可能体现出优势。但这个临界点，依据硬件核心数、数据量、临界区代码长度都会变化。我自己通常会先做压测，用一个简单的基准：在固定线程数下，分别跑阻塞版本和无锁版本，对比吞吐量和P99延迟。只有在阻塞版本出现明显的性能瓶颈，而且木桶的确切位置在锁竞争时，才值得迁移。

7.3 第三层：FIFO之上还能叠什么

实际业务里，纯粹的单一FIFO队列常常不够。我遇到过最多的情况是需要优先级队列，比如重要事件可以插队到普通事件前面。这时可以做成多级队列：维护一个普通FIFO和一个高优先级FIFO，弹出时先看高优先级队列是否为空，为空再取普通队列。这种设计在通用调度器、网络包处理、任务中心里都很常见。

再往上叠的是批量接口。把队列里积压的数据一次性取出一批，减少获取频率，适合日志消费端。例如pushRange、tryPopRange两个批量操作，可以极大降低高频数据流的锁竞争次数。配合“攒够N条才提交”的批量处理，整体处理效率往往能提升一个量级。

说句实在话，我自己在好几个服务里替换掉最初那份手写queue的时候，线上最明显的改善不是吞吐量，而是稳定性——再也没有那些偶发的空队列崩溃和退出时的卡死问题了。数据结构的价值，往往要到生产环境里遇到意外才能体感出来。如果你手头正好需要一个可靠、可维护的FIFO，这套实现和测试方法可以随手拿去用，有问题可以在评论区把场景发出来，我们一起看看能不能找到更合适的方案。