c# - 如果您知道访问模式不利，ConcurrentBag 是否仍然是支持对象池的正确选择？

Question

在分析之后，我发现我的应用程序中的特定对象将通过使用对象池而不是构造它而受益匪浅。此应用程序基于具有多个线程的生产者/消费者队列。

ConcurrentBag 集合基本上是一个 ObjectPool，看起来非常适合作为应用程序对象池的后备存储。如果我理解正确，ConcurrentBag 在概念上是这样工作的：

1. 保留袋装对象的 ThreadLocal 集合。插入时添加到此集合，移除时从此集合中移除。
2. 如果本地集合中没有元素并且必须删除一个对象，则从另一个线程的本地集合中窃取一个。

问题是我已经知道应用程序将始终在线程“A”上请求对象，并始终在线程“B”上返回它。因此，它将始终默认为窃取案例。

了解了这种访问模式，使用框架提供的不同集合来支持对象池会更好吗？

Answer 1

对于您的用例， ConcurrentQueue 将是更好的结构。正如您推测的那样，ConcurrentBag 应该只在您主要从同一个线程插入和拉取时才真正使用，ConcurrentQueue 没有线程关联。

大多数生产者消费者模型将具有单独的线程写入和读取，这就是BlockingCollection<T>使用 aConcurrentQueue<T>作为其默认后备存储的原因。