moodycamel::ConcurrentQueue一个头文件解决的 C 无锁并发队列【免费下载链接】concurrentqueueA fast multi-producer, multi-consumer lock-free concurrent queue for C11项目地址: https://gitcode.com/GitHub_Trending/co/concurrentqueuemoodycamel::ConcurrentQueue 是一个 C11 单头文件库提供多生产者多消费者MPMC无锁并发队列适合需要在多个线程之间安全传递数据、又不想为每次入队出队都加锁的服务端与工具类程序。一句话定位给需要在多个线程间共享数据、且对吞吐敏感的使用者它回答的问题是如何让多个线程同时向同一个队列写入和读取而互不阻塞。整个队列实现放在一个头文件 concurrentqueue.h 里没有汇编代码靠标准 C11 原子原语完成跨平台行为一致。真实场景线程池里的任务被锁拖慢假设你在写一个带线程池的日志处理程序8 个工作线程不断产生日志事件另外的线程负责落盘。常见的做法是给一个std::vector或std::queue套一把std::mutex。线程数一多问题就来了多个线程抢同一把锁临界区外的代码再快也没用等待时间直接叠加到业务延迟上锁的持有时间越短越好但入队 条件变量通知这套组合写起来容易出错漏一次唤醒就可能卡死消费者更糟的是某些写法下线程忙等、自旋CPU 占用飙高。无锁队列的思路是绕开互斥锁用原子操作保证同一时刻只有一个线程完成入队或出队。moodycamel::ConcurrentQueue就是为这种多生产者、多消费者、高吞吐的场景准备的队列内部按生产者拆分、用原子操作协调任意多个线程可以同时调用入队和出队不需要你在外面再包锁。最短路径五行代码跑起来克隆仓库后git clone https://gitcode.com/GitHub_Trending/co/concurrentqueue把根目录下的头文件拷进工程最小用法就是#include concurrentqueue.h moodycamel::ConcurrentQueueint q; q.enqueue(25); int item; bool ok q.try_dequeue(item); // 成功时 ok 为 trueitem 是 25编译只需保证 C11 支持README 给出的参考线是 g 4.8 及以上、VS2012 及以上g 4.6 因std::atomic的已知缺陷不被支持。不需要链接任何额外库不需要 CMake——当然仓库也提供了 CMakeLists.txt 便于工程化管理。关键设计决策为什么内部是这样按生产者拆分子队列。每个生产者对应一条子队列消费者出队时逐条检查各子队列直到找到非空的那条。好处是不同生产者之间几乎不互相竞争代价是出队要扫一遍生产者列表——这个扫描用原子操作完成仍然无锁。连续内存块代替链表。元素存放在连续内存块block里而不是节点链表缓存命中更好分配次数也更少。内存可以构造时按预估数量一次分配好也可以按需动态增长enqueue不够空间时会自己分配try_enqueue则只使用已有空间、空间不足就返回失败适合对分配时机有要求的地方。元素用移动而非拷贝。队列是模板实现不要求你存指针元素在 C11 语义下尽可能以移动方式进出这对大对象字符串、容器影响明显。批量操作是设计重点而不是附加功能。enqueue_bulk和try_dequeue_bulk一次搬一片数据。README 里作者明确说在这种设计下批量操作比逐条进出快得多高竞争下甚至能接近非并发队列的速度。非阻塞版和阻塞版分开。需要没有数据就等着的消费者可以用 blockingconcurrentqueue.h 里的BlockingConcurrentQueue它依赖 lightweightsemaphore.h 提供wait_dequeue及带超时的变体开销很低但略慢于非阻塞版。用一点语义强度换性能。作者坦率说明这个队列不是线性化的也不是顺序一致的。两个生产者同时入队时元素出来的先后没有定义但单个生产者内部顺序保持。好处是性能更好副作用是把队列抽干这类操作需要配合内存序仔细处理README 建议照着 samples.md 的写法来。另外队列内部复用内存较多在 NUMA 大内存机器上扩展性预期一般。显式 token 是性能开关。每个方法基本都有两个版本不带 token 的隐式版和接受生产者/消费者 token 的显式版。token 给队列提供每个线程的私有存储减少内部簿记几乎总是更快。README 给出的效率排序是带 token 的批量 不带 token 的批量 带 token 的单条 不带 token 的单条。理想情况是每线程一个 token。可靠性背书测试覆盖了什么这个项目把测试按不同层级拆开做对应目录如下验证手段位置覆盖内容单元测试tests/unittests/入队/出队、批量、token、内存管理等核心行为配套轻量断言框架 minitest.h模糊测试tests/fuzztests/多线程随机交错操作暴露罕见时序问题Relacy 模型检查tests/relacy/既检查核心组件freelist、spmchash也有对完整实现跑全量覆盖的 integrated 测试注释里说明更慢但覆盖更好CDSChecker 模型检查tests/CDSChecker/对核心算法做形式化模型检查验证并发算法层面的正确性基准测试benchmarks/与 Boost lockfree、Intel TBB、dlib、带锁的 std::queue 等实现在多生产者多消费者场景下对比吞吐另外根目录还有 c_api/用 C 接口包装了队列handle 加一组函数指针给不想直接用 C 模板的场景兜底。选型与避坑什么时候用、哪里要小心适合的场景线程池任务分发BlockingConcurrentQueue配wait_dequeue是现成的 worker 等待写法samples.md 里有完整示例对象池、连接池任何线程try_dequeue取用、用完enqueue归还多生产者多消费者的高吞吐数据通道且不需要严格的全局顺序。不适合或要换方案的情况只需要单生产者单消费者时无锁 MPMC 的实现相对专用 SPSC 结构会有不必要的开销README 提到作者另有 SPSC 队列可优先选专用方案业务要求跨生产者严格全序或要求线性化语义时这个队列不保证这一点——README 的建议是如果逻辑上其实只有一个逻辑生产者可以共享一个生产者 token 来恢复全序如果线程之间本来就不共享数据那最快的同步是不发生同步别为了用队列而用队列。生产使用中的常见坑析构时机。任何线程还在用队列时不能销毁它阻塞版尤其严格——有线程在wait_dequeue上等待时销毁队列是未定义行为所以阻塞取数前得先确保后续还会有元素进来或者用带超时的版本size_approx()只是近似值。队列尚未稳定时它可能返回 0 但实际非空别拿它当精确计数短生命周期线程慎用隐式生产者。隐式入队会为线程自动分配子队列线程退出后这些子队列会被标记复用但并非所有平台都支持README 明确建议短命线程场景改用显式生产者 token抽干队列要配内存序。多线程场景下判断队列真的空了需要按 samples.md 里的 fence 写法处理直接while (try_dequeue)抽干在多消费者下不一定可靠token 别乱建。token 本身不是线程安全的理想是每个线程持有一个而不是每次调用临时创建。总结与下一步moodycamel::ConcurrentQueue的价值在于把多线程安全 无锁高吞吐 不挑元素类型三件事塞进一个头文件代价是放弃线性化和顺序一致性以及几个需要刻意规避的使用陷阱。想深入的话从 samples.md 的七个场景示例入手含线程池任务队列、游戏主循环、对象池再看 README 中High-level design一节对子队列结构的说明关注实现的读者可以直接读 concurrentqueue.h 源码或用 internal/concurrentqueue_internal_debug.h 打开内部调试检查。【免费下载链接】concurrentqueueA fast multi-producer, multi-consumer lock-free concurrent queue for C11项目地址: https://gitcode.com/GitHub_Trending/co/concurrentqueue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
moodycamel::ConcurrentQueue：一个头文件解决的 C++ 无锁并发队列
moodycamel::ConcurrentQueue一个头文件解决的 C 无锁并发队列【免费下载链接】concurrentqueueA fast multi-producer, multi-consumer lock-free concurrent queue for C11项目地址: https://gitcode.com/GitHub_Trending/co/concurrentqueuemoodycamel::ConcurrentQueue 是一个 C11 单头文件库提供多生产者多消费者MPMC无锁并发队列适合需要在多个线程之间安全传递数据、又不想为每次入队出队都加锁的服务端与工具类程序。一句话定位给需要在多个线程间共享数据、且对吞吐敏感的使用者它回答的问题是如何让多个线程同时向同一个队列写入和读取而互不阻塞。整个队列实现放在一个头文件 concurrentqueue.h 里没有汇编代码靠标准 C11 原子原语完成跨平台行为一致。真实场景线程池里的任务被锁拖慢假设你在写一个带线程池的日志处理程序8 个工作线程不断产生日志事件另外的线程负责落盘。常见的做法是给一个std::vector或std::queue套一把std::mutex。线程数一多问题就来了多个线程抢同一把锁临界区外的代码再快也没用等待时间直接叠加到业务延迟上锁的持有时间越短越好但入队 条件变量通知这套组合写起来容易出错漏一次唤醒就可能卡死消费者更糟的是某些写法下线程忙等、自旋CPU 占用飙高。无锁队列的思路是绕开互斥锁用原子操作保证同一时刻只有一个线程完成入队或出队。moodycamel::ConcurrentQueue就是为这种多生产者、多消费者、高吞吐的场景准备的队列内部按生产者拆分、用原子操作协调任意多个线程可以同时调用入队和出队不需要你在外面再包锁。最短路径五行代码跑起来克隆仓库后git clone https://gitcode.com/GitHub_Trending/co/concurrentqueue把根目录下的头文件拷进工程最小用法就是#include concurrentqueue.h moodycamel::ConcurrentQueueint q; q.enqueue(25); int item; bool ok q.try_dequeue(item); // 成功时 ok 为 trueitem 是 25编译只需保证 C11 支持README 给出的参考线是 g 4.8 及以上、VS2012 及以上g 4.6 因std::atomic的已知缺陷不被支持。不需要链接任何额外库不需要 CMake——当然仓库也提供了 CMakeLists.txt 便于工程化管理。关键设计决策为什么内部是这样按生产者拆分子队列。每个生产者对应一条子队列消费者出队时逐条检查各子队列直到找到非空的那条。好处是不同生产者之间几乎不互相竞争代价是出队要扫一遍生产者列表——这个扫描用原子操作完成仍然无锁。连续内存块代替链表。元素存放在连续内存块block里而不是节点链表缓存命中更好分配次数也更少。内存可以构造时按预估数量一次分配好也可以按需动态增长enqueue不够空间时会自己分配try_enqueue则只使用已有空间、空间不足就返回失败适合对分配时机有要求的地方。元素用移动而非拷贝。队列是模板实现不要求你存指针元素在 C11 语义下尽可能以移动方式进出这对大对象字符串、容器影响明显。批量操作是设计重点而不是附加功能。enqueue_bulk和try_dequeue_bulk一次搬一片数据。README 里作者明确说在这种设计下批量操作比逐条进出快得多高竞争下甚至能接近非并发队列的速度。非阻塞版和阻塞版分开。需要没有数据就等着的消费者可以用 blockingconcurrentqueue.h 里的BlockingConcurrentQueue它依赖 lightweightsemaphore.h 提供wait_dequeue及带超时的变体开销很低但略慢于非阻塞版。用一点语义强度换性能。作者坦率说明这个队列不是线性化的也不是顺序一致的。两个生产者同时入队时元素出来的先后没有定义但单个生产者内部顺序保持。好处是性能更好副作用是把队列抽干这类操作需要配合内存序仔细处理README 建议照着 samples.md 的写法来。另外队列内部复用内存较多在 NUMA 大内存机器上扩展性预期一般。显式 token 是性能开关。每个方法基本都有两个版本不带 token 的隐式版和接受生产者/消费者 token 的显式版。token 给队列提供每个线程的私有存储减少内部簿记几乎总是更快。README 给出的效率排序是带 token 的批量 不带 token 的批量 带 token 的单条 不带 token 的单条。理想情况是每线程一个 token。可靠性背书测试覆盖了什么这个项目把测试按不同层级拆开做对应目录如下验证手段位置覆盖内容单元测试tests/unittests/入队/出队、批量、token、内存管理等核心行为配套轻量断言框架 minitest.h模糊测试tests/fuzztests/多线程随机交错操作暴露罕见时序问题Relacy 模型检查tests/relacy/既检查核心组件freelist、spmchash也有对完整实现跑全量覆盖的 integrated 测试注释里说明更慢但覆盖更好CDSChecker 模型检查tests/CDSChecker/对核心算法做形式化模型检查验证并发算法层面的正确性基准测试benchmarks/与 Boost lockfree、Intel TBB、dlib、带锁的 std::queue 等实现在多生产者多消费者场景下对比吞吐另外根目录还有 c_api/用 C 接口包装了队列handle 加一组函数指针给不想直接用 C 模板的场景兜底。选型与避坑什么时候用、哪里要小心适合的场景线程池任务分发BlockingConcurrentQueue配wait_dequeue是现成的 worker 等待写法samples.md 里有完整示例对象池、连接池任何线程try_dequeue取用、用完enqueue归还多生产者多消费者的高吞吐数据通道且不需要严格的全局顺序。不适合或要换方案的情况只需要单生产者单消费者时无锁 MPMC 的实现相对专用 SPSC 结构会有不必要的开销README 提到作者另有 SPSC 队列可优先选专用方案业务要求跨生产者严格全序或要求线性化语义时这个队列不保证这一点——README 的建议是如果逻辑上其实只有一个逻辑生产者可以共享一个生产者 token 来恢复全序如果线程之间本来就不共享数据那最快的同步是不发生同步别为了用队列而用队列。生产使用中的常见坑析构时机。任何线程还在用队列时不能销毁它阻塞版尤其严格——有线程在wait_dequeue上等待时销毁队列是未定义行为所以阻塞取数前得先确保后续还会有元素进来或者用带超时的版本size_approx()只是近似值。队列尚未稳定时它可能返回 0 但实际非空别拿它当精确计数短生命周期线程慎用隐式生产者。隐式入队会为线程自动分配子队列线程退出后这些子队列会被标记复用但并非所有平台都支持README 明确建议短命线程场景改用显式生产者 token抽干队列要配内存序。多线程场景下判断队列真的空了需要按 samples.md 里的 fence 写法处理直接while (try_dequeue)抽干在多消费者下不一定可靠token 别乱建。token 本身不是线程安全的理想是每个线程持有一个而不是每次调用临时创建。总结与下一步moodycamel::ConcurrentQueue的价值在于把多线程安全 无锁高吞吐 不挑元素类型三件事塞进一个头文件代价是放弃线性化和顺序一致性以及几个需要刻意规避的使用陷阱。想深入的话从 samples.md 的七个场景示例入手含线程池任务队列、游戏主循环、对象池再看 README 中High-level design一节对子队列结构的说明关注实现的读者可以直接读 concurrentqueue.h 源码或用 internal/concurrentqueue_internal_debug.h 打开内部调试检查。【免费下载链接】concurrentqueueA fast multi-producer, multi-consumer lock-free concurrent queue for C11项目地址: https://gitcode.com/GitHub_Trending/co/concurrentqueue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
