在第1部分：基础知识中，我们描述了如何在线程上启动任务、配置线程以及双向传递数据。同时也说明了局部变量对于线程来说是私有的，以及引用是如何在线程之间共享，允许其通过公共字段进行通信。

下一步是同步（synchronization）：为期望的结果协调线程的行为。当多个线程访问同一个数据时，同步尤其重要，但是这是一件非常容易搞砸的事情。

同步构造可以分为以下四类：

简单的阻塞方法

这些方法会使当前线程等待另一个线程结束或是自己等待一段时间。Sleep、Join与Task.Wait都是简单的阻塞方法。

锁构造

锁构造能够限制每次可以执行某些动作或是执行某段代码的线程数量。排它锁构造是最常见的，它每次只允许一个线程执行，从而可以使得参与竞争的线程在访问公共数据时不会彼此干扰。标准的排它锁构造是lock（Monitor.Enter/Monitor.Exit）、Mutex与SpinLock。非排它锁构造是Semaphore、SemaphoreSlim以及读写锁。

信号构造

信号构造可以使一个线程暂停，直到接收到另一个线程的通知，避免了低效的轮询。有两种经常使用的信号设施：事件等待句柄（eventwaithandle）和Monitor类的Wait/Pluse方法。Framework.0加入了CountdownEvent与Barrier类。

非阻塞同步构造

非阻塞同步构造通过调用处理器指令来保护对公共字段的访问。CLR与C#提供了下列非阻塞构造：Thread.MemoryBarrier、Thread.VolatileRead、Thread.VolatileWrite、volatile关键字以及Interlocked类。

阻塞这个概念对于前三类来说都非常重要，接下来我们简要的剖析下它。

当线程的执行由于某些原因被暂停，比如调用Sleep等待一段时间，或者通过Join或EndInvoke方法等待其它线程结束时，则认为此线程被阻塞（blocked）。被阻塞的线程会立即出让（yields）其处理器时间片，之后不再消耗处理器时间，直到阻塞条件被满足。可以通过线程的ThreadState属性来检查一个线程是否被阻塞：

boolblocked=(someThread.ThreadStateThreadState.WaitSleepJoin)!=0;

（上面例子中线程状态可能在进行状态判断和依据状态进行操作之间发生改变，因此这段代码仅可用于调试诊断的场景。）

当一个线程被阻塞或是解除阻塞时，操作系统会进行上下文切换（contextswitch），这会带来几微秒的额外时间开销。

阻塞会在以下种情况下解除（电源按钮可不能算╮(╯▽╰)╭）：

阻塞条件被满足

操作超时（如果指定了超时时间）

通过Thread.Interrupt中断

通过Thread.Abort中止

通过Suspend方法（已过时，不应该再使用）暂停线程的执行不被认为是阻塞。

有时线程必须暂停，直到特定条件被满足。信号构造和锁构造可以通过在条件被满足前阻塞线程来实现。但是还有一种更为简单的方法：线程可以通过自旋（spinning）来等待条件被满足。例如：

while(!proceed);

一般来说，这会非常浪费处理器时间：因为对CLR和操作系统来说，这个线程正在执行重要的计算，就给它分配了相应的资源。

有时会组合使用阻塞与自旋：

while(!proceed)Thread.Sleep(10);

尽管并不优雅，但是这比仅使用自旋更高效（一般来说）。然而这样也可能会出现问题，这是由proceed标识上的并发问题引起的。正确的使用和锁构造和信号构造可以避免这个问题。

自旋在等待的条件很快（大致几微秒）就能被满足的情况下更高效，因为它避免了上下文切换带来的额外开销。.NETFramework提供了专门的方法和类型来辅助实现自旋，在第5部分会讲到。

可以通过线程的ThreadState属性来查询线程状态，它会返回一个ThreadState类型的按位方式组合的枚举值，其中包含了三“层”信息。然而大多数值都是冗余的、无用的或者过时不建议使用的。下图是其中一“层”信息：

下面的代码可以提取线程状态中最有用的个值:Unstarted、Running、WaitSleepJoin和Stopped：

publicstaticThreadStateSimpleThreadState(ThreadStatets){returnts(ThreadState.Unstarted

ThreadState.WaitSleepJoin

ThreadState.Stopped);}

ThreadState属性在进行调试诊断时有用，但不适合用来进行同步，因为线程状态可能在判断状态和依据状态进行操作之间发生改变。

排它锁用于确保同一时间只允许一个线程执行指定的代码段。主要的两个排它锁构造是lock和Mutex（互斥体）。其中lock更快，使用也更方便。而Mutex的优势是它可以跨进程的使用。

在这一节里，我们从介绍lock构造开始，然后介绍Mutex和信号量（semaphore）（用于非排它场景）。稍后在第部分会介绍读写锁（reader/writerlock）。

Framework.0加入了SpinLock结构体，可以用于高并发场景。

让我们从下边这个类开始：

classThreadUnsafe{staticint_val1=1,_val=1;staticvoidGo(){if(_val!=0)Console.WriteLine(_val1/_val);_val=0;}}

这个类不是线程安全的：如果Go方法同时被两个线程调用，可能会产生除数为零错误，因为可能在一个线程刚好执行完if的判断语句但还没执行Console.WriteLine语句时，_val就被另一个线程设置为零。

下边使用lock解决这个问题：

classThreadSafe{staticreadonlyobject_locker=newobject();staticint_val1,_val;staticvoidGo(){lock(_locker){if(_val!=0)Console.WriteLine(_val1/_val);_val=0;}}}

同一时间只有一个线程可以锁定同步对象（这里指_locker），并且其它竞争锁的线程会被阻塞，直到锁被释放。如果有多个线程在竞争锁，它们会在一个“就绪队列（readyqueue）”中排队，并且遵循先到先得的规则（需要说明的是，Windows系统和CLR的差别可能导致这个队列在有时会不遵循这个规则）。因为一个线程的访问不能与另一个线程相重叠，排它锁有时也被这样描述：它强制对锁保护的内容进行顺序（serialized）访问。在这个例子中，我们保护的是Go方法的内部逻辑，还有_val1与_val字段。

在竞争锁时被阻塞的线程，它的线程状态是WaitSleepJoin。在中断与中止中，我们会描述如何通过其它线程强制释放被阻塞的线程，这是一种可以用于结束线程的重型技术（译者注：这里指它们应该被作为在没有其它更为优雅的办法时的最后手段）。

*时间代表在同一线程上一次进行加锁和释放锁（假设没有阻塞）的开销，在IntelCorei上测得。

C#的lock语句是一个语法糖，它其实就是使用了try/finally来调用Monitor.Enter与Monitor.Exit方法。下面是在之前示例中的Go方法内部所发生的事情（简化的版本）：

Monitor.Enter(_locker);try{if(_val!=0)Console.WriteLine(_val1/_val);_val=0;}finally{Monitor.Exit(_locker);}

如果在同一个对象上没有先调用Monitor.Enter就调用Monitor.Exit会抛出一个异常。

刚刚所描述的就是C#1.0、.0和.0的编译器翻译lock语句产生的代码。

然而它有一个潜在的缺陷。考虑这样的情况：在Monitor.Enter的实现内部或者在Monitor.Enter与try中间有异常被抛出（可能是因为在线程上调用了Abort，或者有OutOfMemoryException异常被抛出），这时不一定能够获得锁。如果获得了锁，那么该锁就不会被释放，因为不可能执行到try/finally内，这会导致锁泄漏。

为了避免这种危险，CLR.0的设计者为Monitor.Enter添加了下面的重载：

publicstaticvoidEnter(objectobj,refboollockTaken);

当（且仅当）Enter方法抛出异常，锁没有能够获得时，lockTaken为false。

下边是正确的使用方式（这就是C#.0对于lock语句的翻译）：

boollockTaken=false;try{Monitor.Enter(_locker,reflockTaken);//你的代码...}finally{if(lockTaken)Monitor.Exit(_locker);}TryEnter

Monitor还提供了一个TryEnter方法，允许以毫秒或是TimeSpan方式指定超时时间。如果获得了锁，该方法会返回true，而如果由于超时没有获得锁，则会返回false。TryEnter也可以以无参数的形式进行调用，这是对锁进行“测试”，如果不能立即获得锁就会立即返回false。

类似于Enter方法，该方法在CLR.0中也被重载来接受lockTaken参数。

对所有参与同步的线程可见的任何对象都可以被当作同步对象使用，但有一个硬性规定：同步对象必须为引用类型。同步对象一般是私有的（因为这有助于封装锁逻辑），并且一般是一个实例或静态字段。同步对象也可以就是其要保护的对象，如下面例子中的_list字段：

classThreadSafe{Liststring_list=newListstring();voidTest(){lock(_list){_list.Add(Item1);//...

一个只被用来加锁的字段（例如前面例子中的_locker）可以精确控制锁的作用域与粒度。对象自己（this），甚至是其类型都可以被当作同步对象来使用：

lock(this){...}//或者：lock(typeof(Widget)){...}//保护对静态资源的访问

这种方式的缺点在于并没有对锁逻辑进行封装，从而很难避免死锁与过多的阻塞。同时类型上的锁也可能会跨越应用程序域（applicationdomain）边界（在同一进程内）。

你也可以在被lambda表达式或匿名方法所捕获的局部变量上加锁。

锁在任何情况下都不会限制对同步对象本身的访问。换句话说，x.ToString()不会因为其它线程调用lock(x)而阻塞，两个线程都要调用lock(x)才能使阻塞发生。

简单的原则是，需要在访问任意可写的共享字段（anywritablesharedfield）时加锁。即使是最简单的操作，例如对一个字段的赋值操作，都必须考虑同步。在下面的类中，Increment与Assign方法都不是线程安全的：

classThreadUnsafe{staticint_x;staticvoidIncrement(){_x++;}staticvoidAssign(){_x=1;}}

以下是线程安全的版本：

classThreadSafe{staticreadonlyobject_locker=newobject();staticint_x;staticvoidIncrement(){lock(_locker)_x++;}staticvoidAssign(){lock(_locker)_x=1;}}

在非阻塞同步（nonblockingsynchronization）中，我们会解释这种需求是如何产生的，以及在这些场景下内存屏障（memorybarrier，内存栅栏，内存栅障）和Interlocked类如何提供替代方法进行锁定。

如果一组变量总是在相同的锁内进行读写，就可以称为原子的（atomically）读写。假定字段x与y总是在对locker对象的lock内进行读取与赋值：

lock(locker){if(x!=0)y/=x;}

可以说x和y是被原子的访问的，因为上面的代码块无法被其它的线程分割或抢占。如果被其它线程分割或抢占，x和y就可能被别的线程修改导致计算结果无效。而现在x和y总是在相同的排它锁中进行访问，因此不会出现除数为零的错误。

在lock锁内抛出异常将打破锁的原子性，考虑如下代码：

decimal_savingsBalance,_checkBalance;voidTransfer(decimalamount){lock(_locker){_savingsBalance+=amount;_checkBalance-=amount+GetBankFee();}}

如果GetBankFee()方法内抛出异常，银行可能就要损失钱财了。在这个例子中，我们可以通过更早的调用GetBankFee()来避免这个问题。对于更复杂情况，解决方案是在catch或finally中实现“回滚（rollback）”逻辑。

指令原子性是一个相似但不同的概念：如果一条指令可以在CPU上不可分割地执行，那么它就是原子的。（见非阻塞同步）

线程可以用嵌套（重入）的方式重对相同的对象进行加锁：

lock(locker)lock(locker)lock(locker){//...}

或者：

Monitor.Enter(locker);Monitor.Enter(locker);Monitor.Enter(locker);Monitor.Exit(locker);Monitor.Exit(locker);Monitor.Exit(locker);

在这样的场景中，只有当最外层的lock语句退出或是执行了匹配数目的Monitor.Exit语句时，对象才会被解锁。

嵌套锁可以用于在锁中调用另一个方法（也使用了同一对象来锁定）：

staticreadonlyobject_locker=newobject();staticvoidMain(){lock(_locker){AnotherMethod();//这里依然拥有锁，因为锁是可重入的}}staticvoidAnotherMethod(){lock(_locker){Console.WriteLine(Anothermethod);}}

线程只会在第一个（最外层）lock处阻塞。

当两个线程等待的资源都被对方占用时，它们都无法执行，这就产生了死锁。演示死锁最简单的方法就是使用两个锁：

objectlocker1=newobject();objectlocker=newobject();newThread(()={lock(locker1){Thread.Sleep();lock(locker);//死锁}}).Start();lock(locker){Thread.Sleep();lock(locker1);//死锁}

更复杂的死锁链可能由三个或更多的线程创建。

在标准环境下，CLR不会像SQLServer一样自动检测和解决死锁。除非你指定了锁定的超时时间，否则死锁会造成参与的线程无限阻塞。（在SQLCLR集成宿主环境中，死锁能够被自动检测，并在其中一个线程上抛出可捕获的异常。）

死锁是多线程中最难解决的问题之一，尤其是在有很多关联对象的时候。这个困难在根本上在于无法确定调用方（caller）已经拥有了哪些锁。

你可能会锁定类x中的私有字段a，而并不知道调用方（或者调用方的调用方）已经锁住了类y中的字段b。同时，另一个线程正在执行顺序相反的操作，这样就创建了死锁。讽刺的是，这个问题会由于（良好的）面向对象的设计模式而加剧，因为这类模式建立的调用链直到运行时才能确定。

流行的建议：“以一致的顺序对对象加锁以避免死锁”，尽管它对于我们最初的例子有帮助，但是很难应用到刚才所描述的场景。更好的策略是：如果发现在锁区域中的对其它类的方法调用最终会引用回当前对象，就应该小心，同时考虑是否真的需要对其它类的方法调用加锁（往往是需要的，但是有时也会有其它选择）。更多的依靠声明方式（declarative）与数据并行（dataparallelism）、不可变类型（immutabletypes）与非阻塞同步构造（nonblockingsynchronizationconstructs），可以减少对锁的需要。

有另一种思路来帮助理解这个问题：当你在拥有锁的情况下访问其它类的代码，对于锁的封装就存在潜在的泄露。这不是CLR或.NETFramework的问题，而是因为锁本身的局限性。锁的问题在许多研究项目中被分析，包括软件事务内存（SoftwareTransactionalMemory）。

另一个死锁的场景是：如果已拥有一个锁，在调用Dispatcher.Invoke（在WPF程序中）或是Control.Invoke（在WindowsForms程序中）时，如果UI恰好要运行等待同一个锁的另一个方法，就会在这里发生死锁。这通常可以通过调用BeginInvoke而不是Invoke来简单的修复。或者，可以在调用Invoke之前释放锁，但是如果是调用方获得的锁，那么这种方法可能并不会起作用。我们在富客户端应用与线程亲和中来解释Invoke和BeginInvoke。

锁是非常快的，在一个时代的计算机上，没有竞争的情况下获取并释放锁一般只需0纳秒。如果存在竞争，产生的上下文切换会把开销增加到微秒的级别，并且线程被重新调度前可能还会等待更久的时间。如果需要锁定的时间很短，那么可以使用自旋锁（SpinLock）来避免上下文切换的开销。

如果获取锁后保持的时间太长而不释放，就会降低并发度，同时也会加大死锁的风险。

互斥体类似于C#的lock，不同在于它是可以跨越多个进程工作。换句话说，Mutex可以是机器范围（







































治疗白癜风最好的中药
北京看白癜风是多少钱

转载请注明原文网址：http://www.helimiaopu.com/jsyy/7530.html