前幾天與同事激烈討論了一下，有一點(diǎn)收獲，記錄起來。

　　首先給出MSDN的定義：

　　lock 關(guān)鍵字可以用來確保代碼塊完成運(yùn)行，而不會被其他線程中斷。這是通過在代碼塊運(yùn)行期間為給定對象獲取互斥鎖來實(shí)現(xiàn)的。

　　先來看看執(zhí)行過程，代碼示例如下：

　　假設(shè)線程A先執(zhí)行，線程B稍微慢一點(diǎn)。線程A執(zhí)行到lock語句，判斷obj是否已申請了互斥鎖，判斷依據(jù)是逐個(gè)與已存在的鎖進(jìn)行object.ReferenceEquals比較（此處未加證實(shí)），如果不存在，則申請一個(gè)新的互斥鎖，這時(shí)線程A進(jìn)入lock里面了。

　　這時(shí)假設(shè)線程B啟動了，而線程A還未執(zhí)行完lock里面的代碼。線程B執(zhí)行到lock語句，檢查到obj已經(jīng)申請了互斥鎖，于是等待；直到線程A執(zhí)行完畢，釋放互斥鎖，線程B才能申請新的互斥鎖并執(zhí)行l(wèi)ock里面的代碼。

　　接下來說一些該lock什么對象。

　　為什么不能lock值類型，比如lock(1)呢？lock本質(zhì)上Monitor.Enter，Monitor.Enter會使值類型裝箱，每次lock的是裝箱后的對象。lock其實(shí)是類似編譯器的語法糖，因此編譯器直接限制住不能lock值類型。退一萬步說，就算能編譯器允許你lock(1)，但是object.ReferenceEquals(1,1)始終返回false（因?yàn)槊看窝b箱后都是不同對象）,也就是說每次都會判斷成未申請互斥鎖，這樣在同一時(shí)間，別的線程照樣能夠訪問里面的代碼，達(dá)不到同步的效果。同理lock((object)1)也不行。

　　那么lock("xxx")字符串呢？MSDN上的原話是：

　　鎖定字符串尤其危險(xiǎn)，因?yàn)樽址还舱Z言運(yùn)行庫 (CLR)“暫留”。 這意味著整個(gè)程序中任何給定字符串都只有一個(gè)實(shí)例，就是這同一個(gè)對象表示了所有運(yùn)行的應(yīng)用程序域的所有線程中的該文本。因此，只要在應(yīng)用程序進(jìn)程中的任何位置處具有相同內(nèi)容的字符串上放置了鎖，就將鎖定應(yīng)用程序中該字符串的所有實(shí)例。通常，最好避免鎖定 public 類型或鎖定不受應(yīng)用程序控制的對象實(shí)例。例如，如果該實(shí)例可以被公開訪問，則 lock(this) 可能會有問題，因?yàn)椴皇芸刂频拇a也可能會鎖定該對象。這可能導(dǎo)致死鎖，即兩個(gè)或更多個(gè)線程等待釋放同一對象。出于同樣的原因，鎖定公共數(shù)據(jù)類型（相比于對象）也可能導(dǎo)致問題。而且lock(this)只對當(dāng)前對象有效，如果多個(gè)對象之間就達(dá)不到同步的效果。

　　lock(typeof(Class))與鎖定字符串一樣，范圍太廣了。某些系統(tǒng)類提供專門用于鎖定的成員。例如，Array 類型提供 SyncRoot。許多集合類型也提供 SyncRoot。而自定義類推薦用私有的只讀靜態(tài)對象，比如：private static readonly object obj = new object();為什么要設(shè)置成只讀的呢？這時(shí)因?yàn)槿绻趌ock代碼段中改變obj的值，其它線程就暢通無阻了，因?yàn)榛コ怄i的對象變了，object.ReferenceEquals必然返回false。

NET技術(shù)：C#中的lock關(guān)鍵字，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。