ConcurrentBag(T)是否针对单线程场景进行了优化？如果是这样，为什么要并发？
ConcurrentBag.NET 4.0 并发集合库中的类表示：
ConcurrentBag是一个线程安全的包 实施，优化 同一线程的场景 既生产数据又消费数据 存放在包里。 [强调我的]
我是否遗漏了一些东西，或者是说 ConcurrentBag
如果我没有遗漏了什么……为什么会这样呢？拥有一个为并发设计的集合，但针对一个线程进行优化，这似乎很奇怪。
The MSDN documentation on the ConcurrentBag<T> class from .NET 4.0's concurrent collections library says this:
ConcurrentBag is a thread-safe bag
implementation, optimized for
scenarios where the same thread will
be both producing and consuming data
stored in the bag. [emphasis mine]
Am I missing something, or is this saying that the ConcurrentBag<T> class is optimized for single-threaded scenarios?
If I'm not missing something... why would this be? It just seems pretty strange to have a collection designed for concurrency but optimized for one thread.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
优化意味着，如果您有多个线程同时生产和消费，则可以进行适当的优化，如果它可以返回由同一线程放入包中的项目，则速度最快。
如果线程向袋子询问物品，并且袋子中不再有该线程放置的物品，则不适用此优化。在这种情况下，它仍然可以从袋子中检索物品（由另一个线程放置在其中），但它不是最佳的。
或者，换句话说：它是并发的，因为多个线程可以同时生成它并从中消费，而无需外部锁定。上述优化并不能证明这一点是不正确的。
The optimization means that, if you have multiple threads both producing and consuming, there are optimizations in place such that it's fastest if it can return an item that was placed in the bag by the same thread.
Where this optimization doesn't apply is if a thread asks the bag for an item, and there are no more items left in the bag that were placed there by that thread. In that case, it can still retrieve an item from the bag (placed in there by another thread), but it's less optimal.
Or, to put it another way: It's Concurrent because multiple threads can be producing into it and consuming from it simultaneously, without external locking. The mentioned optimization doesn't make this untrue.
您可能会使用 ConcurrentBag 的三种场景以及此优化如何影响它们：
1) 分离生产者和消费者线程。没有效果。
2) 既是消费者又是生产者的线程，在 ConcurrentBag 中存储和检索数据。该优化将提高同一线程添加/检索操作的性能。
3) 可以使用常规集合的单线程场景。优化意味着使用 ConcurrentBag 的开销很小，因此您可以使用它而不会造成巨大的性能损失。
Three scenarios where you might use a
ConcurrentBagand how this optimization affects them:1) Separate producer and consumer threads. No effect.
2) Threads that are both consumers and producers storing and retrieving data from the
ConcurrentBag. The optimization will improve performance for same-thread add / retrieve operations.3) Single threaded scenarios that could use a regular collection. The optimization means that there is little overhead in using a
ConcurrentBagso you can use it without a huge performance hit.文档试图说明的是，它更喜欢使用同一线程生成和使用数据。
它有一个快速路径，当同一线程生成和使用数据时，数据保留在该线程上（想想
[ThreadStatic]）。但是，当同一线程上没有数据可供使用时，它会查找其他线程并从那里获取数据。例如，参见 http://www.codethinked。 com/post/2010/01/27/NET-40-and-System_Collections_Concurrent_ConcurrentBag.aspx 对此有更详细的解释。
What the documentation tries to say is that it prefers the same thread producing and consuming data.
It has a fast path where when the same thread produces and consumes data, the data stays on that thread (think
[ThreadStatic]). However, when there is no data to consume on the same thread, it goes looking on other threads and gets data from there.Look e.g. at http://www.codethinked.com/post/2010/01/27/NET-40-and-System_Collections_Concurrent_ConcurrentBag.aspx for a more detailed explanation of this.