多线程内容大抵分两部份，其一是异步支配，可经由历程专用，线程池，Task，Parallel，PLINQ等，而这里又触及事情线程与IO线程；其二是线程同步题目，鄙人如今进修与探讨的是线程同步题目。
经由历程进修《CLR via C#》内里的内容，对线程同步形成了眉目较清晰的体系结构，在多线程中完成线程同步的是线程同步组织，这个组织分两大类，一个是基元组织，一个是夹杂组织。所谓基元则是在代码中运用最简朴的组织。基原组织又分红两类，一个是用户情势，另一个是内核情势。而夹杂组织则是在内部会运用基元组织的用户情势和内核情势，运用它的情势会有肯定的战略，因为用户情势和内核情势各有益弊，夹杂组织则是为了均衡二者的利与弊而设想出来。下面则枚举全部线程同步体系结构
基元
1.1 用户情势
1.1.1 volatile
1.1.2 Interlock
1.2 内核情势
1.2.1 WaitHandle
1.2.2 ManualResetEvent与AutoResetEvent
1.2.3 Semaphore
1.2.4 Mutex
夹杂
2.1 种种Slim
2.2 Monitor
2.3 MethodImplAttribute与SynchronizationAttribute
2.4 ReaderWriterLock
2.5 Barier(罕用)
2.6 CoutdownEvent（罕用）
先从线程同步题目的缘由提及，当内存中有一个整形的变量A,内里寄存的值是2，当线程1实行的时刻它会把A的值从内存中掏出寄存到CPU的寄存器中，并把A赋值为3，此时恰好线程1的时候片完毕；接着CPU把时候片分给线程2，线程2一样把A从内存中的值掏出来放到内存中，然则因为线程1并没有把变量A的新值3放回内存，故线程2读到的仍然是旧的值（也就是脏数据）2，然后线程2假如须要对A值举行一些推断之类的就会涌现一些非预期的结果了。
而针对上面这类对资本的同享题目处置惩罚，往往会运用林林总总要领。下面则一一引见
先说说基元组织中的用户情势，通经常使用户情势的长处是它的实行相对较快，因为它是经由历程一系列CPU指令来谐和，它形成的壅塞只是极短时候的壅塞，对支配体系而言这个线程是一向在运转，从未被壅塞。瑕玷就是惟有体系内核才住手如许的一个线程运转。另一方面就是因为线程在自旋而非壅塞，那末它还会占用这CPU的时候，形成对CPU时候的糟蹋。
起首是基元用户情势组织中的volatile组织，这个组织网上许多说法是让CPU对指定字段（Field，也就是变量）的读都是从内存读，每次写都是往内存写。但是它和编译器的代码优化有关联。先看看以下代码
public class StrageClass
{
vo int mFlag = 0;
int mValue = 0;
public void Thread1()
{
mValue = 5;
mFlag = 1;
}
public void Thread2()
{
if (mFlag == 1)
Console.WriteLine(mValue);
}
}
在晓得多线程同步题目的同砚们都邑晓得假如用两个线程分别去实行上面两个要领时，得出的结果有两个：
1.不输出任何东西;
2.输出5。然则在CSC编译器编译成IL言语或JIT编译成机器言语的历程当中，会举行代码优化，在要领Thread1中，编译器会认为给两个字段赋值会没什么所谓，它只会站在单个线程实行的角度来看，完整不会顾及多线程的题目，因而它有能够会把两行代码的实行递次调乱，致使先给mFlag赋值为1，再给mValue赋值为5，这就致使了第三种结果，输出0。惋惜这类结果我一向没法测试出来。
处理这个征象的就是volatile组织，运用了这类组织的结果是，通常对运用了此组织的字段举行读支配时，该支配都保证在原有代码递次下会在最早实行；或许是通常对运用了此组织的字段举行写支配时，该支配都保证在原有代码递次下会在末了实行。
完成了volatile的组织如今来讲有三个，其一是Thread的两个静态要领VolatileRead和VolatileWrite，在MSND上的剖析以下
Thread.VolatileRead 读取字段值。 不管处置惩罚器的数目或处置惩罚器缓存的状况怎样，该值都是由计算机的任何处置惩罚器写入的最新值。
Thread.VolatileWrite 立时向字段写入一个值，以使该值对计算机中的一切处置惩罚器都可见。
在多处置惩罚器体系上， VolatileRead 取得由任何处置惩罚器写入的内存位置的最新值。 这能够须要革新处置惩罚器缓存；VolatileWrite 确保写入内存位置的值立时可见的一切处置惩罚器。 这能够须要革新处置惩罚器缓存。
纵然在单处置惩罚器体系上， VolatileRead 和 VolatileWrite 确保值为读取或写入内存，并不缓存 （比方，在处置惩罚器寄存器中）。 因而，您能够运用它们能够由另一个线程，或经由历程硬件更新的字段对接见举行同步。
从上面的笔墨看不出他和代码优化有任何关联，那接着往下看。
volatile关键字则是volatile组织的别的一种完成体式格局，它是VolatileRead和VolatileWrite的简化版，运用 volatile 润饰符对字段能够保证对该字段的一切接见都运用 VolatileRead 或 VolatileWrite。MSDN中对volatile关键字的申明是
volatile 关键字指导一个字段能够由多个同时实行的线程修正。 声明为 volatile 的字段不受编译器优化（假定由单个线程接见）的限定。 如许能够确保该字段在任何时候显现的都是最新的值。
从这里能够看出跟代码优化有关联了。而纵观上面的引见得出两个结论:
1.运用了volatile组织的字段读写都是直接对内存支配，不触及CPU寄存器，使得一切线程对它的读写都是同步，不存在脏读了。读支配是原子的，写支配也是原子的。
2.运用了volatile组织润饰（或接见）字段，它会严厉依据代码编写的递次实行，读支配将会在最早实行，写支配将会最迟实行。
末了一个volatile组织是在.NET Framework中新增的，内里包括的要领都是Read和Write，它实际上就相称于Thread的VolatileRead 和VolatileWrite 。这须要拿源码来讲清晰明了，随意拿一个Volatile的Read要领来看
而再看看Thraed的VolatileRead要领
另一个用户情势组织是Interlocked，这个组织是保证读和写都是在原子支配内里，这是与上面volatile最大的辨别，volatile只能确保纯真的读或许纯真的写。
为什么Interlocked是如许，看一下Interlocaked的要领就晓得了
Add(ref int,int)// 挪用ExternAdd 外部要领 CompareExchange(ref Int32,Int32,Int32)//1与3是不是相称，相称则替代2，返回1的原始值 Decrement(ref Int32)//递减并返回 挪用add Exchange(ref Int32,Int32)//将2设置到1并返回 Increment(ref Int32)//自增 挪用add
就随意拿个中一个要领Add(ref int,int)来讲（Increment和Decrement这两个要领实际上内部挪用了Add要领），它会先读到第一个参数的值，在与第二个参数乞降后，把结果写到给第一参数中。起首这全部历程是一个原子支配，在这个支配内里既包括了读，也包括了写。至于怎样保证这个支配的原子性，预计须要检察Rotor源码才行。在代码优化方面来讲，它确保了一切写支配都在Interlocked之前往实行，这保证了Interlocked内里用到的值是最新的；而任何变量的读取都在Interlocked以后读取，这保证了背面用到的值都是最新更悛改的。
CompareExchange要领相称主要，虽然Interlocked供应的要领甚少，但基于这个能够扩展出其他更多要领，下面就是个例子，求出两个值的最大值,直接抄了Jeffrey的源码
检察上面代码，在进入轮回之前先声明每次轮回最先时target的值，在求出最值以后，查对一下target的值是不是有变化，假如有变化则须要再纪录新值，依据新值来再求一次最值，直到target稳定为止，这就满足了Interlocked中所说的，写都在Interlocked之前发作，Interlocked今后就可以读到最新的值。
基元内核情势
内核情势则是靠支配体系的内查对象来处置惩罚线程的同步题目。先说其弊病，它的速率会相对慢。缘由有两个，其一因为它是由支配体系内查对象来完成的，须要支配体系内部去谐和，别的一个缘由是内查对象都是一些非托管对象，在相识了AppDomain以后就会晓得，接见的对象不在当前AppDomain中的要么就举行按值封送，要么就举行按援用封送。经由视察这部份的非托管资本是按援用封送，这就会存在机能影响。综合上面两方面的两点得出内核情势的弊病。然则他也是有益的方面：1.线程在守候资本的时刻不会"自旋"而是壅塞，这个节省了CPU时候，而且这个壅塞能够设定一个超时价。2.能够完成Window线程和CLR线程的同步，也可同步差别历程中的线程（前者未体验到，而关于后者则晓得semaphores中有边境值资本）。3.可运用安全性设置，为经受权账户制止接见（这个不晓得是咋回事）。
内核情势的一切对象的基类是WaitHandle。内核情势的一切类条理以下
WaitHandle
EventWaitHandle
AutoResetEvent
ManualResetEvent
Semaphore
Mutex
WaitHandle继续MarshalByRefObject，这个就是按援用封送了非托管对象。WaitHandle内里重假如种种Wait要领，挪用了Wait要领在没有收到信号之前会被壅塞。WaitOne则是守候一个信号，WaitAny(WaitHandle[] waitHandles)则是收到恣意一个waitHandles的信号，WaitAll(WaitHandle[] waitHandles)则是守候一切waitHandles的信号。这些要领都有一个版本许可设置一个超时时候。其他的内核情势组织都有类似的Wait要领。
EventWaitHandle的内部维护着一个布尔值，而Wait要领会在这个布尔值为false时线程就会被壅塞，直到该布尔值为true时线程才被开释。支配这个布尔值的要领有Set()和Reset(),前者是把布尔值设成true；后者则设成false。这相称于一个开关，挪用了Reset以后线程实行到Wait就暂停了，直到Set才恢复。它有两个子类，运用的体式格局类似，辨别在于AutoResetEvent挪用Set以后自动挪用Reset，使得开关立时恢复封闭状况；而ManualResetEvent就须要手动挪用Set闪开关封闭。如许就到达一个结果寻常状况下AutoResetEvent每次开释的时刻能让一条线程经由历程；而ManualResetEvent在手动挪用Reset之前有能够会让多条线程经由历程。
Semaphore的内部是维护着一个整形，当组织一个Semaphore对象时会指定最大的信号量与初始信号量值，每当挪用一次WaitOne,信号量就会加1，当加到最大值时，线程就会被壅塞，当挪用Release的时刻就会开释一个或多个信号量，此时被壅塞掉的一个或多个线程就会被开释。这个就相符生产者与消耗者题目了，当生产者不停往产物行列中加入产物时，他就会WaitOne,当行列满了，就相称于信号量满了，生成者就会被壅塞，当消耗者消耗掉一个商品时，就会Release开释掉产物行列中的一个空间，此时因没有空间寄存产物的生产者又能够最先事情往产物行列中寄存产物了。
Mutex的内部与划定规矩相对前面二者轻微庞杂一点，先说与前面类似的处所就是一样都邑经由历程WaitOne来壅塞当前线程，经由历程ReleastMutex来开释对线程的壅塞。辨别在于WaitOne的许可第一个挪用的线程经由历程，其他背面的线程挪用到WaitOne就会被壅塞，经由历程了WaitOne的线程能够反复挪用WaitOne屡次，然则必需挪用一样次数的ReleaseMutex来开释，不然会因为次数不对等致使别的线程一向处于壅塞的状况。相比起之前的几个组织，这个组织会有线程一切权与递归这两个观点，这个是纯真靠前面的组织都没法完成的，分外封装除外。
夹杂组织
上面的基元组织是用了最简朴的完成体式格局，用户 情势有用户情势的快，然则它会带来CPU时候的糟蹋；内核情势处理了这个题目，然则会带来机能上的丧失，各有益弊，而夹杂组织则是鸠合了二者的利，它会在内部经由历程肯定战略恰当的机遇运用用户情势，再另一种状况下又会运用内核情势。然则这些层层推断带来的是内存上的开支。在多线程同步中没有圆满的组织，各个组织都有益弊，存在即有意义，连系细致的运用场景就会有最优的组织可供运用。只是在于我们可否依据细致的场景权衡利害罢了。
种种Slim后缀的类，在System.Threading定名空间中，能够看到若干个以Slim后缀末端的类：ManualResetEventSlim,SemaphoreSlim,ReaderWriterLockSlim。除了末了一个，其他两个都是在基元内核情势中有一样的组织，然则这三个类都是原有组织的简化版，尤其是前两个，运用体式格局跟原有的一样，然则只管防止运用支配体系的内查对象，而到达了轻量级的结果。比如在SemaphoreSlim中运用了内核组织ManualResetEvent，然则这个组织是经由历程延时初始化，没到达非不得已时都不运用。至于ReaderWriterLockSlim则在背面再引见。
Monitor与lock,lock关键字可谓是最广为人知的一种完成多线程同步的手腕，那末下面则又从一段代码提及
这个要领相称简朴且无实际意义，它只是为了看编译器把这段代码编译成什么模样，经由历程检察IL以下
留意到IL代码中涌现了try…finally语句块、Monitor.Enter与Monotor.Exit要领。然后把代码变动一下再编译看看IL
IL代码
代码比较类似，但并不是等价，实际上与lock语句块等价的代码以下
那末既然lock实质上是挪用了Monitor，那Monitor是怎样经由历程对一个对象加锁，然后完成线程同步。本来每一个在托管堆内里的对象都有两个牢固的成员，一个指向该对象范例的指针，另一个是指向一个线程同步块索引。这个索引指向一个同步块数组的元素，Monitor对线程加锁就是靠这个同步块。依据Jeffrey（CLR via C#的作者）的说法同步块中有三个字段，一切权的线程Id，守候线程的数目，递归的次数。但是我经由历程另一批文章相识到线程同步块的成员并不是纯真这几个，有兴致的同砚能够去浏览《展现同步块索引》的文章，有两篇。 当Monitor须要为某个对象obj加锁时，它会搜检obj的同步块索引有否为数组的某个索引，假如是-1的，则从数组中找出一个余暇的同步块与之关联，同时同步块的一切权线程Id就纪录下当前线程的Id；当再次有线程挪用Monitor的时刻就会搜检同步块的一切权Id和当前线程Id是不是对应上，能对应上的就让其经由历程，在递归次数上加1，假如对应不上的就把该线程扔到一个停当行列（这个行列实际上也是存在同步块内里）中，并将其壅塞；这个同步块会在挪用Exit的时刻搜检递归次数确保递归完了就消灭一切权线程Id。经由历程守候线程数目得知是不是有线程在守候，假如有则从守候行列中掏出线程并开释，不然就消除与同步块的关联，让同步块守候被下个被加锁的对象运用。
Monitor中另有一对要领Wait与Pulse。前者能够使得取获得锁的线程短暂地将锁开释，而当前线程就会被壅塞而放入守候行列中。直到其他线程挪用了Pulse要领，才会从守候行列中把线程放到停当行列中，守候下次锁被开释时，才有机会被再次猎取锁，细致可否猎取就要看守候行列中的状况了。
ReaderWriterLock读写锁，传统的lock关键字（即等价于Monitor的Enter和Exit）,他对同享资本的锁是全互斥锁，一经加锁的资本其他资本完整不能接见。
而ReaderWriterLock对互斥资本的加的锁分读锁与写锁，类似于数据库中提到的同享锁和排他锁。大抵状况是加了读锁的资本许可多个线程对其接见，而加了写锁的资本只要一个线程能够对其接见。两种加了差别缩的线程都不能同时接见资本，而严厉来讲，加了读锁的线程只要在同一个行列中的都能接见资本，而差别行列的则不能接见；加了写锁的资本只能在一个行列中，而写锁行列中只要一个线程能接见资本。辨别读锁的线程是不是在于一致个行列中的推断标准是，本次加读锁的线程与上次加读锁的线程这个时候段中，有否别的线程加了写锁，没没别的线程加写锁，则这两个线程都在同一个读锁行列中。
ReaderWriterLockSlim和ReaderWriterLock类似，是后者的升级版，出如今.NET Framework3.5，据说是优化了递归和简化了支配。在此递归战略我还没有穷究过。现在也许枚举一下它们通经常使用的要领
ReaderWriterLock经常使用的要领
Acqurie或Release ReaderLock或WriteLock 的排列组合
UpGradeToWriteLock/DownGradeFromWriteLock 用于在读锁中升级到写锁。当然在这个升级的历程当中也触及到线程从读锁行列切换到写锁行列中，因而须要守候。
ReleaseLock/RestoreLock 开释一切锁和恢复锁状况
ReaderWriterLock完成IDispose接口，其要领则是以下情势
TryEnter/Enter/Exit ReadLock/WriteLock/UpGradeableReadLock
CoutdownEvent比较罕用的夹杂组织，这个跟Semaphore相反，体如今Semaphore是在内部计数（也就是信号量）到达最大值的时刻让线程壅塞，而CountdownEvent是在内部计数到达0的时刻才让线程壅塞。其要领有
AddCount //计数递增； Signal //计数递减； Reset //计数重设为指定或初始； Wait //当且仅当计数为0才不壅塞，不然就壅塞。
Barrier也是一个比较罕用的夹杂组织，用于处置惩罚多线程在分步骤的支配中合作题目。它内部维护着一个计数，该计数代表此次合作的参与者数目，当差别的线程挪用SignalAndWait的时刻会给这个计数加1而且把挪用的线程壅塞，直到计数到达最大值的时刻，才会开释一切被壅塞的线程。假定照样不明白的话就看一下MSND上面的示例代码
这里给Barrier初始化的参与者数目是3，同时每完成一个步骤的时刻会挪用托付，该要领是输出count的值步骤索引。参与者数目厥后增加了两个又减少了一个。每一个参与者的支配都是雷同，给count举行原子自增，自增完则挪用SgnalAndWait示知Barrier当前步骤已完成并守候下一个步骤的最先。然则第三次因为回调要领里抛出了一个非常，每一个参与者在挪用SignalAndWait的时刻都邑抛出一个非常。经由历程Parallel最先了一个并行支配。假定并行开的功课数跟Barrier参与者数目不一样就会致使在SignalAndWait会有非预期的状况涌现。
接下来讲两个Attribute，这个预计不算是同步组织，然则也能在线程同步中发挥作用
MethodImplAttribute这个Attribute适用于要领的，当给定的参数是MethodImplOptions.Synchronized，它会对全部要领的要领体举行加锁，通常挪用这个要领的线程在没有取得锁的时刻就会被壅塞，直到具有锁的线程开释了才将其叫醒。对静态要领而言它就相称于把该类的范例对象给锁了，即lock(typeof(ClassType))；关于实例要领他就相称于把该对象的实例给锁了，即lock(this)。最最先对它内部挪用了lock这个结论存在怀疑，因而用IL编译了一下，发明要领体的代码没啥异常，检察了一些源码也好无眉目，厥后发明它的IL要领头跟一般的要领有辨别，多了一个synchronized
因而网上找种种材料，末了发明"junchu25"的博客[1][2]里提到用WinDbg来检察JIT生成的代码。
挪用Attribute的
挪用lock的
关于用这个Attribute完成的线程同步连Jeffrey都不引荐运用。
System.Runtime.Remoting.Contexts.SynchronizationAttribute这个Attribute适用于类，在类的定义中加了这个Attribute并继续与ContextBoundOject的类，它会对类中的一切要领都加上同一个锁，对照MethodImplAttribute它的局限更广，当一个线程挪用此类的任何要领时，假如没有取得锁，那末该线程就会被壅塞。有个说法是它实质上挪用了lock，关于这个说法的求证就更不轻易，国内的资本少之又少，内里又触及到AppDomain，线程高低文，末了中心的就是由SynchronizedServerContextSink这个类去完成的。AppDomain应该要另立篇举行引见。然则在这里也要轻微说一下，之前认为内存中就是有线程栈与堆内存，而这只是很基础的分别，堆内存还会分别红若干个AppDomain，在每一个AppDomain中也至少有一个高低文，每一个对象都邑隶属与一个AppDomain内里的一个高低文中。跨AppDomain的对象是不能直接接见的，要么举行按值封送（相称于深复制一个对象到挪用的AppDomain），要么就按援用封送。关于按援用封送则须要该类继续MarshalByRefObject。对继续了这个类的对象举行挪用时都不是挪用类的自身，而是经由历程代办的情势举行挪用。那末跨高低文的也须要举行按值封送支配。寻常组织的一个对象都是在历程默许AppDomain下的默许高低文中，而运用了SynchronizationAttribute特征的类它的实例是属于别的的一个高低文中，继续了ContextBoundObject基类的类举行跨高低文接见对象时也是经由历程按援用封送的体式格局用代办接见对象，并不是接见到对象自身。至因而不是跨高低文接见对象能够经由历程的RemotingServices.IsObjectOutOfContext(obj)要领举行推断。SynchronizedServerContextSink是mscorlib的一个内部类。当线程挪用跨高低文的对象时，这个挪用会被SynchronizedServerContextSink封装成WorkItem的对象,该对象也mscorlib的中的一个内部类，SynchronizedServerContextSink就要求SynchronizationAttribute，Attribute依据如今是不是有多个WorkItem的实行要求来决议当前处置惩罚的这个WorkItem会立时实行照样放到一个先进先出的WorkItem行列中按递次实行，这个行列是SynchronizationAttribute的一个成员，行列成员入队出队时或许Attribute推断是不是立时实行WorkItem时都须要猎取一个lock的锁，被锁的对象也恰是这个WorkItem的行列。这内里触及到几个类的交互，鄙人如今还没完整看清，以上这个处置惩罚历程能够有错，待剖析清晰再举行补充。不过经由历程这个Attribute完成的线程同步按逼人的直觉也是不引荐运用的，重假如机能方面的消耗，锁的局限也比较大。
以上就是详解C#多线程之线程同步（图文）的细致内容，更多请关注ki4网别的相干文章！
