1. 程式人生 > 其它 >C#中Lock鎖的物件選擇問題

C#中Lock鎖的物件選擇問題

轉自https://blog.csdn.net/sl1990129/article/details/79150935

1、為什麼不能lock值型別

比如lock(1)呢?lock本質上Monitor.Enter,Monitor.Enter會使值型別裝箱,每次lock的是裝箱後的物件。lock其實是類似編譯器的語法糖,因此編譯器直接限制住不能lock值型別。退一萬步說,就算能編譯器允許你lock(1),但是object.ReferenceEquals(1,1)始終返回false(因為每次裝箱後都是不同物件),也就是說每次都會判斷成未申請互斥鎖,這樣在同一時間,別的執行緒照樣能夠訪問裡面的程式碼,達不到同步的效果。同理lock((object)1)也不行。

2、Lock字串

那麼lock("xxx")字串呢?MSDN上的原話是:

 鎖定字串尤其危險,因為字串被公共語言執行庫 (CLR)“暫留”。 這意味著整個程式中任何給定字串都只有一個例項,就是這同一個物件表示了所有執行的應用程式域的所有執行緒中的該文字。因此,只要在應用程式程序中的任何位置處具有相同內容的字串上放置了鎖,就將鎖定應用程式中該字串的所有例項。

3、MSDN推薦的Lock物件

通常,最好避免鎖定 public 型別或鎖定不受應用程式控制的物件例項。例如,如果該例項可以被公開訪問,則 lock(this) 可能會有問題,因為不受控制的程式碼也可能會鎖定該物件。這可能導致死鎖,即兩個或更多個執行緒等待釋放同一物件。出於同樣的原因,鎖定公共資料型別(相比於物件)也可能導致問題。

而且lock(this)只對當前物件有效,如果多個物件之間就達不到同步的效果。

而自定義類推薦用私有的只讀靜態物件,比如:

 private static readonly object obj = new object();

 為什麼要設定成只讀的呢?這時因為如果在lock程式碼段中改變obj的值,其它執行緒就暢通無阻了,因為互斥鎖的物件變了,object.ReferenceEquals必然返回false。

4、lock(typeof(Class))

與鎖定字串一樣,範圍太廣了。