为什么 ConcurrentBag.Net (4.0) 这么慢？我做错了吗？

Question

在开始项目之前，我编写了一个简单的测试来比较 (System.Collections.Concurrent) 中的 ConcurrentBag 相对于锁定和同步的性能。列表。我非常惊讶 ConcurrentBag 比使用简单 List 锁定慢 10 倍以上。据我了解，当读者和作者是同一线程时，ConcurrentBag 效果最好。但没想到它的性能会比传统锁差这么多。

我已经运行了一个测试，使用两个并行 for 循环写入和读取列表/包。然而，写入本身显示出巨大的差异：

private static void ConcurrentBagTest()
   {
        int collSize = 10000000;
        Stopwatch stopWatch = new Stopwatch();
        ConcurrentBag<int> bag1 = new ConcurrentBag<int>();

        stopWatch.Start();


        Parallel.For(0, collSize, delegate(int i)
        {
            bag1.Add(i);
        });


        stopWatch.Stop();
        Console.WriteLine("Elapsed Time = {0}", 
                          stopWatch.Elapsed.TotalSeconds);
 }

在我的机器上，这需要 3-4 秒才能运行，而此代码需要 0.5 - 0.9 秒：

       private static void LockCollTest()
       {
        int collSize = 10000000;
        object list1_lock=new object();
        List<int> lst1 = new List<int>(collSize);

        Stopwatch stopWatch = new Stopwatch();
        stopWatch.Start();


        Parallel.For(0, collSize, delegate(int i)
            {
                lock(list1_lock)
                {
                    lst1.Add(i);
                }
            });

        stopWatch.Stop();
        Console.WriteLine("Elapsed = {0}", 
                          stopWatch.Elapsed.TotalSeconds);
       }

正如我提到的，进行并发读取和写入并不能帮助并发袋测试。我做错了什么或者这个数据结构真的很慢吗？

[编辑] - 我删除了任务，因为我在这里不需要它们（完整代码有另一个任务读取）

[编辑] 非常感谢您的回答。我很难选择“正确的答案”，因为它似乎是几个答案的混合体。

正如 Michael Goldshteyn 指出的那样，速度实际上取决于数据。 Darin 指出，应该有更多的争用，让 ConcurrentBag 更快，而 Parallel.For 不一定启动相同数量的线程。需要注意的一点是，不要在锁内做任何不必要的事情。在上面的情况下，除了将值分配给临时变量之外，我没有看到自己在锁内执行任何操作。

此外，sixlettervariables 指出，碰巧正在运行的线程数量也可能会影响结果，尽管我尝试以相反的顺序运行原始测试，并且 ConcurrentBag 仍然较慢。

我从 15 个任务开始进行了一些测试，结果取决于集合大小等。然而，对于多达 100 万次插入，ConcurrentBag 的性能几乎与锁定列表一样好，甚至更好。超过 100 万时，锁定有时似乎要快得多，但我的项目可能永远不会有更大的数据结构。 这是我运行的代码：

        int collSize = 1000000;
        object list1_lock=new object();
        List<int> lst1 = new List<int>();
        ConcurrentBag<int> concBag = new ConcurrentBag<int>();
        int numTasks = 15;

        int i = 0;

        Stopwatch sWatch = new Stopwatch();
        sWatch.Start();
         //First, try locks
        Task.WaitAll(Enumerable.Range(1, numTasks)
           .Select(x => Task.Factory.StartNew(() =>
            {
                for (i = 0; i < collSize / numTasks; i++)
                {
                    lock (list1_lock)
                    {
                        lst1.Add(x);
                    }
                }
            })).ToArray());

        sWatch.Stop();
        Console.WriteLine("lock test. Elapsed = {0}", 
            sWatch.Elapsed.TotalSeconds);

        // now try concurrentBag
        sWatch.Restart();
        Task.WaitAll(Enumerable.Range(1, numTasks).
                Select(x => Task.Factory.StartNew(() =>
            {
                for (i = 0; i < collSize / numTasks; i++)
                {
                    concBag.Add(x);
                }
            })).ToArray());

        sWatch.Stop();
        Console.WriteLine("Conc Bag test. Elapsed = {0}",
               sWatch.Elapsed.TotalSeconds);

Answer 1

让我问您这个问题：您拥有一个不断向集合添加内容并且从不读取集合的应用程序，这有多现实？这样的收藏有什么用呢？ （这不是一个纯粹的反问。我可以想象有一些用途，例如，您只在关闭时（用于日志记录）或在用户请求时从集合中读取。我相信这些场景是不过，相当罕见。）

这就是您的代码正在模拟的内容。除了列表必须调整其内部数组大小的偶尔情况外，调用 List.Add 的速度都快如闪电；但这会被很快发生的所有其他添加所消除。因此，在这种情况下，您不太可能看到大量的争用，尤其在具有例如 8 个核心的个人电脑上进行测试（正如您在某处评论中所说的那样）。 也许您可能会在 24 核计算机等设备上看到更多争用，其中许多内核可能会同时尝试将内容添加到列表中。

争用更有可能发生在您从收藏中阅读的地方，尤其是在。在 foreach 循环（或相当于 foreach 底层的 LINQ 查询）中，需要锁定整个操作，以便您在迭代集合时不会修改集合。

如果您能够真实地重现此场景，我相信您会看到 ConcurrentBag 的规模比当前测试显示的要好得多。

---

更新：这里是我编写的一个程序，用于在上述场景中比较这些集合（多个作者，多个读者）。使用集合大小为 10000 和 8 个读者线程运行 25 次试验，我得到了以下结果：

Took 529.0095 ms to add 10000 elements to a List<double> with 8 reader threads.
Took 39.5237 ms to add 10000 elements to a ConcurrentBag<double> with 8 reader threads.
Took 309.4475 ms to add 10000 elements to a List<double> with 8 reader threads.
Took 81.1967 ms to add 10000 elements to a ConcurrentBag<double> with 8 reader threads.
Took 228.7669 ms to add 10000 elements to a List<double> with 8 reader threads.
Took 164.8376 ms to add 10000 elements to a ConcurrentBag<double> with 8 reader threads.
[ ... ]
Average list time: 176.072456 ms.
Average bag time: 59.603656 ms.

很明显，这取决于您对这些集合所做的操作。

Answer 2

.NET Framework 4 中似乎有一个 bug，微软在 4.5 中修复了这个错误，看来他们没想到 ConcurrentBag 会被大量使用。

请参阅以下 Ayende 帖子了解更多信息

http ://ayende.com/blog/156097/the-high-cost-of-concurrentbag-in-net-4-0

Answer 3

作为一般答案：

• 如果数据争用很少或没有（即锁），使用锁定的并发集合可以非常快。这是因为这样的集合类通常是使用非常便宜的锁定原语构建的，尤其是在不满足时。
• 无锁集合可能会更慢，因为避免锁的技巧以及其他瓶颈（例如错误共享、实现其无锁性质所需的复杂性导致缓存未命中等）......

总而言之，决定哪种方式更快的是高度依赖于所使用的数据结构以及其他问题中的锁争用量（例如，共享/独占类型安排中的读取器数量与写入器数量）。

你的具体例子有很高的争议程度，所以我必须说我对这种行为感到惊讶。另一方面，保留锁时完成的工作量非常小，所以毕竟锁本身可能很少有争用。 ConcurrentBag 并发处理的实现也可能存在缺陷，这使得您的特定示例（频繁插入且没有读取）成为一个糟糕的用例。

Answer 4

使用 MS 的竞争可视化工具查看该程序表明，与简单锁定 List 相比，ConcurrentBag 与并行插入相关的成本要高得多。我注意到的一件事是，启动第一个 ConcurrentBag 运行（冷运行）似乎会产生与启动 6 个线程（在我的机器上使用）相关的成本。然后将 5 或 6 个线程与 List 代码一起使用，这样速度更快（热运行）。在列表后添加另一个 ConcurrentBag 运行表明它比第一次（热运行）花费的时间更少。

从我在争用中看到的情况来看，ConcurrentBag实现分配内存花费了大量时间。从 List 代码中删除显式大小分配会减慢速度，但不足以产生影响。

编辑：似乎是 ConcurrentBag 在内部为每个 Thread.CurrentThread 保留一个列表，锁定 2-4 次，具体取决于是否它在一个新线程上运行，并至少执行一个 Interlocked.Exchange。正如 MSDN 中所述：“针对同一线程同时生成和使用存储在包中的数据的场景进行了优化。”这是与原始列表相比性能下降的最可能的解释。

Answer 5

这个问题已经在 .NET 4.5 中得到解决。根本问题是 ConcurrentBag 使用的 ThreadLocal 没有预期会有很多实例。该问题已得到修复，现在可以运行得相当快。

来源 - . NET 4.0

Answer 6

正如 @Darin-Dimitrov 所说，我怀疑您的 Parallel.For 实际上并没有在两个结果中产生相同数量的线程。尝试手动创建 N 个线程，以确保在这两种情况下您确实看到了线程争用。

Answer 7

您基本上只有很少的并发写入并且没有争用（Parallel.For 并不一定意味着很多线程）。尝试并行写入，您将观察到不同的结果：

class Program
{
    private static object list1_lock = new object();
    private const int collSize = 1000;

    static void Main()
    {
        ConcurrentBagTest();
        LockCollTest();
    }

    private static void ConcurrentBagTest()
    {
        var bag1 = new ConcurrentBag<int>();
        var stopWatch = Stopwatch.StartNew();
        Task.WaitAll(Enumerable.Range(1, collSize).Select(x => Task.Factory.StartNew(() =>
        {
            Thread.Sleep(5);
            bag1.Add(x);
        })).ToArray());
        stopWatch.Stop();
        Console.WriteLine("Elapsed Time = {0}", stopWatch.Elapsed.TotalSeconds);
    }

    private static void LockCollTest()
    {
        var lst1 = new List<int>(collSize);
        var stopWatch = Stopwatch.StartNew();
        Task.WaitAll(Enumerable.Range(1, collSize).Select(x => Task.Factory.StartNew(() =>
        {
            lock (list1_lock)
            {
                Thread.Sleep(5);
                lst1.Add(x);
            }
        })).ToArray());
        stopWatch.Stop();
        Console.WriteLine("Elapsed = {0}", stopWatch.Elapsed.TotalSeconds);
    }
}

Answer 8

我的猜测是锁不会经历太多争用。我建议阅读以下文章： Java 理论与实践：有缺陷的微基准剖析。本文讨论了锁微基准测试。正如文章中所述，在这种情况下需要考虑很多事情。

Answer 9

看到他们两者之间的扩展将会很有趣。

两个问题

1）bag 与 list 的读取速度有多快，记得在 list 上加锁

2）当另一个线程正在写入时，bag 与 list 的读取速度有多快

Answer 10

由于循环体很小，您可以尝试使用 Partitioner 类的 Create 方法...

这使您能够提供
委托体的顺序循环，
以便仅调用委托
每个分区一次，而不是一次
每次迭代

如何：加速小循环体

Answer 11

看起来 ConcurrentBag 只是比其他并发集合慢。

我认为这是一个实现问题 - ANTS Profiler 显示它在几个地方陷入困境 - 包括数组副本。

使用并发字典的速度要快数千倍。