可能重复：
Is using an existing object rather than creating a specific lock object safe?
您如何看待：锁定我班级中正在使用的私有静态对象是一种好习惯吗？例如，我有包含元素的Dictionary，在修改它时我会锁定（myList）。我更喜欢使用专门用作锁的特殊私有System.Object字段，但我的同事认为使用私有静态字段是可以的，因为它已经是私有的。
答案 0 :(得分：3)
无论哪种方式都有效;但是，我更喜欢一个单独的只读静态对象进行同步。这样，它的目的对于您正在执行的锁定类型是显而易见的。
如果要锁定以便安全地使用字典或列表，您是否考虑过使用System.Generic.Collections.Concurrent对象？
另外，您是否考虑过ReaderWriterLock？这样你就可以允许多次读取，但是安全地锁定一次只允许一次写入。
更多信息
锁定单独的对象与锁定字典本身没有区别。 CLR将创建或分配SyncBlock结构并管理锁定计数，而不考虑被锁定的对象。有关此处的更多信息：http://msdn.microsoft.com/en-us/magazine/cc188793.aspx
我的想法：
字典的职责是存储数据，而不是同步线程。使用一个用于同步的单独对象，将其标记为私有只读，并对其进行适当命名，以便您知道该成员是用于锁定的。
你和你的队友不太可能对谁锁定什么和何时锁定感到困惑。如果字典是双重任务，作为同步对象和字典，那么新的队友可能不会明白存在锁定，它在字典上，并且它们不应该创建新的同步对象。
新的队友可能不知道词典引用作为同步对象和字典具有双重责任。该队友可能会试图传递对类外的字典的引用，因为它可能以一种导致死锁的意外方式被锁定。一个单独的同步对象可能会导致其他队友停下来并重新考虑传递其引用。
如果在调用锁之前将成员标记为只读并初始化，那么您最常保证该成员永远不会为空或换出以供另一个引用。
CLR中有些对象专门用于线程同步。在大多数情况下，SyncLock和Monitor.Enter很好，但是通过切换到ReaderWriterLock可以获得更好的性能。您不仅可以允许多个线程同时读取，而且可以安全地阻止所有线程以允许同步写入。这里的简单示例：http://www.codekicks.com/2008/03/readerwriterlock-cnet-systemthreading.html