performance of ConcurrentQueue vs Queue + lock
本文关键字：lock Queue vs of ConcurrentQueue performance | 更新日期: 2023-09-27 17:50:31
我必须实现一个消费者一个生产者的标准算法。我可以使用Queue和几个lock语句轻松实现它。或者我可以用ConcurrentQueue。哪个更好?
如果使用Queue + lock，那么我可以优化"多次添加/检索"，因为我可以一次lock，然后多次Add。
一般情况下，ConcurrentQueue和Queue + lock哪个更快，差异有多大?当然ConcurrentQueue是最直接的方式，但我不想失去很多性能，因为我在高频交易应用程序中使用它。
From c# in a Nutshell:
实现了并发堆栈、队列和包类内部使用链表。这使得它们的内存效率较低比非并发的
Stack和Queue类要好，但是对于并发访问，因为链表有利于无锁或low-lock实现。
换句话说，很难定义一般情况，更不用说预测性能上的差异了。
取决于集合的大小和使用情况。如果有足够的并发访问，性能可以预期会更好，内存消耗会更差。
另外，来自Microsoft文档关于ConcurrentQueue(T)和Queue(T):
在纯生产者-消费者场景中，处理时间为每个元素都非常小(只有几个指令)System.Collections.Concurrent.ConcurrentQueue可以提供适度的性能优于System.Collections.Generic.Queue有一个外部锁。在这个场景中，ConcurrentQueue执行当一个专用线程正在排队而另一个专用线程正在排队时效果最好de-queuing。如果您不执行此规则，那么Queue甚至可能运行速度比ConcurrentQueue稍微快一些多个核心。
当处理时间约为500 FLOPS(浮点操作)时或更多，则双线程规则不适用于ConcurrentQueue，它有很好的可伸缩性。队列在这种情况下不能很好地伸缩。
在混合生产者-消费者场景中，当处理时间非常较小，具有外部锁的Queue的可伸缩性优于ConcurrentQueue。但是，当处理时间在500左右时如果是FLOPS或更多，那么ConcurrentQueue的伸缩效果更好。