多线程的讲解（锁定与同步）（转）

原帖地址暂时没看到。

直接拷贝doc文档的吧。

如下：

从原理上讲,lock和Syncronized Attribute都是用Moniter.Enter实现的,比如如下代码

object lockobj=new object(); lock(obj) { //do things }

　　在编译时,会被编译为类似

try{ Moniter.Enter(obj) { //do things } } catch { } finally { Moniter.Exit(obj); }

　　而[MethodImpl(MethodImplOptions.Synchronized)]标记为同步的方法会在编译时被lock(this)语句所环绕
所以我们只简单探讨Moniter.Enter的实现

　　（注:DotNet并非使用Win32API的CriticalSection来实现Moniter.Enter，不过他为托管对象提供了一个类似的结构叫做Syncblk）

　　每个对象实例头部都有一个指针,这个指针指向的结构,包含了对象的锁定信息,当第一次使用Moniter.Enter(obj)时,这个obj对象的锁定结构就会被初时化,第二次调用Moniter.Enter时,会检验这个object的锁定结构,如果锁没有被释放,则调用会阻塞



WaitHandle是什么,他和他的派生类怎么使用

　　WaitHandle是Mutex，Semaphore，EventWaitHandler，AutoResetEvent，ManualResetEvent共同的祖先，他们包装了用于同步的内核对象，也就是说是这些内核对象的托管版本。

　　Mutex:类似于一个接力棒,拿到接力棒的线程才可以开始跑,当然接力棒一次只属于一个线程(Thread Affinity),如果这个线程不释放接力棒(Mutex.ReleaseMutex),那么没办法,其他所有需要接力棒运行的线程都知道能等着看热闹

　　Semaphore:类似于一个小桶,里面装了几个小球,凡是拿到小球就可以跑,比如指定小桶里最初有四个小球,那么开始的四个线程就可以直接拿着自己的小球开跑,但是第五个线程一看,小球被拿光了,就只好乖乖的等着有谁放一个小球到小桶里(Semophore.Release),他才能跑,但是这里的游戏规则比较特殊,我们可以随意向小桶里放入小球,也就是说我可以拿走一个小球,放回去俩,甚至一个都不拿,放回去5个,这样就有五个线程可以拿着这些小球运行了.我们可以规定小桶里有开始有几个小球(构造函数的第一个参数),也可以规定最多不能超过多少小球(构造函数的第二个参数)



什么是用双锁实现Singleton,为什么要这样做,双锁检验是不安全的吗?

使用双锁检验技巧来实现单件,来自于Java社区

public static MySingleton Instance{ get{ if(_instance!=null)}{ lock(_instance){ if(s_value==null){ _instance= new MySingleton(); } } } } }

这样做其实是为了提高效率,比起

public static MySingleton Instance{ get{ lock(_instance){ if(s_value==null){ _instance= new MySingleton(); } } } }

　　前一种方法在instance创建的时候不需要用lock同步,从而增进了效率

　　在java中这种技巧被证明是不安全的详细见http://www.cs.umd.edu/~pugh/java/memoryModel/

　　但是在.Net下,这样的技巧是成立的,因为.Net使用了改进的内存模型

　　并且在.Net下,我们可以使用LazyInit来实现单件

private static readonly _instance=new MySingleton() public static MySingleton Instance{ get{return _instance} }

　　当第一此使用_instance时,CLR会生成这个对象,以后再访问这个字段,将会直接返回

互斥对象（Mutex）,信号量(Semaphore),事件（Event）对象与lock语句的比较

　　首先这里所谓的事件对象不是System.Event，而是一种用于同步的内核机制

　　互斥对象和事件对象属于内核对象，利用内核对象进行线程同步，线程必须要在用户模式和内核模式间切换，所以一般效率很低，但利用互斥对象和事件对象这样的内核对象，可以在多个进程中的各个线程间进行同步。

lock或者Moniter是.net用一个特殊结构实现的,不涉及模式切换,也就是说工作在用户方式下，同步速度较快,但是不能跨进程同步

刚刚接触锁定的程序员往往觉得这个世界非常的危险,每个静态变量似乎都有可能产生竞争

　　首先锁定是解决竞争条件的,也就是多个线程同时访问某个资源,造成意想不到的结果,比如,最简单的情况,一个计数器,如果两个线程同时加一,后果就是损失了一个计数,但是频繁的锁定又可能带来性能上的消耗,还有最可怕的情况,死锁

到底什么情况下我们需要使用锁,什么情况下不用呢?

只有共享资源才需要锁定
首先,只有可以被多线程访问的共享资源才需要考虑锁定,比如静态变量,再比如某些缓存中的值,属于线程内部的变量不需要锁定

把锁定交给数据库
　　数据库除了存储数据之外,还有一个重要的用途就是同步,数据库本身用了一套复杂的机制来保证数据的可靠和一致性,这就为我们节省了很多的精力.保证了数据源头上的同步,我们多数的精力就可以集中在缓存等其他一些资源的同步访问上了

了解你的程序是怎么运行的
　　实际上在web开发中大多数逻辑都是在单个线程中展开的,无论asp.net还是php,一个请求都会在一个单独的线程中处理,其中的大部分变量都是属于这个线程的,根本没有必要考虑锁定,当然对于asp.net中的application对象中的数据,我们就要小心一些了

　　WinForm中凡是使用BeginInvoke和Invoke调用的方法也都不需要考虑同步,因为这用这两个方法调用的方法会在UI线程中执行,因此实际是同步的,所以如果调用的方法中存在某些静态变量,不需要考虑锁定

业务逻辑对事务和线程安全的要求
　　这条是最根本的东西,开发完全线程安全的程序是件很费时费力的事情,在电子商务等涉及金融系统的案例中,许多逻辑都必须严格的线程安全,所以我们不得不牺牲一些性能,和很多的开发时间来做这方面的工作,而一般的应用中,许多情况下虽然程序有竞争的危险,我们还是可以不使用锁定,比如有的时候计数器少一多一,对结果无伤大雅的情况下,我们就可以不用去管他

计算一下冲突的可能性
　　我以前曾经谈到过,架构不要过设计,其实在这里也一样,假如你的全局缓存里的某个值每天只有几百或者几千个访问,并且访问时间很短,并且分布均匀(实际上这是大多数的情况),那么冲突的可能性就非常的少,也许每500天才会出现一次或者更长,从7*24小时安全服务的角度来看,也完全符合要求,那么你还会为这样万分之一的可能性花80%的精力去设计吗?

请多使用lock,少用Mutex
　　如果你一定要使用锁定,请尽量不要使用内核模块的锁定机制,比如.net的Mutex,Semaphore,AutoResetEvent,ManuResetEvent,使用这样的机制涉及到了系统在用户模式和内核模式间的切换,所以性能差很多,但是他们的优点是可以跨进程同步线程,所以应该清楚的了解到他们的不同和适用范围