為什麼不要 lock this

當我們使用執行緒的時候，效率最高的方式當然是非同步，即各個執行緒同時執行，其間不相互依賴和等待。但當不同的執行緒都需要訪問某個資源的時候，就需要同步機制了，也就是說當對同乙個資源進行讀寫的時候，我們要使該資源在同一時刻只能被乙個執行緒操作，以確保每個操作都是有效即時的，也即保證其操作的原子性。lock是c#中最常用的同步方式，格式為lock(objecta) 。

lock(objecta) 看似簡單，實際上有三個意思，這對於適當地使用它至關重要：

1. objecta被lock了嗎？沒有則由我來lock，否則一直等待，直至objecta被釋放。

2. lock以後在執行codeb的期間其他執行緒不能呼叫codeb，也不能使用objecta。

3. 執行完codeb之後釋放objecta，並且codeb可以被其他執行緒訪問。

我們看乙個例子：

using

system;

using

system.threading;

namespace

namespace1}}

//所有執行緒都可以同時訪問的方法

public

void

donotlockme()

}class

program}}

在t1執行緒中，lockme呼叫了lock(this), 也就是main函式中的c1，這時候在主線程中呼叫lock(c1)時，必須要等待t1中的lock塊執行完畢之後才能訪問c1，即所有c1相關的操作都無法完成，於是我們看到連c1.donotlockme()都沒有執行。

把c1的**稍作改動：

classc1}

}//所有執行緒都可以同時訪問的方法

public

void

donotlockme()}

這次我們使用乙個私有成員作為鎖定變數(locker)，在lockme中僅僅鎖定這個私有locker，而不是整個物件。這時候重新執行程式，可以看到雖然t1出現了死鎖，donotlockme()仍然可以由主線程訪問；lockme()依然不能訪問，原因是其中鎖定的locker還沒有被t1釋放。

關鍵點：

1. lock(this)的缺點就是在乙個執行緒鎖定某物件之後導致整個物件無法被其他執行緒訪問。

2. 鎖定的不僅僅是lock段裡的**，鎖本身也是執行緒安全的。

3. 我們應該使用不影響其他操作的私有物件作為locker。

4. 在使用lock的時候，被lock的物件(locker)一定要是引用型別的，如果是值型別，將導致每次lock的時候都會將該物件裝箱為乙個新的引用物件(事實上如果使用值型別，c#編譯器(3.5.30729.1)在編譯時就會給出乙個錯誤)。

為什麼不要 lock this

為什麼不要 lock this

為什麼不要用 StringBuffer

為什麼不要用select

為什麼不要 lock this

為什麼不要 lock this

為什麼不要用 StringBuffer

為什麼不要用select

相關推薦