以下各節(jié)描述了在多線程應用程序中可以用來同步資源訪問的功能和類。
在應用程序中使用多個線程的一個好處是每個線程都可以異步執(zhí)行。對于 Windows 應用程序，耗時的任務可以在后臺執(zhí)行，而使應用程序窗口和控件保持響應。對于服務器應用程序，多線程處理提供了用不同線程處理每個傳入請求的能力。否則，在完全滿足前一個請求之前，將無法處理每個新請求。
然而，線程的異步特性意味著必須協(xié)調(diào)對資源（如文件句柄、網(wǎng)絡連接和內(nèi)存）的訪問。否則，兩個或更多的線程可能在同一時間訪問相同的資源，而每個線程都不知道其他線程的操作。結(jié)果將產(chǎn)生不可預知的數(shù)據(jù)損壞。
對于整數(shù)數(shù)據(jù)類型的簡單操作，可以用 Interlocked 類的成員來實現(xiàn)線程同步。對于其他所有數(shù)據(jù)類型和非線程安全的資源，只有使用本主題中的結(jié)構(gòu)才能安全地執(zhí)行多線程處理。
有關(guān)多線程編程的背景信息，請參見：
lock 關(guān)鍵字
lock 關(guān)鍵字可以用來確保代碼塊完成運行，而不會被其他線程中斷。這是通過在代碼塊運行期間為給定對象獲取互斥鎖來實現(xiàn)的。
lock 語句以關(guān)鍵字 lock 開頭，它有一個作為參數(shù)的對象，在該參數(shù)的后面還有一個一次只能由一個線程執(zhí)行的代碼塊。例如：
public void Function()
{
System.Object lockThis = new System.Object();
lock(lockThis)
{
// Access thread-sensitive resources.
}
}
提供給 lock 關(guān)鍵字的參數(shù)必須為基于引用類型的對象，該對象用來定義鎖的范圍。在上例中，鎖的范圍限定為此函數(shù)，因為函數(shù)外不存在任何對該對象的引用。嚴格地說，提供給 lock 的對象只是用來唯一地標識由多個線程共享的資源，所以它可以是任意類實例。然而，實際上，此對象通常表示需要進行線程同步的資源。例如，如果一個容器對象將被多個線程使用，則可以將該容器傳遞給 lock，而 lock 后面的同步代碼塊將訪問該容器。只要其他線程在訪問該容器前先鎖定該容器，則對該對象的訪問將是安全同步的。
通常，最好避免鎖定 public 類型或鎖定不受應用程序控制的對象實例。例如，如果該實例可以被公開訪問，則 lock(this) 可能會有問題，因為不受控制的代碼也可能會鎖定該對象。這可能導致死鎖，即兩個或更多個線程等待釋放同一對象。出于同樣的原因，鎖定公共數(shù)據(jù)類型（相比于對象）也可能導致問題。鎖定字符串尤其危險，因為字符串被公共語言運行庫 (CLR)“暫留”。這意味著整個程序中任何給定字符串都只有一個實例，就是這同一個對象表示了所有運行的應用程序域的所有線程中的該文本。因此，只要在應用程序進程中的任何位置處具有相同內(nèi)容的字符串上放置了鎖，就將鎖定應用程序中該字符串的所有實例。因此，最好鎖定不會被暫留的私有或受保護成員。某些類提供專門用于鎖定的成員。例如，Array 類型提供 SyncRoot。許多集合類型也提供 SyncRoot。
有關(guān) lock 關(guān)鍵字的更多信息，請參見：
監(jiān)視器
與 lock 關(guān)鍵字類似，監(jiān)視器防止多個線程同時執(zhí)行代碼塊。Enter 方法允許一個且僅一個線程繼續(xù)執(zhí)行后面的語句；其他所有線程都將被阻止，直到執(zhí)行語句的線程調(diào)用 Exit。這與使用 lock 關(guān)鍵字一樣。事實上，lock 關(guān)鍵字就是用 Monitor 類來實現(xiàn)的。例如：
lock(x)
{
DoSomething();
}
這等效于：
System.Object obj = (System.Object)x;
System.Threading.Monitor.Enter(obj);
try
{
DoSomething();
}
finally
{
System.Threading.Monitor.Exit(obj);
}
使用 lock 關(guān)鍵字通常比直接使用 Monitor 類更可取，一方面是因為 lock 更簡潔，另一方面是因為 lock 確保了即使受保護的代碼引發(fā)異常，也可以釋放基礎監(jiān)視器。這是通過 finally 關(guān)鍵字來實現(xiàn)的，無論是否引發(fā)異常它都執(zhí)行關(guān)聯(lián)的代碼塊。
有關(guān)監(jiān)視器的更多信息，請參見監(jiān)視器同步技術(shù)示例。
同步事件和等待句柄
使用鎖或監(jiān)視器對于防止同時執(zhí)行區(qū)分線程的代碼塊很有用，但是這些構(gòu)造不允許一個線程向另一個線程傳達事件。這需要“同步事件”，它是有兩個狀態(tài)（終止和非終止）的對象，可以用來激活和掛起線程。讓線程等待非終止的同步事件可以將線程掛起，將事件狀態(tài)更改為終止可以將線程激活。如果線程試圖等待已經(jīng)終止的事件，則線程將繼續(xù)執(zhí)行，而不會延遲。
同步事件有兩種：AutoResetEvent 和 ManualResetEvent。它們之間唯一的不同在于，無論何時，只要 AutoResetEvent 激活線程，它的狀態(tài)將自動從終止變?yōu)榉墙K止。相反，ManualResetEvent 允許它的終止狀態(tài)激活任意多個線程，只有當它的 Reset 方法被調(diào)用時才還原到非終止狀態(tài)。
可以通過調(diào)用一種等待方法，如 WaitOne、WaitAny 或 WaitAll，讓線程等待事件。System.Threading.WaitHandle.WaitOne 使線程一直等待，直到單個事件變?yōu)榻K止狀態(tài)；System.Threading.WaitHandle.WaitAny 阻止線程，直到一個或多個指示的事件變?yōu)榻K止狀態(tài)；System.Threading.WaitHandle.WaitAll 阻止線程，直到所有指示的事件都變?yōu)榻K止狀態(tài)。當調(diào)用事件的 Set 方法時，事件將變?yōu)榻K止狀態(tài)。
在下面的示例中，創(chuàng)建了一個線程，并由 Main 函數(shù)啟動該線程。新線程使用 WaitOne 方法等待一個事件。在該事件被執(zhí)行 Main 函數(shù)的主線程終止之前，該線程一直處于掛起狀態(tài)。一旦該事件終止，輔助線程將返回。在本示例中，因為事件只用于一個線程的激活，所以使用 AutoResetEvent 或 ManualResetEvent 類都可以。
using System;
using System.Threading;
class ThreadingExample
{
static AutoResetEvent autoEvent;
static void DoWork()
{
Console.WriteLine(" worker thread started, now waiting on event...");
autoEvent.WaitOne();
Console.WriteLine(" worker thread reactivated, now exiting...");
}
static void Main()
{
autoEvent = new AutoResetEvent(false);
Console.WriteLine("main thread starting worker thread...");
Thread t = new Thread(DoWork);
t.Start();
Console.WriteLine("main thrad sleeping for 1 second...");
Thread.Sleep(1000);
Console.WriteLine("main thread signaling worker thread...");
autoEvent.Set();
}
}
有關(guān)線程同步事件用法的更多示例，請參見：
Mutex 對象
mutex 與監(jiān)視器類似；它防止多個線程在某一時間同時執(zhí)行某個代碼塊。事實上，名稱“mutex”是術(shù)語“互相排斥 (mutually exclusive)”的簡寫形式。然而與監(jiān)視器不同的是，mutex 可以用來使跨進程的線程同步。mutex 由 Mutex 類表示。
當用于進程間同步時，mutex 稱為“命名 mutex”，因為它將用于另一個應用程序，因此它不能通過全局變量或靜態(tài)變量共享。必須給它指定一個名稱，才能使兩個應用程序訪問同一個 mutex 對象。
盡管 mutex 可以用于進程內(nèi)的線程同步，但是使用 Monitor 通常更為可取，因為監(jiān)視器是專門為 .NET Framework 而設計的，因而它可以更好地利用資源。相比之下，Mutex 類是 Win32 構(gòu)造的包裝。盡管 mutex 比監(jiān)視器更為強大，但是相對于 Monitor 類，它所需要的互操作轉(zhuǎn)換更消耗計算資源。有關(guān) mutex 的用法示例，請參見 Mutex。