.NET 同步与异步之锁（Lock、Monitor）（七）

在上一篇随笔中已经提到、解决竞争条件的典型方式就是加锁，那本篇随笔就重点来说一说.NET提供的最常用的锁 lock关键字和 Monitor。

一、lock关键字Demo

        public object thisLock = new object();
        private long index;
 
        public void AddIndex()
        {
            lock (this.thisLock)
            {
                this.index++;
 
                if (this.index > long.MaxValue / )
                {
                    this.index = ;
                }
　　　　　　　　　// 和 index 无关的大量操作
            }
        }
 
        public long GetIndex()
        {
            return this.index;
        }

这一组demo，代码简洁，逻辑简单，一个 AddIndex 方法保证字段 index 在 0到100之间，另外一个GetIndex方法用来获取字段index的值。

但是，这一组Demo却有不少问题，甚至可以说是错误，下面我将一一进行说明：

1、忘记同步——即读写操作都需要加锁

　　GetIndex方法，由于该方法没有加锁，所以通过该方法在任何时刻都可以访问字段index的值，也就是说会恰好在某个时间点获取到 101 这个值，这一点是和初衷相违背的。

2、读写撕裂

　　如果说读写撕裂这个问题，这个demo可能不是很直观，但是Long类型确实存在读写撕裂。比如下面的例子：

        /// <summary>
        /// 测试原子性
        /// </summary>
        public void TestAtomicity()
        {
            long test = ;
 
            long breakFlag = ;
            int index = ;
            Task.Run(() =>
            {
                base.PrintInfo("开始循环   写数据");
                while (true)
                {
                    test = (index %  == ) ? 0x0 : 0x1234567890abcdef;
 
                    index++;
 
                    if (Interlocked.Read(ref breakFlag) > )
                    {
                        break;
                    }
                }
 
                base.PrintInfo("退出循环   写数据");
            });
 
            Task.Run(() =>
            {
                base.PrintInfo("开始循环   读数据");
                while (true)
                {
                    long temp = test;
 
                    if (temp !=  && temp != 0x1234567890abcdef)
                    {
                        Interlocked.Increment(ref breakFlag);
                        base.PrintInfo($"读写撕裂:   { Convert.ToString(temp, 16)}");
                        break;
                    }
                }
 
                base.PrintInfo("退出循环   读数据");
            });
        }

测试原子性操作

64位的数据结构在32位的系统上（当然和CPU也有关系）是需要两个命令来实现读写操作的，也就是说、如果恰好在两个写命令中间发生了读取操作，就有可能读取到不完成的数据。故而要警惕读写撕裂。

3、粒度错误

　　AddIndex 方法中，和 index 无关的大量操作，放在锁中是没有必要的，虽然没必要但是也不是错的，只能说这个锁的粒度过大，造成了没必要的并发上的性能影响。

下面举例一个错误的锁粒度：

        public class BankAccount
        {
            private long id;
            private decimal m_balance = 0.0M;
 
            private object m_balanceLock = new object();
 
            public void Deposit(decimal delta)
            {
                lock (m_balanceLock)
                {
                    m_balance += delta;
                }
            }
 
            public void Withdraw(decimal delta)
            {
                lock (m_balanceLock)
                {
                    if (m_balance < delta)
                        throw new Exception("Insufficient funds");
                    m_balance -= delta;
                }
            }
 
            public static void ErrorTransfer(BankAccount a, BankAccount b, decimal delta)
            {
                a.Withdraw(delta);
                b.Deposit(delta);
            }
 
            public static void Transfer(BankAccount a, BankAccount b, decimal delta)
            {
                lock (a.m_balanceLock)
                {
                    lock (b.m_balanceLock)
                    {
                        a.Withdraw(delta);
                        b.Deposit(delta);
                    }
                }
            }
 
            public static void RightTransfer(BankAccount a, BankAccount b, decimal delta)
            {
                if (a.id < b.id)
                {
                    Monitor.Enter(a.m_balanceLock); // A first
                    Monitor.Enter(b.m_balanceLock); // ...and then B
                }
                else
                {
                    Monitor.Enter(b.m_balanceLock); // B first
                    Monitor.Enter(a.m_balanceLock); // ...and then A
                }
 
                try
                {
                    a.Withdraw(delta);
                    b.Deposit(delta);
                }
                finally
                {
                    Monitor.Exit(a.m_balanceLock);
                    Monitor.Exit(b.m_balanceLock);
                }
            }
 
        }

错误的锁粒度

在 ErrorTransfer 方法中，在转账的两个方法中间的时间点上，转账金额属于无主状态，这时锁的粒度就过小了。

在 Transfer 方法中，虽然粒度正确了，但是此时容易死锁。而比较恰当的方式可以是：RightTransfer 。

4、不合理的lock方式

锁定非私有类型的对象是一种危险的行为，因为非私有类型被暴露给外界、外界也可以对被暴露的对象进行加锁，这种情况下很容造成死锁或者错误的锁粒度。

较为合理的方式是将 thislock 改为 private .

由上述进行类推：

1、lock(this)：如果当前类型为外界可访问的也会有类似问题。

2、lock(typeof(T)): 因为Type对象，是整个进程域中是唯一的。所以，如果T为外界可访问的类型也会有类似问题。

3、lock("字符串")：因为String类型的特殊性（内存驻留机制），多个字符串其实有可能是同一把锁，所以、一不小心就容易掉入陷阱、造成死锁或者错误的锁粒度。

二、通过 IL 代码看本质

下面是 AddIndex 方法的全部il代码 [使用 .NET 4.5类库，VS2015 编译]：

.method public hidebysig instance void  AddIndex() cil managed
{
  // 代码大小       81 (0x51)
  .maxstack
  .locals init ([] object V_0,
           [] bool V_1,
           [] bool V_2)
  IL_0000:  nop
  IL_0001:  ldarg.
  IL_0002:  ldfld      object ParallelDemo.Demo.LockMonitorClass::thisLock
  IL_0007:  stloc.
  IL_0008:  ldc.i4.
  IL_0009:  stloc.
  .try
  {
    IL_000a:  ldloc.
    IL_000b:  ldloca.s   V_1
    IL_000d:  call       void [mscorlib]System.Threading.Monitor::Enter(object,
                                                                        bool&)
    IL_0012:  nop
    IL_0013:  nop
    IL_0014:  ldarg.
    IL_0015:  ldarg.
    IL_0016:  ldfld      int64 ParallelDemo.Demo.LockMonitorClass::index
    IL_001b:  ldc.i4.
    IL_001c:  conv.i8
    IL_001d:  add
    IL_001e:  stfld      int64 ParallelDemo.Demo.LockMonitorClass::index
    IL_0023:  ldarg.
    IL_0024:  ldfld      int64 ParallelDemo.Demo.LockMonitorClass::index
    IL_0029:  ldc.i8     0x3fffffffffffffff
    IL_0032:  cgt
    IL_0034:  stloc.
    IL_0035:  ldloc.
    IL_0036:  brfalse.s  IL_0042
    IL_0038:  nop
    IL_0039:  ldarg.
    IL_003a:  ldc.i4.
    IL_003b:  conv.i8
    IL_003c:  stfld      int64 ParallelDemo.Demo.LockMonitorClass::index
    IL_0041:  nop
    IL_0042:  nop
    IL_0043:  leave.s    IL_0050
  }  // end .try
  finally
  {
    IL_0045:  ldloc.
    IL_0046:  brfalse.s  IL_004f
    IL_0048:  ldloc.
    IL_0049:  call       void [mscorlib]System.Threading.Monitor::Exit(object)
    IL_004e:  nop
    IL_004f:  endfinally
  }  // end handler
  IL_0050:  ret
} // end of method LockMonitorClass::AddIndex

当然你没必要完全看懂，你只需要注意到三个细节就可以了：

1、调用 [mscorlib]System.Threading.Monitor::Enter(object, bool&) 方法，其中第二个入参为索引为1的local变量 [查类库后发现该参数是 ref 传递引用]。

2、如果索引为1的local变量不为 false，则调用 [mscorlib]System.Threading.Monitor::Exit(object) 方法

3、try... finally 语句块

换句话，也就是说 lock关键字其实本质上就是 Monitor 类的简化实现方式，为了安全、进行了try...finally处理。

三、Monitor 的 wait和 Pulse

因为进入锁（Enter）和离开锁（Exit）都是有一定的性能损耗的，所以，当有频繁的没有必要的锁操作的时候，性能影响更大。

比如：在生产者消费者模式中，如果没有需要消费的数据时，对锁的频繁操作是没有必要的（轮询模式，不是推送）。

在这种情况下， wait方法就派上用场了。如下是MSDN中的一句备注：

当前拥有对指定对象的锁的线程调用此方法以释放该对象，以便另一个线程可以访问它。等待重新获取锁时阻止调用方。当调用方需要等待另一个线程操作后将发生状态更改时，调用此方法。

wait 和 pulse 方法一笔带过，这对方法、笔者用的也不多。

随笔暂告一段落、下一篇随笔介绍：锁（ReaderWriterLockSlim）（预计1篇随笔）

附，Demo : http://files.cnblogs.com/files/08shiyan/ParallelDemo.zip

参见更多：随笔导读：同步与异步

(未完待续...)