C 說說lock到底鎖誰？（2）

今天在園子裡面有園友反饋關於[c#基礎]說說lock到底鎖誰？文章中lock(this)的問題。後來針對文章中的例子，仔細想了一下，確實不準確，才有了這篇文章的補充，已經對文章中的demo進行修改。

乙個例子

using
system;
using
system.collections.generic;
using
system.linq;
using
system.text;
using
system.threading;
using
system.threading.tasks;
namespace
locktest
); th.start();
thread.sleep(
1000
); thread th2 = new thread(() =>
});th2.start();
console.read();}}
class
testlock
console.writeline(i.tostring());
i++;}}
console.writeline(
"lock dispose");
}public
void
mothercallyoudinner()}}

測試

那麼通過lock(static object)方式呢，能不能保證lock塊內的方法，同時只被乙個執行緒執行呢，並且執行緒2能訪問到mothercallyoudinner方法。而不像上面出現的那種情況，如果不釋放lock(this)，導致執行緒2都無法執行**邏輯。

using
system;
using
system.collections.generic;
using
system.linq;
using
system.text;
using
system.threading;
using
system.threading.tasks;
namespace
locktest
); th.start();
thread.sleep(
1000
); thread th2 = new thread(() =>
});th2.start();
console.read();}}
class
testlock
console.writeline(i.tostring());
i++;}}
console.writeline(
"lock dispose");
}public
void
mothercallyoudinner()}}

測試

可以看到，將lock(this)更換為鎖定私有的靜態物件，執行緒2執行了，首先輸出了「your mother call you to home for dinner.」，同時實現了doworkwithlock方法中lock的**塊當前只被乙個執行緒執行，直到lcok（objlock）被釋放。因為鎖定的物件，外部不能訪問，執行緒2不再關心lock（this）是不是已經釋放，都會執行，當然也保證了方法doworkwithlock同時被乙個執行緒訪問。

1、避免使用lock(this)，因為無法保證你提供的方法，在外部類中使用的時候，開發人員會不會鎖定當前物件。

通常，應避免鎖定public型別，否則例項將超出**的控制範圍。常見的結構 lock (this)、lock (typeof (mytype)) 和 lock ("mylock") 違反此準則：

最佳做法是定義private物件來鎖定, 或private static物件變數來保護所有例項所共有的資料。

這裡只是說明lock(this)的問題，雖然極端。但開發中，不能保證不會發生。

2、最好使用私有的靜態唯讀的鎖物件，保證不會影響其他邏輯的正常執行。

3、盡量避免死鎖的發生。

why is lock(this) bad?

C 說說lock到底鎖誰？（2）

C 基礎說說lock到底鎖誰？

說說lock到底鎖誰 I ？

C 執行緒Lock鎖只能鎖定物件

C 說說lock到底鎖誰？（2）

C 基礎 說說lock到底鎖誰？

說說lock到底鎖誰 I ？

C 執行緒Lock鎖 只能鎖定物件

相關推薦

C 基礎說說lock到底鎖誰？

C 執行緒Lock鎖只能鎖定物件