C#线程安全容器剖析-优快云博客

最近写了个小程序用到了C#4.0中的线程安全集合。想起很久以前用C#2.0开发的时候写后台windows服务，为了利用多线程实现生产者和消费者模型，经常要封装一些线程安全的容器，比如泛型队列和字典等等。下面就结合部分MS的源码和自己的开发经验浅显地分析一下如何实现线程安全容器以及实现线程安全容器容易产生的问题。

一、ArrayList

在C#早期版本中已经实现了线程安全的ArrayList，可以通过下面的方式构造线程安全的数组列表：

var array = ArrayList.Synchronized(new ArrayList());

我们从Synchronized方法入手，分析它的源代码看是如何实现线程安全的：

Synchronized

继续跟进去，发现SyncArrayList是一个继承自ArrayList的私有类，内部线程安全方法的实现经过分析，很多都是像下面这样lock（注意是lock_root对象而不是数组列表实例对象）一下完事：

lock (this._root)

有心的你可以查看SyncArrayList的源码：

SyncArrayList

ArrayList线程安全实现过程小结：定义ArrayList的私有实现SyncArrayList，子类内部通过lock同步构造实现线程安全，在ArrayList中通过Synchronized对外间接调用子类。

二、Hashtable

同样，在C#早期版本中实现了线程安全的Hashtable，它也是早期开发中经常用到的缓存容器，可以通过下面的方式构造线程安全的哈希表：

var ht = Hashtable.Synchronized(new Hashtable());

同样地，我们从Synchronized方法入手，分析它的源代码看是如何实现线程安全的：

Synchronized

继续跟进去，发现SyncHashtable是一个继承自Hashtable和IEnumerable接口的私有类，内部线程安全方法的实现经过分析，很多都是像下面这样lock（注意是lock哈希表的SyncRoot Object实例对象而不是哈希表实例）一下完事：

lock (this._table.SyncRoot)

贴一下SyncHashtable的源码：

SyncHashtable

Hashtable线程安全实现过程小结：定义Hashtable的私有实现SyncHashtable，子类内部通过lock同步构造实现线程安全，在Hashtable中通过Synchronized对外间接调用子类。

三、4.0中的线程安全容器

1、ConcurrentQueue

从上面的实现分析来说，封装一个线程安全的容器看起来并不是什么难事，除了对线程安全容器的异常处理心有余悸，其他的似乎按步就班就可以了，不是吗？也许还有更高明的实现吧？

在4.0中，多了一个System.Collections.Concurrent命名空间，怀着忐忑的心情查看C#4.0其中的一个线程安全集合ConcurrentQueue的源码，发现它继承自IProducerConsumerCollection<T>, IEnumerable<T>, ICollection, IEnumerable接口，内部实现线程安全的时候，通过SpinWait和通过互锁构造（Interlocked）及SpinWait封装的Segment，间接实现了线程安全。Segment的实现比较复杂，和线程安全密切相关的方法就是TryXXX那几个方法，源码如下：

Segment

上面的代码稍微分析一下就知道它的作用。ConcurrentQueue的线程安全的Enqueue方法实现如下：

Enqueue

ConcurrentQueue<T>线程安全实现过程小结：继承接口，子类内部通过同步构造实现接口的线程安全，直接对外公开调用。

和ArrayList以及Hashtable线程安全的“曲折”实现有点不同，ConcurrentQueue<T>一开始就是朝着线程安全方向实现去的。它没有使用lock，因为大家知道使用lock性能略差，对于读和写操作，应该分开，不能一概而论。ConcurrentQueue<T>具体实现在性能和异常处理上应该已经考虑的更全面周到一点。

在我看来，ConcurrentQueue<T>线程安全的具体实现有多吸引人在其次，IProducerConsumerCollection<T>接口的抽象和提取非常值得称道，查看源码发现ConcurrentStack<T>和ConcurrentBag<T>也继承自该接口。<<CLR via C#>>一书中在谈到接口和抽象类的时候特别举了集合和流(Stream)的例子，微软为什么如此设计，想起来果然很有深意。

2、ConcurrentDictionary<TKey, TValue>

对于线程安全的泛型字典ConcurrentDictionary<TKey, TValue>，我们也可以查看它的源码看它的具体实现方式。看源码有1200多行，实现稍微复杂一些。我们仅从最简单的TryAdd方法分析：

TryAdd

其中内部方法TryAdd的主要实现如下：

TryAddInternal

同步构造Monitor瞬间吸引眼球，然后它的try…finally异常处理方式是不是也很眼熟？

四、如法炮制

如果让我来构造实现线程安全容器，最简单直接快速高效的方式就是参考ArrayList和 Hashtable，我们完全可以模仿它们的处理方式，通过继承一个容器，然后内部通过lock一个SyncRoot对象，中规中矩地实现framework中其他容器的线程安全。比如要实现线程安全的泛型队列Queue<T>，贴一下大致的伪代码：

SyncQueue

通过类继承我们可以得到泛型队列的所有特点，需要实现线程安全的地方只要按需重写它即可，对外调用也很简单，直接模仿ArrayList和Hashtable，添加Synchronized方法间接调用队列的子类即可，多么清晰简洁啊，关键时刻copy-paste也很有效嘛！

你可能觉得上面这样不动脑的方式似乎很傻很天真，但这绝对是一种正常人都能想到的思路，谁让MS的数组列表和哈希表就是这么实现的呢？

当然，我们还能想到的一种常见实现方式就是通过组合而不是类继承，实现的伪代码类似下面这样：

SyncQueue

上面这种方式和类继承的实现方式又有不同。它是通过在内部包装一个容器，然后按需进行方法、属性等等的线程安全处理，其他的所有特点依赖于那一个私有泛型队列组合对象queue。这种情况下泛型SyncQueue和泛型队列是组合关系，依赖性和耦合性更低，相对更灵活，封装性更好，是一种较为通用的设计，实际开发和使用中这种方式比较常见。

到这里，我们至少可以分析得出，实现一般的线程安全容器的思路至少有两种：类继承（内部实现偏向使用组合）和（或）组合，线程安全的地方只要通过framework的同步构造如lock、Interlocked等实现即可。

思考：如果让您实现线程安全容器，您优先会怎么实现呢？

五、线程安全并不真正安全

1、foreach遍历

CacheUtil缓存实现的伪代码如下:

CacheUtil

foreach的代码很简单，从哈希表构造的缓存中取数据并遍历，如下：

GetAndForeach

上面的遍历代码一般情况下是不会有问题的。但是在多线程修改哈希表的Value的情况下，上面的foreach遍历有可能发生异常。为什么呢？下面来简单分析一下：

从代码中可以看出来，哈希表中的Value存放的是IList类型，那么值所保存的应该是一个引用（也就是指针）。
（1）、当线程1通过索引器得到这个IList时，这个TryGet读取操作是线程安全的。接着线程1进行的操作是列表遍历。在foreach进行遍历不为空的List的时候，遍历的其实是存放在IList指针指向的引用。

（2）、在foreach遍历集合的时候，这时候线程2如果正好对哈希表的key所对应的Value进行修改，IList的指针所指向的引用改变了，所以线程1的遍历操作就会抛出异常。

这是一个简单而又经典的陷阱，在哈希表的MSDN线程安全块有一段说明：

Enumerating through a collection is intrinsically not a thread safe procedure. Even when a collection is synchronized, other threads can still modify the collection, which causes the enumerator to throw an exception. To guarantee thread safety during enumeration, you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.

2、通过索引取集合中的数据

列表通过索引取值，一个简单的示例代码如下：

GetFirstOrDefault

当列表中的元素为1个的时候，上面的操作非常容易进入一个无厘头的陷阱之中。有人会问怎么会有陷阱，你看取数据之前都判断了啊，逻辑正确了啊，这哪里还有问题吗？

按照类似于1中的分析，GetFirstOrDefault应该可以分为下面两步：

（1）线程1取数据，判断list.Count的时候发现列表内有1个元素，这一步线程安全，没有任何问题，然后准备返回索引为0的元素；

（2）线程2在线程1将要取索引为0的元素之前移除了列表中的唯一元素或者直接将list指向null，这样线程1通过索引取元素就抛出异常了。

3、如何保证容器数据操作安全？

从上面的两个示例，我们得知通常所看到的线程安全实际上并不一定安全。不安全的主要原因就是容器内的数据很容易被其他线程改变，或者可以简要概括为：一段时间差引发的血案。实际上，我们平时所做的业务系统，归根结底很多bug或者隐藏的缺陷都是由不起眼的一小段时间差引起的。

保证容器内的数据和操作都安全，一种简单而有效的方法就是将你所要进行的操作进行“事务”处理。比如示例1中哈希表的Value的遍历操作，通常情况下，我们分作两步：

（1）、（安全地）读取数据

（2）、（不安全地）遍历；

为了达到遍历操作不抛出异常，我们可以把两步合并为一步，抽象出一个线程安全的新方法TryGetAndEnumerate，这样可以保证线程安全地取数据和遍历，具体实现无非是lock一下SyncRoot类似的这种思路。但是这种线程安全的遍历可能代价很高，而且极其不通用。

线程安全集合容易产生的问题和解决方法，请参考JaredPar MSFT的Why are thread safe collections so hard?，这篇文章对设计一个线程安全的容器的指导原则是：

1、Don’t add an decision procedures(procedures like Count as decision procedures). They lead users down the path to bad code.
2、Methods which query the object can always fail and the API should reflect this.

实际上大家都知道利用事务处理思想多用TryXXX方法一般是没错的。

注意，在.net framework4.0中，使用ConcurrentQueue的TryDequeue方法会引发内存泄漏(Memory Leak)，但Dequeue方法则不会，这个bug微软已经在.net framework4.5中修复，可放心使用。关于ConcurrentQueue的TryDequeue引发内存泄漏的bug的讨论可参考这里。

本文转自JeffWong博客园博客，原文链接：http://www.cnblogs.com/jeffwongishandsome/archive/2012/09/09/2677293.html，如需转载请自行联系原作者