你用ConcurrentList做什么?

在线程世界中，随机访问容器的概念并不像它看起来那样有用。该声明

  if (i < MyConcurrentList.Count)  
      x = MyConcurrentList[i]; 

总的来说仍然不是线程安全的。

与其创建ConcurrentList，不如尝试使用现有的内容构建解决方案。最常见的类是ConcurrentBag，尤其是BlockingCollection。

在顺序执行的代码中，使用的数据结构与(编写良好的)并发执行的代码不同。原因是顺序代码隐含着隐式的顺序。然而并发代码并不意味着任何顺序;更妙的是，它暗示着缺乏任何明确的秩序!

因此，具有隐含顺序的数据结构(如List)对于解决并发问题不是很有用。列表意味着顺序，但它并没有清楚地定义这个顺序是什么。因此，操作列表的代码的执行顺序将(在某种程度上)决定列表的隐式顺序，这与有效的并发解决方案直接冲突。

记住，并发是一个数据问题，而不是代码问题!您不能先实现代码(或重写现有的顺序代码)，然后获得设计良好的并发解决方案。您需要首先设计数据结构，同时记住在并发系统中不存在隐式排序。

你用ConcurrentList做什么?

在线程世界中，随机访问容器的概念并不像它看起来那样有用。该声明

  if (i < MyConcurrentList.Count)  
      x = MyConcurrentList[i]; 

总的来说仍然不是线程安全的。

与其创建ConcurrentList，不如尝试使用现有的内容构建解决方案。最常见的类是ConcurrentBag，尤其是BlockingCollection。

ConcurrentList(作为一个可调整大小的数组，而不是一个链表)不容易用非阻塞操作编写。它的API不能很好地转换为“并发”版本。

如果不需要处理太多项，无锁复制和写入方法非常有效。 下面是我写的一个类:

public class CopyAndWriteList<T>
{
    public static List<T> Clear(List<T> list)
    {
        var a = new List<T>(list);
        a.Clear();
        return a;
    }

    public static List<T> Add(List<T> list, T item)
    {
        var a = new List<T>(list);
        a.Add(item);
        return a;
    }

    public static List<T> RemoveAt(List<T> list, int index)
    {
        var a = new List<T>(list);
        a.RemoveAt(index);
        return a;
    }

    public static List<T> Remove(List<T> list, T item)
    {
        var a = new List<T>(list);
        a.Remove(item);
        return a;
    }

}

使用示例: orders_BUY = CopyAndWriteList.Clear(orders_BUY);

System.Collections.Generic。List<t>对于多个读取器来说已经是线程安全的。试图使它对多个写入器是线程安全的是没有意义的。(原因Henk和Stephen已经提到了)