为什么 ConcurrentBag 不支持实现 ICollection？

Question

我有一个方法，它采用 IList 并向其中添加内容。我想传递一个 ConcurrentBag 在某些情况下，但它不实现 IList 或 ICollection，仅实现非通用 ICollection，它没有 Add 方法。

现在，我明白为什么它不能（也许）实现 IList - 它不是一个有序集合，因此它拥有索引器是没有意义的。但我没有发现任何 ICollection 方法。

那么，为什么呢？而且，.NET 中是否有线程安全的集合可以实现更健壮的接口？

Answer 1

List 不是并发的，因此它可以实现 ICollection，它为您提供了一对方法 Contains 和 添加。如果 Contains 返回 false，您可以安全地调用 Add，知道它会成功。

ConcurrentBag 是并发的，因此它无法实现 ICollection，因为 Contains 返回的答案在您调用时可能无效添加。相反，它实现了 IProducerConsumerCollection，它提供了单一方法 TryAdd，该方法可以完成 Contains 和 Add 的工作。 。

因此，不幸的是，您希望对两个都是集合但不共享公共接口的事物进行操作。有很多方法可以解决这个问题，但当 API 与这些相似时，我的首选方法是为两个接口提供方法重载，然后使用 lambda 表达式来制作委托，这些委托使用各自的方法为每个接口执行相同的操作。然后，您可以使用该委托来代替执行几乎常见操作的位置。

这是一个简单的例子：

public class Processor
{
    /// <summary>
    /// Process a traditional collection.
    /// </summary>
    /// <param name="collection">The collection.</param>
    public void Process(ICollection<string> collection)
    {
        Process(item =>
            {
                if (collection.Contains(item))
                    return false;
                collection.Add(item);
                return true;
            });
    }

    /// <summary>
    /// Process a concurrent collection.
    /// </summary>
    /// <param name="collection">The collection.</param>
    public void Process(IProducerConsumerCollection<string> collection)
    {
        Process(item => collection.TryAdd(item));
    }

    /// <summary>
    /// Common processing.
    /// </summary>
    /// <param name="addFunc">A func to add the item to a collection</param>
    private void Process(Func<string, bool> addFunc)
    {
        var item = "new item";
        if (!addFunc(item))
            throw new InvalidOperationException("duplicate item");
    }
}

Answer 2

有 SynchronizedCollection，实现了 IList< T> 和 ICollection 以及 IEnumerable。

Answer 3

为什么 ConcurrentBag 不实现 ICollection？

因为它不能。具体来说，该方法的功能 ConcurrentBag 不支持 >ICollection.Remove。您无法从此集合中删除特定项目。您只能“采取” 一个项目，由集合本身决定 哪一项给你。

ConcurrentBag 是一个专门的集合，旨在支持特定场景（混合生产者-消费者场景，主要是 对象池）。其内部结构的选择是为了最佳地支持这些场景。 ConcurrentBag 在内部维护一个 WorkStealingQueue （内部类）。项目始终被推入当前线程队列的尾部。项目将从当前线程队列的尾部弹出，除非其为空，在这种情况下，项目会从另一个线程队列的头部“窃取”。从本地队列中推送和弹出是无锁的。这就是该集合设计的最佳用途：从本地缓冲区存储和检索项目，而不与其他线程争用锁。编写这样的无锁代码非常困难。如果您看到 此类的源代码，它会让你大吃一惊。如果允许另一个线程从 WorkStealingQueue 中的任何位置（而不仅仅是头部）窃取项目，那么此核心功能是否可以保持无锁状态？我不知道答案，但如果我不得不猜测，基于 WorkStealingQueue.TryLocalPeek 方法我会说不：

// It is possible to enable lock-free peeks, following the same general approach
// that's used in TryLocalPop.  However, peeks are more complicated as we can't
// do the same kind of index reservation that's done in TryLocalPop; doing so could
// end up making a steal think that no item is available, even when one is. To do
// it correctly, then, we'd need to add spinning to TrySteal in case of a concurrent
// peek happening. With a lock, the common case (no contention with steals) will
// effectively only incur two interlocked operations (entering/exiting the lock) instead
// of one (setting Peek as the _currentOp).  Combined with Peeks on a bag being rare,
// for now we'll use the simpler/safer code.

所以 < a href="https://learn.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentbag-1.trypeek" rel="nofollow noreferrer">TryPeek< /a> 使用锁，不是因为使其无锁是不可能的，而是因为它很难。想象一下，如果可以从队列中的任意位置删除项目会有多困难。 Remove 功能正是需要这样的功能。

Answer 4

...

using System.Linq;


bool result = MyConcurrentBag.Contains("Item");

提供某种 ICollection 功能。