C# 多執行緒(lock,Monitor,Mutex,同步事件和等待控制代碼)
原文地址:http://www.cnblogs.com/SkySoot/archive/2012/04/02/2430295.html
本篇從 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);
}
}
執行緒同步是一個非常複雜的話題,這些同步方法的使用場景是怎樣的?究竟有哪些細微的差別?還有待於進一步的學習和實踐。