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

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

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

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

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

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

我很惊讶没有人提到使用LinkedList作为编写专业类的基础。

通常我们不需要各种集合类的完整API，如果您编写的主要是功能性副作用的免费代码，尽可能使用不可变的类，那么您实际上不会希望改变集合，以支持各种快照实现。

LinkedList solves some difficult problems of creating snapshot copies/clones of large collections. I also use it to create "threadsafe" enumerators to enumerate over the collection. I can cheat, because I know that I'm not changing the collection in any way other than appending, I can keep track of the list size, and only lock on changes to list size. Then my enumerator code simply enumerates from 0 to n for any thread that wants a "snapshot" of the append only collection, that will be guaranteed to represent a "snapshot" of the collection at any moment in time, regardless of what other threads are appending to the head of the collection.

我非常确定大多数需求通常非常简单，您只需要2或3个方法。编写一个真正的泛型库是非常困难的，但解决您自己的代码需求有时可以通过一两个技巧很容易。

LinkedList和优秀的函数式编程万岁。

干杯,……爱你们! 艾尔

附注:样本hack AppendOnly类在这里:https://github.com/goblinfactory/AppendOnly

你用ConcurrentList做什么?

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

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

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

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

在读的数量远远超过写的情况下，或者(无论多么频繁)写是非并发的情况下，在写时复制方法可能是合适的。

实现如下所示

lockless blazingly fast for concurrent reads, even while concurrent modifications are ongoing - no matter how long they take because "snapshots" are immutable, lockless atomicity is possible, i.e. var snap = _list; snap[snap.Count - 1]; will never (well, except for an empty list of course) throw, and you also get thread-safe enumeration with snapshot semantics for free.. how I LOVE immutability! implemented generically, applicable to any data structure and any type of modification dead simple, i.e. easy to test, debug, verify by reading the code usable in .Net 3.5

为了让写时复制工作，你必须让你的数据结构有效地保持不可变，也就是说，在你让它们对其他线程可用之后，任何人都不允许改变它们。当你想修改的时候，你

克隆结构 对克隆进行修改 原子地交换对修改后的克隆的引用

Code

static class CopyOnWriteSwapper
{
    public static void Swap<T>(ref T obj, Func<T, T> cloner, Action<T> op)
        where T : class
    {
        while (true)
        {
            var objBefore = Volatile.Read(ref obj);
            var newObj = cloner(objBefore);
            op(newObj);
            if (Interlocked.CompareExchange(ref obj, newObj, objBefore) == objBefore)
                return;
        }
    }
}

使用

CopyOnWriteSwapper.Swap(ref _myList,
    orig => new List<string>(orig),
    clone => clone.Add("asdf"));

如果你需要更多的性能，它将有助于非泛化方法，例如，为你想要的每一种类型的修改(添加，删除，…)创建一个方法，并硬编码函数指针克隆和op。

注意事项#1:确保没有人修改(假定)不可变的数据结构是你的责任。在泛型实现中我们无法阻止这种情况，但当专门化到List<T>时，可以使用List. asreadonly()来防止修改。

注意事项2 .注意列表中的值。上面的copy on write方法只保护它们的列表成员关系，但如果你放的不是字符串，而是一些其他可变对象，你必须注意线程安全(例如锁定)。但这与这个解决方案是正交的，例如，可变值的锁定可以很容易地使用而没有问题。你只需要意识到这一点。

注意事项#3如果您的数据结构很大，并且您经常修改它，那么从内存消耗和复制所涉及的CPU成本两方面考虑，全部在写时复制的方法可能是不可取的。在这种情况下，你可能想要使用MS的不可变集合。

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