减小锁定的粒度：C#实现基于关键字（key）的锁定
问题描述
最近需要实现一个API，方法签名（的抽象版本）类似于
void Update(string id)
API将在多线程环境下被调用，需满足：
- 如果多个调用线程传入相同的id，则它们必须被串行化——一个线程工作，其他线程阻塞，前一个线程调用完毕后，后一个线程才开始工作，依此类推。
- 若传入的id不同，则各线程可并行执行。
场景与数据库的行锁定非常相似——锁定对于更新相同的行的多个请求是互斥的，而更新不同的行则可同时进行。
不过这回我们没有数据库的帮忙，同时，程序非常的小（其实是客户端程序），所以我们希望解决方案也非常小巧。
基本思路
说道多线程串行化，立刻想到的就是锁，但是如果简单的 lock (someGlobalObject) 会时所有的线程串行化，这不满足需求。
我们仍然需要锁，不过锁的作用范围更小，于是，需求被转化为小粒度锁定的实现，这个锁范围满足：
- 相同的id共享同一个锁对象。
- 不同的id使用不同的锁对象。
实现
思路确定了，进入实现阶段。
这里为了便于测试，定义一个接口，实际的场景中并不需要这个接口。
1 interface IKeyLockEngine 2 { 3 void Invoke(string key, Action act); 4 }
实现方案1：使用字典记录id与锁对象
“id -> 锁对象”的映射场景很容易让人想到字典（哈希表）——使用一个Dictionary存放正在被使用的id（作为key）和锁对象（作为value），若已经没有线程使用某一id调用API，则从字典中移除该id。
对于每次传入的id做一次检验，将获得以下两种情况：
- id不存在于字典中——没有线程正在使用该id调用API，为该id分配一个锁对象，并将id写入字典；
- id存在于字典中——已有线程正在使用该id调用API，从字典中取出锁对象并使用之；
那么，在有多个线程使用同一个id的情况下，如何知道何时需要从字典中移除该id呢？这里引入一个计数器来解决。
此方案的实现代码如下：
1 public class DictionaryBasedKeyLockEngine : IKeyLockEngine 2 { 3 private static readonly object SyncRoot = new object(); 4 private static readonly Dictionary<string, LockUnit> Locks = new Dictionary<string, LockUnit>(); 5 6 public void Invoke(string key, Action act) 7 { 8 LockUnit lockUnit; 9 10 lock (SyncRoot) 11 { 12 if (Locks.TryGetValue(key, out lockUnit)) 13 { 14 lockUnit.WaitCounter++; 15 } 16 else 17 { 18 lockUnit = new LockUnit(); 19 Locks.Add(key, lockUnit); 20 } 21 } 22 23 try 24 { 25 Monitor.Enter(lockUnit); 26 act(); 27 } 28 finally 29 { 30 lock (SyncRoot) 31 { 32 lockUnit.WaitCounter--; 33 if (lockUnit.WaitCounter == 0) 34 Locks.Remove(key); 35 } 36 Monitor.Exit(lockUnit); 37 } 38 } 39 40 private class LockUnit 41 { 42 public int WaitCounter; 43 } 44 }
上面使用了内部类LockUnit作为锁定对象的类型，并保持一个计数器WaitCounter，其记录了当前使用该锁对象的线程的数量，当计数器归0，就是从字典里移除id的时候了。
因为字典数据是各线程共享的，为了能安全的操作字典，需要一个额外的锁对象SyncRoot，因此实际上有两层的锁定。
实现方案2：互斥体
另一种实现方案使用了.net Framework提供的互斥体 System.Threading.Mutex，利用其可命名的特性，将id作为互斥体的名称，很好的实现了id到锁对象的映射。
1 public class MutexBasedKeyLockEngine : IKeyLockEngine 2 { 3 private static readonly string NameHeader = Guid.NewGuid().ToString("N"); 4 5 public void Invoke(string key, Action act) 6 { 7 var m = new Mutex(false, NameHeader + key); 8 try 9 { 10 m.WaitOne(); 11 act(); 12 } 13 finally 14 { 15 m.ReleaseMutex(); 16 } 17 } 18 }
因为互斥体是在整个操作系统中有效的，作用域非常大，为了避免key与本实现外部所注册的互斥体冲突，定义了一个Guid（几乎不会重复）作为互斥体名称的前缀，以避免此问题。
其他方案：
使用旗语 System.Threading.Semaphore，与互斥体相似，不过还多一个功能，可以控制并发的数量，因为应用场景下没有此要求，在此便不再讨论。
性能分析
我们来比较上述两种方案的性能，重点比较id的重复率对于性能的影响，测试代码如下，代码中使用了老赵的性能计数器CodeTimer。
1 static void Main() 2 { 3 var ran = new Random(); 4 var keyRange = 100; //控制id重复的概率，值越大重复的概率越小 5 var keys = new string[100000]; 6 for (int i = 0; i < keys.Length; i++) 7 { 8 keys[i] = ran.Next(keyRange).ToString(); 9 } 10 11 Action act = () => Thread.Sleep(TimeSpan.FromMilliseconds(0.1)); 12 13 Console.WriteLine("keyRange={0}", keyRange); 14 CodeTimer.Initialize(); 15 CodeTimer.Time("mutex", 1, () => Perform(new MutexBasedKeyLockEngine(), keys, act, 10)); 16 CodeTimer.Time("dictionary", 1, () => Perform(new DictionaryBasedKeyLockEngine(), keys, act, 10)); 17 18 Console.ReadKey(); 19 } 20 21 static void Perform(IKeyLockEngine keyLockEngine, string[] keys, Action act, int threadCount) 22 { 23 var threads = new List<Thread>(); 24 for (int i = 0; i < threadCount; i++) 25 { 26 var tmp = i; 27 var t = new Thread(() => 28 { 29 for (int j = tmp; j < keys.Length; j += threadCount) 30 { 31 keyLockEngine.Invoke(keys[j], act); 32 } 33 }); 34 threads.Add(t); 35 } 36 threads.ForEach(x => x.Start()); 37 threads.ForEach(x => x.Join()); 38 }
测试代码中使用变量keyRange控制随机数的生成范围，keyRange越小，随机数的取值范围就越小，生成的关键字重复的概率就越大，下面是不同的keyRange下的测试结果。
keyRange=10
mutex
Time Elapsed: 1,172ms
CPU Cycles: 31,268,688
dictionary
Time Elapsed: 3,075ms
CPU Cycles: 8,096,584
====================
keyRange=10000
mutex
Time Elapsed: 1,719ms
CPU Cycles: 14,243,352
dictionary
Time Elapsed: 240ms
CPU Cycles: 13,247,904
====================
keyRange=10000000
mutex
Time Elapsed: 3,719ms
CPU Cycles: 50,583,016
dictionary
Time Elapsed: 207ms
CPU Cycles: 21,327,184
从测试结果中，可以看到，关键字的重复率较高时，使用互斥体的方案竟比之使用字典+Moniter的方案的耗时更少；反之，则使用字典的方案耗时更少。
这个结果在使用互斥体的方案上是容易理解的，因为互斥体的创建和销毁开销较大，重复率越高则创建/销毁的互斥体越少，开销也就越少。
那为何使用字典的方案在关键字重复率较高时性能下降了呢？经测试，在多个线程请求锁时，Moniter.Enter方法比单线程请求锁时花费的时间更多，这就需要从Moniter的实现原理上解释了，目前我对此原理尚未了解透彻，待搞清楚后再道来。
结论
最终，我们使用字典的方案，原因如下：
- 使用互斥体的方案在关键字完全重复的情况下应该是性能最好的，不过此时各线程就完全串行化了，这和使用简单的lock效果一样，此时该方案就没有意义了；而实际场景中关键字是“偶然重复”的，这意味着，使用字典的方案更为泛用。
- 互斥体的名称必须是字符串，而字典的key可以是任意类型，在使用字典的方案中，我们容易将string类型的key改为泛型类型，从而扩展该实现的使用范围。互斥体命名则不能做此扩展，因为我们无法确保关键字的类型总是按要求重载了ToString方法。
写在后面：这篇文章的标题怎么取非常让人纠结，一下子找不到一句合适的话描述该问题，各位会怎么做呢？
