为什么不要 "lock(this)" ? lock object 并是readonly（转载）

一. 为什么要lock，lock了什么？

当我们使用线程的时候，效率最高的方式当然是异步，即各个线程同时运行，其间不相互依赖和等待。但当不同的线程都需要访问某个资源的时候，就需要同步机制了，也就是说当对同一个资源进行读写的时候，我们要使该资源在同一时刻只能被一个线程操作，以确保每个操作都是有效即时的，也即保证其操作的原子性。lock是C#中最常用的同步方式，格式为lock(objectA){codeB} 。

lock(objectA){codeB} 看似简单，实际上有三个意思，这对于适当地使用它至关重要：
1. objectA被lock了吗？没有则由我来lock，否则一直等待，直至objectA被释放。
2. lock以后在执行codeB的期间其他线程不能调用codeB，也不能使用objectA。
3. 执行完codeB之后释放objectA，并且codeB可以被其他线程访问。

二. lock(this)怎么了？

我们看一个例子：

C1
class C1
{
privatebool deadlocked= true;
privateobject locker= newobject();

//这个方法用到了lock，我们希望lock的代码在同一时刻只能由一个线程访问
publicvoid LockMe(object o)
{
lock (locker)
{
while(deadlocked)
{
deadlocked = (bool)o;
Console.WriteLine("Foo: I am locked :(");
Thread.Sleep(500);
}
}
}

//所有线程都可以同时访问的方法
publicvoid DoNotLockMe()
{
Console.WriteLine("I am not locked :)");
}
}

这次我们使用一个私有成员作为锁定变量(locker)，在LockMe中仅仅锁定这个私有locker，而不是整个对象。这时候重新运行程序，可以看到虽然t1出现了死锁，DoNotLockMe()仍然可以由主线程访问；LockMe()依然不能访问，原因是其中锁定的locker还没有被t1释放。

关键点：
1. lock(this)的缺点就是在一个线程锁定某对象之后导致整个对象无法被其他线程访问。
2. 锁定的不仅仅是lock段里的代码，锁本身也是线程安全的。
3. 我们应该使用不影响其他操作的私有对象作为locker。
4. 在使用lock的时候，被lock的对象(locker)一定要是引用类型的，如果是值类型，将导致每次lock的时候都会将该对象装箱为一个新的引用对象(事实上如果使用值类型，C#编译器(3.5.30729.1)在编译时就会给出一个错误)。

kenny add

而对于Monitor，发现它的静态方法Enter(object obj)有一个异常类型ArgumentNullException，

执行lock(null对象 )处，抛出未处理的异常：System.ArgumentNullException: 值不能为空！

在代码段中修改锁定对象，会出现 blance<0的情况，并会抛出异常

private static readonly object obj = new object();

为什么要设置成只读的呢？这是因为如果在lock代码段中改变obj的值，其它线程就畅通无阻了，因为互斥锁的对象变了，object.ReferenceEquals必然返回false。

所以把上面的修改成private static readonly

转自http://blog.csdn.net/gulijiang2008/article/details/7257422