Rust中Intel tbb::concurrent_queue的等价并发队列是什么？

如果你在找Rust里和TBB concurrent_queue 对标高效MPMC（多生产者多消费者）队列，我来帮你拆解下你提到的这些crate，以及它们和TBB实现的性能差异：

• crossbeam-deque：首先得明确，这个 crate 是为**工作窃取（work-stealing）**场景设计的，主要用于线程池的任务调度（比如rayon这类并行库就依赖它）。它虽然支持MPMC，但设计目标不是通用的高并发消息队列，和TBB concurrent_queue 的适用场景有区别，如果你需要的是通用队列，可能不是最优选择。

• multiqueue：这是一个专门针对通用MPMC场景优化的无锁队列，底层基于改进的Michael-Scott无锁算法。它的设计目标就是追求高吞吐量和低延迟，在很多高并发基准测试中，它的性能表现和TBB concurrent_queue 非常接近——因为无锁设计避免了传统锁的竞争开销，这一点和TBB通过分段锁、本地缓存减少竞争的思路异曲同工。

• two-lock-queue：这个是经典的双锁队列实现，用独立的生产者锁和消费者锁分离竞争。它的优势是实现简单、内存占用低，但在极高并发场景下，锁竞争的瓶颈会比TBB的实现更明显，吞吐量可能会落后一些，适合并发度不那么极端的场景。

• futures-pool/thread-pool：这两个是线程池实现，不是独立的队列crate——它们内部确实会用到队列来调度任务，但不会暴露给用户作为通用MPMC队列使用，所以可以直接排除在你的候选列表之外。

另外补充一个你没提到但值得关注的选项：crossbeam-queue，它是crossbeam家族里的通用MPMC队列，提供了无锁的ConcurrentQueue类型，性能同样出色，很多Rust并发场景中会优先选择它，因为crossbeam生态的稳定性和文档完善度都很高。

至于性能是否能达到TBB的水平，其实不用太担心：很多Rust无锁队列的实现已经在高并发场景下做到了和TBB相近甚至更高的吞吐量——一方面是Rust的内存模型对无锁操作的友好支持，另一方面是这些crate针对现代CPU的缓存、指令集做了大量优化。如果你的场景对性能要求极高，建议自己跑一下基准测试（比如用criterion crate），对比这些队列在你的具体 workload 下的表现。

内容的提问来源于stack exchange，提问作者asdetrefle