舊事重提了，或許很多人會奇怪，為什麼 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 (裡面很多細節可以優化）
