.Net中的并行编程-3.ConcurrentQueue实现与分析

     在上文《.Net中的并行编程-2.ConcurrentQueue的实现与分析》 中解释了无锁的相关概念，无独有偶BCL提供的ConcurrentQueue也是基于原子操作实现, 由于ConcurrentQueue的代码较多所以本文主要分析几个常用操作：

入队(EnQueue) 、出队(TryDequeue) 、是否为空(IsEmpty)、获取队列内元素数量(Count)。

一、ConcurrentQueue内部结构:

1.实现原理

众所周知，在普通的非线程安全队列有两种实现方式:

1.使用数组实现的循环队列。

2.使用链表实现的队列。

先看看两种方式的优劣：

     .Net Farmework中的普通队列Queue的实现使用了第一种方式，缺点是当队列空间不足会进行扩容，扩容的主要实现是开辟一个原始长度2倍的新数组，然后将原始数组里面的数据复制到新数组中，所以当扩容时就会产生不小的内存开销，在并发的环境中对性能的影响不可小视。当然在调用Queue的构造函数时可以指定默认空间的大小，但是一般情况下数据量是不可预测的，选大了会照成空间浪费，选小了会有复制内存的开销，而且队列扩容以后需要显示调用TrimToSize()方法才能回收掉不使用的内存空间。

     第二种链表实现方式虽然消除了空间浪费的问题但是又增加了GC的压力，当入队时会分配一个新节点，出队时要对该节点进行废弃，对于大量的出队入队操作时该实现方式性能不高。

    综合以上两种实现方式，在支持多线程并发出队并发入队的情况下，ConcurrentQueue使用了分段存储的概念（如上图所示），ConcurrentQueue分配内存时以段(Segment)为单位，一个段内部含有一个默认长度为32的数组和执行下一个段的指针，有个和Head和Tail指针分别指向了起始段和结束段（这种结构有点像操作系统的段式内存管理和页式内存管理策略）。这种分配内存的实现方式不但减轻的GC的压力而且调用者也不用显示的调用TrimToSize()方法回收内存（在某段内存为空时，会由GC来回收该段内存）。

2.Segment(段)内部结构

其实对于ConcurrentQueue的操作其实就是对Segment(数据段)的操作。

Segment可抽象出如下数据结构:

Segment内部主要方法:

    Segment内部和用数组实现的普通队列相当，只不过对于入队和出队操作使用了原子操作来防止多线程竞争问题，使用随机退让等技术保证活锁等问题，实现机制和ConcurrentStack差别不大，跟多TryAppend的实现细节在源码注释中已经阐述的非常清楚这里就再做不过多的解释。

二、入队操作

如上图所示，入队操作是在尾部的段中进行，当数据进入段内失败时会先进行一个回退操作然后再不断尝试直到成功，这里失败的原因（tail.Append(item)返回false）只有一个就是当该段内的空间不够时正在分配新的段，这段时间内会进入该段的元素会失败。

三、出队操作

如上图所示，出队失败时返回false 而不是像入队一样进行回退操作，因为出队失败的原因只有一个就是当队列内所有段的元素为空时，所以出队设计成了返回bool值的函数。

四、判断是否为空(IsEmpty)

  整个判断为O(1)的复杂度 主要有三种情况:

1. 头节点（段）不为空返回false

2. 头节点为空而且下一个节点也为空返回true

3. 头节点为空而且下一个节点不为空返回false，这种情况说明队列正在扩容，所以要自选等待扩容完毕时再次进行判断

五、获取队列内元素数量(Count)

     找到头节点的low的位置和尾节点的high的位置，由于每个段内记录了当前段在队列中的索引，所以很容易求出整个队列中元素的数量。

     跟ConcurrentStack一样 微软官方文档和注释中也说明：判断队列是否为空要使用IsEmpty属性而不是判断Count == 0  原因在于GetHeadTailPositions在大量数据入队和出队的过程中寻找头尾节点的位置是比较耗时的操作，要不断循环确定头尾节点的位置，所以判断队列是否为空还是使用IsEmpty属性。