本篇從 Monitor，Mutex，ManualResetEvent，AutoResetEvent，WaitHandler 的類關系圖開始，希望通過本篇的介紹能對常見的線程同步方法有一個整體的認識，而對每種方式的使用細節，適用場合不會過多解釋。
讓我們來看看這幾個類的關系圖：
1. lock 關鍵字
lock 是 C# 關鍵詞，它將語句塊標記為臨界區,確保當一個線程位於代碼的臨界區時，另一個線程不進入臨界區。如果其他線程試圖進入鎖定的代碼，則它將一直等待（即被阻止），直到該對象被釋放。方法是獲取給定對象的互斥鎖，執行語句，然后釋放該鎖。MSDN 上給出了使用 lock 時的注意事項通常，應避免鎖定 public 類型，否則實例將超出代碼的控制范圍。
常見的結構 lock (this)、lock (typeof (MyType)) 和 lock ("myLock") 。
1）如果實例可以被公共訪問，將出現 lock (this) 問題。
2）如果 MyType 可以被公共訪問，將出現 lock (typeof (MyType)) 問題。由於一個類的所有實例都只有一個類型對象（該對象是 typeof 的返回結果），鎖定它，就鎖定了該對象的所有實例。微軟現在建議不要使用 lock(typeof(MyType)),因為鎖定類型對象是個很緩慢的過程，並且類中的其他線程、甚至在同一個應用程序域中運行的其他程序都可以訪問該類型對象，因此，它們就有可能代替您鎖定類型對象，完全阻止您的執行，從而導致你自己的代碼的掛起。
3）由於進程中使用同一字符串的任何其他代碼將共享同一個鎖，所以出現 lock("myLock") 問題。這個問題和.NET Framework 創建字符串的機制有關系，如果兩個 string 變量值都是"myLock"， 在內存中會指向同一字符串對象。最佳做法是定義 private 對象來鎖定, 或 private static 對象變量來保護所有實例所共有的數據。
我們再來通過 IL Dasm 看看 lock 關鍵字的本質，下面是一段簡單的測試代碼：
lock (lockobject)
{
int i = 5;
}
用 IL Dasm 打開編譯后的文件，上面的語句塊生成的 IL 代碼為：
IL_0045: call
IL_004a: nop
.try
{
IL_004b: nop
void [mscorlib]System.Threading.Monitor::Enter(object)
IL_004c: ldc.i4.5 IL_004d: stloc.1
IL_004e: nop IL_004f: leave.s }
// end .try finally { IL_0051: ldloc.3 IL_0052: call IL_0057: nop IL_0058: endfinally }
// end handler
通過上面的代碼我們很清楚的看到：lock 關鍵字其實就是對 Monitor 類的 Enter()和 Exit()方法的封裝。通過 try......catch......finally 語句塊確保在 lock 語句塊結束后執行 Monitor.Exit()方法，釋放互斥鎖。
2. Monitor 類
Monitor類通過向單個線程授予對象鎖來控制對對象的訪問。對象鎖提供限制訪問臨界區的能力。當一個線程擁有對象的鎖時，其他任何線程都不能獲取該鎖。還可以使用 Monitor 來確保不會允許其他任何線程訪問正在由鎖的所有者執行的應用程序代碼節，除非另一個線程正在使用其他的鎖定對象執行該代碼。通過對 lock 關鍵字的分析我們知道，lock 就是對 Monitor 的 Enter 和 Exit 的一個封裝，而且使用起來更簡潔，因此 Monitor 類的 Enter()和 Exit()方法的組合使用可以用 lock 關鍵字替代。
Monitor 類的常用方法：
TryEnter()：
能夠有效的解決長期死等的問題，如果在一個並發經常發生，而且持續時間長的環境中使用 TryEnter，可以有效防止死鎖或者長時間的等待。比如我們可以設置一個等待時間 bool gotLock = Monitor.TryEnter(myobject,1000),讓當前線程在等待 1000 秒后根據返回的 bool 值來決定是否繼續下面的操作。
Wait() ：
釋放對象上的鎖以便允許其他線程鎖定和訪問該對象。在其他線程訪問對象時，調用線程將等待。脈沖信號用於通知等待線程有關對象狀態的更改。
Pulse()：
PulseAll()：
向一個或多個等待線程發送信號。該信號通知等待線程鎖定對象的狀態已更改，並且鎖的所有者准備釋放該鎖。等待線程被放置在對象的就緒隊列中以便它可以最后接收對象鎖。一旦線程擁有了鎖，它就可以檢查對象的新狀態以查看是否達到所需狀態。注意：Pulse、PulseAll 和 Wait 方法必須從同步的代碼塊內調用。
我們假定一種情景：媽媽做蛋糕，小孩有點饞，媽媽每做好一塊就要吃掉，媽媽做好一塊后，告訴小孩蛋糕已經做好了。下面的例子用 Monitor 類的 Wait 和 Pulse 方法模擬小孩吃蛋糕的情景。
using System;
using System.Threading;
/// <summary>
/// 僅僅是說明 Wait 和 Pulse/PulseAll 的例子
/// 邏輯上並不嚴密，使用場景也並不一定合適
/// </summary>
class MonitorSample
{
private int n = 1; // 生產者和消費者共同處理的數據
private int max = 10000;
private object monitor = new object();
public void Produce() // 生產
{
lock (monitor)
{
for (; n <= max; n++)
{
Console.WriteLine("媽媽：第" + n.ToString() + "塊蛋糕做好了");
// Pulse 方法不用調用是因為另一個線程中用的是 Wait(object,int) 方法
// 該方法使被阻止線程進入了同步對象的就緒隊列
// 是否需要脈沖激活是 Wait 方法一個參數和兩個參數的重要區別
Monitor.Pulse(monitor);
// 調用 Wait 方法釋放對象上的鎖並阻止該線程（線程狀態為 WaitSleepJoin）
// 該線程進入到同步對象的等待隊列，直到其它線程調用 Pulse 使該線程進入到就緒隊列中
// 線程進入到就緒隊列中才有條件爭奪同步對象的所有權
// 如果沒有其它線程調用 Pulse/PulseAll 方法，該線程不可能被執行
Monitor.Wait(monitor);
}
}
}
public void Consume() // 消費
{
lock (monitor)
{
while (true)
{
// 通知等待隊列中的線程鎖定對象狀態的更改，但不會釋放鎖
// 接收到 Pulse 脈沖后，線程從同步對象的等待隊列移動到就緒隊列中
// 注意：最終能獲得鎖的線程並不一定是得到 Pulse 脈沖的線程
Monitor.Pulse(monitor);
// 釋放對象上的鎖並阻止當前線程，直到它重新獲取該鎖
// 如果指定的超時間隔已過，則線程進入就緒隊列
// 該方法只有在線程重新獲得鎖時才有返回值
// 在超時等待時間內就獲得了鎖,返回結果為 true,否則為 false
// 有時可以利用這個返回結果進行一個代碼的分支處理
Monitor.Wait(monitor, 1000);
Console.WriteLine("孩子：開始吃第" + n.ToString() + "塊蛋糕");
}
}
}
static void Main(string[] args)
{
MonitorSample obj = new MonitorSample();
Thread tProduce = new Thread(new ThreadStart(obj.Produce));
Thread tConsume = new Thread(new ThreadStart(obj.Consume));
tProduce.Start();
tConsume.Start();
Console.ReadLine();
}
}
這個例子的目的是要理解 Wait 和 Pulse 如何保證線程同步的，同時要注意 Wait(obeject) 和 Wait(object,int) 方法的區別，理解它們的區別很關鍵的一點是要理解同步的對象包含若干引用，其中包括對當前擁有鎖的線程的引用、對就緒隊列（包含准備獲取鎖的線程）的引用和對等待隊列（包含等待對象狀態更改通知的線程）的引用。
.NET 中線程同步的方式多的讓人看了眼花繚亂，究竟該怎么理解？其實，拋開.NET 環境看線程同步，無非執行兩種操作：
1. 互斥/加鎖，目的是保證臨界區代碼操作的"原子性"；
2. 信號燈操作，目的是保證多個線程按照一定順序執行，如生產者線程要先於消費者線程執行。
.NET 中線程同步的類無非是對這兩種方式的封裝，目的歸根結底都可以歸結為實現互斥/加鎖或者是信號燈這兩種方式，只是它們的適用場合有所不同。
下面我們根據類的層次結構了解 WaitHandler 及其子類。
1. WaitHandler
WaitHandle 是 Mutex，Semaphore，EventWaitHandler，AutoResetEvent，ManualResetEvent 共同的祖先，它封裝 Win32 同步句柄內核對象，也就是說是這些內核對象的托管版本。線程可以通過調用 WaitHandler 實例的方法 WaitOne 在單個等待句柄上阻止。此外，WaitHandler 類重載了靜態方法，以等待所有指定的等待句柄都已收集到信號 WaitAll，或者等待某一指定的等待句柄收集到信號 WaitAny。這些方法都提供了放棄等待的超時間隔、在進入等待之前退出同步上下文的機會，並允許其它線程使用同步上下文。WaitHandler 是 C# 中的抽象類，不能實例化。
2. EventWaitHandler vs. ManualResetEvent vs. AutoResetEvent（同步事件）
我們先看看兩個子類 ManualResetEvent 和 AutoResetEvent 在.NET Framework 中的實現：
//.NET Framework 中 ManualResetEvent 類的實現
[ComVisible(true),HostProtection(SecurityAction.LinkDemand,Synchronization = true, ExternalThreading = true)]
public sealed class ManualResetEvent : EventWaitHandle
{
// Methods
public ManualResetEvent(bool initialState) : base(initialState, EventResetMode.ManualReset) {}
}
//.NET Framework 中 AutoResetEvent 類的實現
[ComVisible(true), HostProtection(SecurityAction.LinkDemand,Synchronization = true,ExternalThreading = true)]
public sealed class AutoResetEvent : EventWaitHandle
{
// Methods
public AutoResetEvent(bool initialState) : base(initialState, EventResetMode.AutoReset) { }
}
原來 ManualResetEvent 和 AutoResetEvent 都繼承自 EventWaitHandler，它們的唯一區別就在於父類 EventWaitHandler 的構造函數參數 EventResetMode 不同，這樣我們只要弄清了參數 EventResetMode 值不同時，EventWaitHandler 類控制線程同步的行為有什么不同，兩個子類也就清楚了。為了便於描述，我們不去介紹父類的兩種模式，而直接介紹子類。
ManualResetEvent 和 AutoResetEvent 的共同點：
1） Set 方法將事件狀態設置為終止狀態，允許一個或多個等待線程繼續；
Reset 方法將事件狀態設置為非終止狀態，導致線程阻止；
WaitOne 阻止當前線程，直到當前線程的 WaitHandler 收到事件信號。
2） 可以通過構造函數的參數值來決定其初始狀態，若為 true 則事件為終止狀態從而使線程為非阻塞狀態，為 false 則線程為阻塞狀態。
3） 如果某個線程調用 WaitOne 方法，則當事件狀態為終止狀態時，該線程會得到信號，繼續向下執行。
ManualResetEvent 和 AutoResetEvent 的不同點：
1） AutoResetEvent.WaitOne() 每次只允許一個線程進入，當某個線程得到信號后，AutoResetEvent 會自動又將信號置為不發送狀態，則其他調用 WaitOne 的線程只有繼續等待，也就是說 AutoResetEvent 一次只喚醒一個線程；
2） ManualResetEvent 則可以喚醒多個線程，因為當某個線程調用了 ManualResetEvent.Set()方法后，其他調用 WaitOne 的線程獲得信號得以繼續執行，而 ManualResetEvent 不會自動將信號置為不發送。
3） 也就是說，除非手工調用了 ManualResetEvent.Reset() 方法，則 ManualResetEvent 將一直保持有信號狀態，ManualResetEvent 也就可以同時喚醒多個線程繼續執行。
示例場景：
張三、李四兩個好朋友去餐館吃飯，兩個人點了一份宮爆雞丁，宮爆雞丁做好需要一段時間，張三、李四不願傻等，都專心致志的玩起了手機游戲，心想宮爆雞丁做好了，服務員肯定會叫我們的。服務員上菜之后，張三李四開始享用美味的飯菜，飯菜吃光了，他們再叫服務員過來買單。
我們可以從這個場景中抽象出來三個線程：
張三線程、李四線程、服務員線程他們之間需要同步：
服務員上菜 -> 張三、李四開始享用宮爆雞丁 -> 吃好后叫服務員過來買單。
這個同步用什么呢？ManualResetEvent 還是 AutoResetEvent？
通過上面的分析不難看出，服務員上完菜需要喚醒張三和李四這2個線程進行消費, 因此我們應該用 ManualResetEvent 進行同步，下面是程序代碼：
using System.Threading;
using System;
public class EventWaitTest
{
private string name; //顧客姓名
// private static AutoResetEvent eventWait = new AutoResetEvent(false);
private static ManualResetEvent eventWait = new ManualResetEvent(false);
private static ManualResetEvent eventOver = new ManualResetEvent(false);
public EventWaitTest(string name)
{
this.name = name;
}
public static void Product()
{
Console.WriteLine("服務員：廚師在做菜呢，兩位稍等");
Thread.Sleep(2000);
Console.WriteLine("服務員：宮爆雞丁好了");
eventWait.Set();
while (true)
{
if (eventOver.WaitOne(1000, false))
{
Console.WriteLine("服務員：兩位請買單");
eventOver.Reset();
}
}
}
public void Consume()
{
while (true)
{
if (eventWait.WaitOne(1000, false))
{
Console.WriteLine(this.name + "：開始吃宮爆雞丁");
Thread.Sleep(2000);
Console.WriteLine(this.name + "：宮爆雞丁吃光了");
eventWait.Reset();
eventOver.Set();
break;
}
else
{
Console.WriteLine(this.name + "：等着上菜無聊先玩會手機游戲");
}
}
}
}
public class App
{
public static void Main(string[] args)
{
EventWaitTest zhangsan = new EventWaitTest("張三");
EventWaitTest lisi = new EventWaitTest("李四");
Thread t1 = new Thread(new ThreadStart(zhangsan.Consume));
Thread t2 = new Thread(new ThreadStart(lisi.Consume));
Thread t3 = new Thread(new ThreadStart(EventWaitTest.Product));
t1.Start();
t2.Start();
t3.Start();
Console.Read();
}
}
編譯后查看運行結果，符合我們的預期，控制台輸出為：服務員：廚師在做菜呢，兩位稍等...... 張三：等着上菜無聊先玩會手機游戲；李四：等着上菜無聊先玩會手機游戲 張三：等着上菜無聊先玩會手機游戲 李四：等着上菜無聊先玩會手機游戲 服務員：宮爆雞丁好了 張三：開始吃宮爆雞丁 李四：開始吃宮爆雞丁 張三：宮爆雞丁吃光了 李四：宮爆雞丁吃光了 服務員：兩位請買單
如果改用 AutoResetEvent 進行同步呢？會出現什么樣的結果？恐怕張三和李四就要打起來了，一個享用了美味的宮爆雞丁，另一個到要付賬的時候卻還在玩游戲。感興趣的朋友可以把注釋的 那行代碼注釋去掉，並把下面一行代碼注釋掉，運行程序看會出現怎樣的結果。
3. Mutex(互斥體）
Mutex 和 EventWaitHandler 有着共同的父類 WaitHandler 類，它們同步的函數用法也差不多，這里不再贅述。Mutex 的突出特點是可以跨應用程序域邊界對資源進行獨占訪問，即可以用於同步不同進程中的線程，這種功能當然這是以犧牲更多的系統資源為代價的。前兩篇簡單介紹了線程同步 lock，Monitor，同步事件 EventWaitHandler，互斥體 Mutex 的基本用法，在此基礎上，我們對它們用法進行比較，並給出什么時候需要鎖什么時候不需要的幾點建議。最后，介紹幾個 FCL 中線程安全的類，集合類的鎖定方式等，做為對線程同步系列的完善和補充。
1. 什么時候需要同步？
lock 和 Monitor 是.NET 用一個特殊結構實現的，Monitor 對象是完全托管的、完全可移植的，並且在操作系統資源要求方面可能更為有效，同步速度較快，但不能跨進程同步。（Monitor.Enter lock 和 Monitor.Exit 方法的封裝），主要作用是鎖定臨界區，使臨界區代碼只能被獲得鎖的線程執行。Monitor.Wait 和 Monitor.Pulse 用於線程同步，類似信號操作，個人感覺使用比較復雜，容易造成死鎖。
互斥體 Mutex 和事件對象 EventWaitHandler 屬於內核對象，利用內核對象進行線程同步，線程必須要在用戶模式和內核模式間切換，所以一般效率很低，但利用互斥對象和事件對象這樣的內核對象，可以在多個進程中的各個線程間進行同步。互斥體 Mutex 類似於一個接力棒，拿到接力棒的線程才可以開始跑，當然接力棒一次只屬於一個線程(Thread Affinity)，如果這個線程不釋放接力棒(Mutex.ReleaseMutex)，那么沒辦法，其他所有需要接力棒運行的線程都只能等着看熱鬧。EventWaitHandle 類允許線程通過發信號互相通信。通常，一個或多個線程在 EventWaitHandle 上阻止，直到一個未阻止的線程調用 Set 方法，以釋放一個或多個被阻止的線程。
2. 什么時候需要鎖定？
首先要理解鎖定是解決競爭條件的，也就是多個線程同時訪問某個資源，造成意想不到的結果。比如最簡單的情況，一個計數器，兩個線程同時加一，后果就是損失了一個計數，但相當頻繁的鎖定又可能帶來性能上的消耗，還有最可怕的情況死鎖。
那么什么情況下我們需要使用鎖，什么情況下不需要呢？
1） 只有共享資源才需要鎖定，只有可以被多線程訪問的共享資源才需要考慮鎖定，比如靜態變量，再比如某些緩存中的值，而屬於線程內部的變量不需要鎖定。
2） 多使用 lock,少用 Mutex 如果你一定要使用鎖定，請盡量不要使用內核模塊的鎖定機制，比如.NET 的 Mutex，Semaphore，AutoResetEvent 和 ManuResetEvent，使用這樣的機制涉及到了系統在用戶模式和內核模式間的切換，性能差很多，但是他們的優點是可以跨進程同步線程，所以應該清楚的了解到他們的不同和適用范圍。
3） 了解你的程序是怎么運行的。實際上在 web 開發中大多數邏輯都是在單個線程中展開的，一個請求都會在一個單獨的線程中處理，其中的大部分變量都是屬於這個線程的，根本沒有必要考慮鎖定，當然對於 ASP.NET 中的 Application 對象中的數據，我們就要考慮加鎖了。
4） 把鎖定交給數據庫。數據庫除了存儲數據之外，還有一個重要的用途就是同步，數據庫本身用了一套復雜的機制來保證數據的可靠和一致性，這就為我們節省了很多的精力。保證了數據源頭上的同步，我們多數的精力就可以集中在緩存等其他一些資源的同步訪問上了。通常，只有涉及到多個線程修改數據庫中同一條記錄時，我們才考慮加鎖。
5） 業務邏輯對事務和線程安全的要求這條是最根本的東西，開發完全線程安全的程序是件很費時費力的事情，在電子商務等涉及金融系統的案例中，許多邏輯都必須嚴格的線程安全，所以我們不得不犧牲一些性能，和很多的開發時間來做這方面的工作。而一般的應用中，許多情況下雖然程序有競爭的危險，我們還是可以不使用鎖定，比如有的時候計數器少一多一，對結果無傷大雅的情況下，我們就可以不用去管它。
3. InterLocked 類
Interlocked 類提供了同步對多個線程共享的變量的訪問的方法。如果該變量位於共享內存中，則不同進程的線程就可以使用該機制。互鎖操作是原子的，即整個操作是不能由相同變量上的另一個互鎖操作所中斷的單元。這在搶先多線程操作系統中是很重要的，在這樣的操作系統中，線程可以在從某個內存地址加載值之后但是在有機會更改和存儲該值之前被掛起。
我們來看一個 InterLock.Increment() 的例子，該方法以原子的形式遞增指定變量並存儲結果，示例如下：
using System.Threading;
using System;
class InterLockedTest
{
public static Int64 i = 0;
public static void Add()
{
for (int i = 0; i < 100000000; i++)
{
Interlocked.Increment(ref InterLockedTest.i);
//InterLockedTest.i = InterLockedTest.i + 1;
}
}
public static void Main(string[] args)
{
Thread t1 = new Thread(new ThreadStart(InterLockedTest.Add));
Thread t2 = new Thread(new ThreadStart(InterLockedTest.Add));
t1.Start();
t2.Start();
t1.Join();
t2.Join();
Console.WriteLine(InterLockedTest.i.ToString());
Console.Read();
}
}
輸出結果： 200000000
如果 InterLockedTest.Add()方法中用注釋掉的語句代替 Interlocked.Increment() 方法，結果將不可預知！每次執行結果不同。InterLockedTest.Add() 方法保證了加 1 操作的原子性，功能上相當於自動給加操作使用了 lock 鎖。同時我們也注意到 InterLockedTest.Add() 用時比直接用 + 號加 1 要耗時的多，所以說加鎖資源損耗還是很明顯的。
4. 集合類的同步
.NET 在一些集合類，如 Queue、ArrayList、HashTable 和 Stack，已經提供了一個供 lock 使用的對象 SyncRoot。用 Reflector 查看了 SyncRoot 屬性（Stack.SynchRoot 略有不同）的源碼如下：
public virtual object SyncRoot
{
get
{
if (this._syncRoot == null)
{
//如果_syncRoot 和 null 相等，將 new object 賦值給_syncRoot
//Interlocked.CompareExchange 方法保證多個線程在使用 syncRoot 時是線程安全的
Interlocked.CompareExchange(ref this._syncRoot, new object (), null);
}
return this._syncRoot;
}
}
這里要特別注意的是 MSDN 提到：從頭到尾對一個集合進行枚舉本質上並不是一個線程安全的過程。即使一個集合已進行同步，其他線程仍可以修改該集合，這將導致枚舉數引發異常。若要在枚舉過程中保證線程安全，可以在整個枚舉過程中鎖定集合，或者捕捉由於其他線程進行的更改而引發的異常。應該使用下面的代碼：
Queue q = new Queue();
lock (q.SyncRoot)
{
foreach (object item in q)
{
//do something
}
}
還有一點需要說明的是，集合類提供了一個是和同步相關的方法 Synchronized， 該方法返回一個對應的集合類的 wrapper 類，該類是線程安全的，因為他的大部分方法都用 lock 進行了同步處理。如HashTable的Synchronized 返回一個新的線程安全的 HashTable 實例，代碼如下：
// 在多線程環境中只要我們用下面的方式實例化 HashTable 就可以了
Hashtable ht = Hashtable.Synchronized(new Hashtable());
// 以下代碼是.NET Framework Class Library 實現，增加對 Synchronized 的認識
[HostProtection(SecurityAction.LinkDemand, Synchronization=true)]
public static Hashtable Synchronized(Hashtable table)
{
if (table == null)
{
throw new ArgumentNullException("table");
}
return new SyncHashtable(table);
}
// SyncHashtable 的幾個常用方法，我們可以看到內部實現都加了 lock 關鍵字保證線程安全
public override void Add(object key, object value)
{
lock (this._table.SyncRoot)
{
this._table.Add(key, value);
}
}
public override void Clear()
{
lock (this._table.SyncRoot)
{
this._table.Clear();
}
}
public override void Remove(object key)
{
lock (this._table.SyncRoot)
{
this._table.Remove(key);
}
}
線程同步是一個非常復雜的話題，這些同步方法的使用場景是怎樣的？究竟有哪些細微的差別？還有待於進一步的學習和實踐。