lock 关键字可以用来确保代码块完成运行，而不会被其他线程中断。这是通过在代码块运行期间为给定对象获取互斥锁来实现的。

先来看看执行过程，代码示例如下：

lock 语句用于获取某个给定对象的互斥锁，执行一个语句，然后释放该锁。
lock-statement:（lock 语句：）
lock   (   expression   )   embedded-statement（lock   (   表达式   )   嵌入语句）
lock 语句的表达式必须表示一个引用类型的值。永远不会为 lock 语句中的表达式执行隐式装箱转换（第 6.1.5 节），因此，如果该表达式表示的是一个值类型的值，则会导致一个编译时错误。
下列形式的 lock 语句
lock (x) ...
（其中 x 是一个引用类型的表达式）完全等效于

system.threading.monitor.enter(x);
try {
   ...
}
finally {
   system.threading.monitor.exit(x);
}

不同的只是：实际执行中 x 只计算一次。
当一个互斥锁已被占用时，在同一线程中执行的代码仍可以获取和释放该锁。但是，在其他线程中执行的代码在该锁被释放前是无法获得它的。
一个类的 system.type 对象可以方便地用来当作关于该类的静态方法的互斥锁。例如：

class cache
{
   public static void add(object x) {
      lock (typeof(cache)) {
         ...
      }
   }
   public static void remove(object x) {
      lock (typeof(cache)) {
         ...
      }
   }
}

假设线程a先执行，线程b稍微慢一点。线程a执行到lock语句，判断obj是否已申请了互斥锁，

判断依据是逐个与已存在的锁进行object.referenceequals比较(此处未加证实)，如果不存

在，则申请一个新的互斥锁，这时线程a进入lock里面了。

这时假设线程b启动了，而线程a还未执行完lock里面的代码。线程b执行到lock语句，检查到obj

已经申请了互斥锁，于是等待;直到线程a执行完毕，释放互斥锁，线程b才能申请新的互斥锁并执行

lock里面的代码。

接下来说一些该lock什么对象。

为什么不能lock值类型，比如lock(1)呢?lock本质上monitor.enter，monitor.enter会使值类型装箱，

每次lock的是装箱后的对象。lock其实是类似编译器的语法糖，因此编译器直接限制住不能lock值类型。

退一万步说，就算能编译器允许你lock(1)，但是object.referenceequals(1,1)始终返回false(因为

每次装箱后都是不同对象),也就是说每次都会判断成未申请互斥锁，这样在同一时间，别的线程照样能

够访问里面的代码，达不到同步的效果。同理lock((object)1)也不行。

那么lock("xxx")字符串呢?msdn上的原话是：

锁定字符串尤其危险，因为字符串被公共语言运行库 (clr)“暂留”。 这意味着整个程序中任何给定字符串

都只有一个实例，就是这同一个对象表示了所有运行的应用程序域的所有线程中的该文本。因此，只要在应用

程序进程中的任何位置处具有相同内容的字符串上放置了锁，就将锁定应用程序中该字符串的所有实例。

通常，最好避免锁定 public 类型或锁定不受应用程序控制的对象实例。例如，如果该实例可以被公开访问，

则 lock(this) 可能会有问题，因为不受控制的代码也可能会锁定该对象。这可能导致死锁，即两个或更多个线

程等待释放同一对象。出于同样的原因，锁定公共数据类型(相比于对象)也可能导致问题。而且lock(this)

只对当前对象有效，如果多个对象之间就达不到同步的效果。

lock(typeof(class))与锁定字符串一样，范围太广了。

某些系统类提供专门用于锁定的成员。例如，array 类型提供 syncroot。许多集合类型也提供 syncroot。

而自定义类推荐用私有的只读静态对象，比如：

private static readonly object obj = new object();

为什么要设置成只读的呢?这时因为如果在lock代码段中改变obj的值，其它线程就畅通无阻了，因为互斥锁的

对象变了，object.referenceequals必然返回false。