為什麼不要 lock this

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

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

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

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

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

二. lock(this)怎麼了？

我們看乙個例子：

lock

using

system;

using

system.threading;

namespace

namespace1}}

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

public

void

donotlockme()

}class

program}}

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

把c1的**稍作改動：

c1classc1}

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

public

void

donotlockme()

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

關鍵點：

1. lock(this)的缺點就是在乙個執行緒（例如本例的t1）通過執行該類的某個使用"lock(this)"的方法(例如本例的lockme())鎖定某物件之後, 導致整個物件無法被其他執行緒(例如本例的主線程)訪問 - 因為程式設計師可以在任何其他執行緒(例如本例的主線程)訪問該類的時候使用類似lock(c1)的**,因此我們在設計類的時候就最好未雨綢繆，而不是把負擔留給使用者。

2. 我們應該使用不影響其他操作和不會被外部物件鎖定的的私有成員作為locker。

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

為什麼不要 lock this

為什麼不要 lock this

為什麼不要用 StringBuffer

為什麼不要用select

為什麼不要 lock this

為什麼不要 lock this

為什麼不要用 StringBuffer

為什麼不要用select

相關推薦