舊事重提了，或許很多人會奇怪，為什么 C# 不允許lock一個struct ? 例如：public void PRocessTask(int taskid){ lock(taskid){ ..... }}編譯說lock只能使用引用類型。有些人聰明（我想我以前也有這樣的"聰明"。。），這樣做: lock((object)taskid){...}但是，實際的經驗告訴我，這樣行不通，lock需要的是引用，嚴格來說是需要對象的實例。即使對象在意義上是相同的，但是如果不是ReferenceEquals的話，那么將作為兩個實例來對待，那么C# lock 的就不是同一個東西。也就是說，當你以為這個 lock 生效的話，它其實在做無用工。在上面的例子，由于lock((object)taskid)每執行一次，taskid都進行一次裝箱，而裝箱后的對象不是同一個實例(都是完完全全的新的實例)，所以 lock((object)taskid){...} 是白做了。當然，lock((object)123){} 這樣的做法也是一樣有問題的。但是這種就好點：lock(“helloworld“){} 。為什么只是“好點”，而不是“沒有問題”了呢。原因在于DotNet分配字符串的機制。DotNet為每個Assembly里的字符串都分配固定的空間。所以每次引用“helloworld“的時候，是同一個實例。但是這個字符串不會在其他Assembly中得到共用。如果幾個Assembly都是這樣寫的，那么它們各自有她們自己的“helloworld“比較好的做法:lock(this)...lock(typeof(ThisType))lock(GetType())//除非你明白這是干什么，否則不要亂來。lock(SomeType.StaticSyncObject)lock(someinst.SyncObject)其他的一些不好的做法lock(“task:“+id)lock(filename)當然，具體lock什么東西，是設計上的協議和規范。不過要注意的是，使用lock必須明確對象是不是想象中的同一實例。如果需要針對一個變化的值，從它的意義上的Equals方面進行 lock ，那怎么辦？這個可以參考 http://www.lostinet.com/files/ 下的 HashCodeLock (里面很多細節可以優化）