异步的同步构造
任何使用了内核模式的线程同步构造，我都不是特别喜欢。因为所有这些基元都会阻塞一个线程的运行。创建线程的代价很大。创建了不用，这于情于理说不通。
创建了reader-writer锁的情况，如果写锁被长时间占有，那么其他的读请求线程都会被阻塞，随着越来越多客户端请求到达，服务器创建了更多的线程，而他们被创建出来的目的就是让他们在锁上停止运行。更糟糕的是，一旦writer锁释放，所有读线程都同时解除阻塞并开始执行。现在，又变成大量的线程试图在相对数量很少的cpu上运行。所以，windows开始在线程之间不同的进行上下文切换，而真正的工作时间却很少。
锁很流行，但长时间拥有会带来巨大的伸缩性问题。如果代码能通过异步的同步构造指出他想要一个锁，那么会非常有用。在这种情况下，如果线程得不到锁，可直接返回并执行其他工作，而不必在那里傻傻地阻塞。
SemaphoreSlim通过waitAsync实现了这个思路
public Task<bool> WaitAsync(int millisecondsTimeout, CancellationToken cancellationToken);
使用await asynclock.WaitAsync()就可以实现刚才说的情境。
但如果是reader-writer呢？.net framework提供了concurrentExclusiveSchedulerPair类。实例代码如下：
private static void ConcurrentExclusiveSchedulerDemo() { var cesp = new ConcurrentExclusiveSchedulerPair(); var tfExclusive = new TaskFactory(cesp.ExclusiveScheduler); var tfConcurrent = new TaskFactory(cesp.ConcurrentScheduler); for (int i = 0; i < 5; i++) { var exclusive = i < 2; (exclusive ? tfExclusive : tfConcurrent).StartNew(() => { Console.WriteLine("{0} access",exclusive?"exclusive":"concurrent"); //这里进行独占写入或者并发读取操作 }); } }
遗憾的是，framework没有提供鞠咏reader-writer语义的异步锁。所以我们可以自己构建一个，如下：
public sealed class AsyncOneManyLock { #region 锁的代码 //自旋锁不要用readonly private SpinLock m_lock = new SpinLock(true); private void Lock() { bool taken = false;m_lock.Enter(ref taken); } private void Unlock() { m_lock.Exit(); } #endregion #region 锁的状态和辅助方法 private Int32 m_state = 0; private bool IsFree { get { return m_state == 0; } } private bool IsOwnedByWriter { get { return m_state == -1; } } private bool IsOwnedByReader { get { return m_state > 0; } } private Int32 AddReaders(Int32 count) { return m_state += count; } private Int32 SubtractReader() { return --m_state; } private void MakeWriter() { m_state = -1; } private void MakeFree() { m_state = 0; } #endregion //目的实在非竞态条件时增强性能和减少内存消耗 private readonly Task m_noContentionAccessGranter; //每个等待的writer都通过他们在这里排队的TaskCompletionSource来唤醒 private readonly Queue<TaskCompletionSource<Object>> m_qWaitingWriters = new Queue<TaskCompletionSource<object>>(); //一个TaskCompletionSource收到信号，所有等待的reader都唤醒 private TaskCompletionSource<Object> m_waitingReaderSignal = new TaskCompletionSource<object>(); private Int32 m_numWaitingReaders = 0; public AsyncOneManyLock() { //创建一个返回null的任务 m_noContentionAccessGranter = Task.FromResult<Object>(null); } public Task WaitAsync(OneManyMode mode) { Task accressGranter = m_noContentionAccessGranter;//假定无竞争 Lock () ; switch (mode) { case OneManyMode.Exclusive: if (IsFree) { MakeWriter();//无竞争 } else { //有竞争 var tcs = new TaskCompletionSource<Object>(); m_qWaitingWriters.Enqueue(tcs); accressGranter = tcs.Task; } break; case OneManyMode.Shared: if (IsFree||(IsOwnedByReader&&m_qWaitingWriters.Count==0)) { AddReaders(1);//无竞争 } else { //有竞争,递增等待的reader数量，并返回reader任务使reader等待。 m_numWaitingReaders++; accressGranter = m_waitingReaderSignal.Task.ContinueWith(t => t.Result); } break; } Unlock(); return accressGranter; } public void Release() { //嘉定没有代码被释放 TaskCompletionSource<Object> accessGranter = null; Lock () ; if (IsOwnedByWriter) { MakeFree(); } else { SubtractReader(); } if (IsFree) { //如果自由，唤醒一个等待的writer或所有等待的readers if (m_qWaitingWriters.Count>0) { MakeWriter(); accessGranter = m_qWaitingWriters.Dequeue(); } else if (m_numWaitingReaders>0) { AddReaders(m_numWaitingReaders); m_numWaitingReaders = 0; accessGranter = m_waitingReaderSignal; //为将来需要等待的readers创建一个新的tcs m_waitingReaderSignal = new TaskCompletionSource<object>(); } } Unlock(); //唤醒锁外面的writer/reader,减少竞争几率以提高性能 if (accessGranter!=null) { accessGranter.SetResult(null); } } }
上述代码永远不会阻塞线程。原因是内部没有没有很实用任何内核构造。这里确实使用了一个SpinLock，它在内部使用了用户模式构造。但是他的执行时间很短，WaitAsync方法里，只是一些整数计算和比较，这也符合只有执行时间很短的代码段才可以用自旋锁来保护。所以使用一个spinLock来保护对queue的访问，还是比较合适的。
并发集合类
FCL自带4个线程安全的集合类，全部在System.Collections.Concurrent命名空间中定义。它们是ConcurrentStack、concurrentQueue、concurrentDictionary、concurrentBag。
所有这些集合都是“非阻塞”的，换而言之，如果一个线程试图提取一个不存在的元素（数据项），线程会立即返回；线程不会阻塞在那里，等着一个元素的出现。正是由于这个原因，所以如果获取了一个数据项，像tryDequeue,tryPop,tryTake和tryGetValue这样的方法全部返回true;否则返回false。
一个集合“非阻塞”，并不意味着他就不需要锁了。concurrentDictionary类在内部使用了Monitor。但是，对集合中的项进行操作时，锁只被占有极短的时间。concurrentQueue和ConcurrentStack确实不需要锁；他们两个在内部都使用interlocked的方法来操纵集合。一个concurrentBag对象由大量迷你集合对象构成，每个线程一个。线程将一个项添加到bag中时，就用interlocked的方法将这个项添加到调用线程的迷你集合中。一个线程视图从bag中提取一个元素时，bag就检查调用线程的迷你集合，试图从中取出数据项。如果数据项在哪里，就用一个interlocked方法提取这个项。如果不在，就在内部获取一个monitor，以便从 线程的迷你集合提取一个项。这称为一个线程从另一个线程“窃取”一个数据项。
注意，所有并发集合类都提供了getEnumerator方法，他一般用于C#的foreach语句，但也可用于Linq。对于concurrentQueue、ConcurrentStack和concurrentBag类，getEnumerator方法获取集合内容的一个“快照”，并从这个快照中返回元素；实际集合内容可能在使用快照枚举时发生改变。concurrentDictionary的getEnumerator的该方法不获取他内容的快照。因此，在枚举字典期间，字典的内容可能改变。还要注意，count属性返回的是查询时集合中的元素数量，如果其他线程同时正在集合中增删，这个计数可能马上就变得不正确。
ConcurrentStack、concurrentQueue、concurrentBag都实现了IProducerConsumerCollection接口，实现了这个接口的任何类都能转变成一个阻塞集合，不过，尽量不使用这种阻塞集合。
这里我们重点介绍下concurrentDictionary。
ConcurrentDictionary
这里我对.net core中ConcurrentDictionary源码进行了分析，里面采用了Volatile.Read和write，然后也使用了lock这种混合锁，而且还定义了更细颗粒度的锁。所以多线程使用ConcurrentDictionary集合还是比较好的选择。
TryRemove
这个方法会调用内部私用的TryRemoveInternal
private bool TryRemoveInternal(TKey key, out TValue value, bool matchValue, TValue oldValue) { int hashcode = _comparer.GetHashCode(key); while (true) { Tables tables = _tables; int bucketNo, lockNo; //这里获取桶的索引和锁的索引，注意，锁的索引和桶未必是同一个值，具体算法看源码。 GetBucketAndLockNo(hashcode, out bucketNo, out lockNo, tables._buckets.Length, tables._locks.Length); //这里锁住的只是对应这个index指向的锁，而不是所有锁。 lock (tables._locks[lockNo]) { //这里table可能被重新分配，所以这里再次获取，看得到的是不是同一个table // If the table just got resized, we may not be holding the right lock, and must retry. // This should be a rare occurrence. if (tables != _tables) { continue; } Node prev = null; //这里同一个桶，可能因为连地址，有很多值，所以要对比key for (Node curr = tables._buckets[bucketNo]; curr != null; curr = curr._next) { Debug.Assert((prev == null && curr == tables._buckets[bucketNo]) || prev._next == curr); //对比是不是要删除的的那个元素 if (hashcode == curr._hashcode && _comparer.Equals(curr._key, key)) { if (matchValue) { bool valuesMatch = EqualityComparer<TValue>.Default.Equals(oldValue, curr._value); if (!valuesMatch) { value = default(TValue); return false; } } //执行删除，判断有没有上一个节点。然后修改节点指针或地址。 if (prev == null) { Volatile.Write<Node>(ref tables._buckets[bucketNo], curr._next); } else { prev._next = curr._next; } value = curr._value; tables._countPerLock[lockNo]--; return true; } prev = curr; } } value = default(TValue); return false; } }
TryAdd
这个方法会调用内部私用的TryAddInternal
TryAddInternal(key, _comparer.GetHashCode(key), value, false, true, out dummy);
/// <summary> /// Shared internal implementation for inserts and updates. /// If key exists, we always return false; and if updateIfExists == true we force update with value; /// If key doesn't exist, we always add value and return true; /// </summary> private bool TryAddInternal(TKey key, int hashcode, TValue value, bool updateIfExists, bool acquireLock, out TValue resultingValue) { Debug.Assert(_comparer.GetHashCode(key) == hashcode); while (true) { int bucketNo, lockNo; Tables tables = _tables; //老方法了，不多说，获取hash索引和锁索引 GetBucketAndLockNo(hashcode, out bucketNo, out lockNo, tables._buckets.Length, tables._locks.Length); bool resizeDesired = false; bool lockTaken = false; try { //这里都是true的，所以会获取锁 if (acquireLock) Monitor.Enter(tables._locks[lockNo], ref lockTaken); // If the table just got resized, we may not be holding the right lock, and must retry. // This should be a rare occurrence. if (tables != _tables) { continue; } // Try to find this key in the bucket Node prev = null; //查看对应的桶里， for (Node node = tables._buckets[bucketNo]; node != null; node = node._next) { Debug.Assert((prev == null && node == tables._buckets[bucketNo]) || prev._next == node); //查看有没有相同的key值，有就返回false if (hashcode == node._hashcode && _comparer.Equals(node._key, key)) { // The key was found in the dictionary. If updates are allowed, update the value for that key. // We need to create a new node for the update, in order to support TValue types that cannot // be written atomically, since lock-free reads may be happening concurrently. //这个应该是addorupdate使用的，存在就更新。 if (updateIfExists) { if (s_isValueWriteAtomic) { node._value = value; } else { Node newNode = new Node(node._key, value, hashcode, node._next); if (prev == null) { Volatile.Write(ref tables._buckets[bucketNo], newNode); } else { prev._next = newNode; } } resultingValue = value; } else { resultingValue = node._value; } return false; } prev = node; } // The key was not found in the bucket. Insert the key-value pair. Volatile.Write<Node>(ref tables._buckets[bucketNo], new Node(key, value, hashcode, tables._buckets[bucketNo])); //这里checked检查是否存在溢出。 checked { tables._countPerLock[lockNo]++; } // If the number of elements guarded by this lock has exceeded the budget, resize the bucket table. // It is also possible that GrowTable will increase the budget but won't resize the bucket table. // That happens if the bucket table is found to be poorly utilized due to a bad hash function. // _budget是 The maximum number of elements per lock before a resize operation is triggered if (tables._countPerLock[lockNo] > _budget) { resizeDesired = true; } } finally { if (lockTaken) Monitor.Exit(tables._locks[lockNo]); } // The fact that we got here means that we just performed an insertion. If necessary, we will grow the table. // // Concurrency notes: // - Notice that we are not holding any locks at when calling GrowTable. This is necessary to prevent deadlocks. //As a result, it is possible that GrowTable will be called unnecessarily. But, GrowTable will obtain lock 0 // and then verify that the table we passed to it as the argument is still the current table. if (resizeDesired) { GrowTable(tables); } //赋值 resultingValue = value; return true; } }
TryGetValue
TryGetValueInternal(key, _comparer.GetHashCode(key), out value);
private bool TryGetValueInternal(TKey key, int hashcode, out TValue value) { Debug.Assert(_comparer.GetHashCode(key) == hashcode); //用本地变量保存这个table的快照。 // We must capture the _buckets field in a local variable. It is set to a new table on each table resize. Tables tables = _tables; int bucketNo = GetBucket(hashcode, tables._buckets.Length); // We can get away w/out a lock here. // The Volatile.Read ensures that we have a copy of the reference to tables._buckets[bucketNo]. // This protects us from reading fields ('_hashcode', '_key', '_value' and '_next') of different instances. Node n = Volatile.Read<Node>(ref tables._buckets[bucketNo]); //如果key相符 ，赋值，不然继续寻找下一个。 while (n != null) { if (hashcode == n._hashcode && _comparer.Equals(n._key, key)) { value = n._value; return true; } n = n._next; } value = default(TValue);//没找到就赋默认值 return false; }