锁定正在使用的私有静态字段
本文关键字：静态 字段 锁定 | 更新日期: 2023-09-27 18:20:25
可能重复：
使用现有对象而不是创建特定的锁定对象是否安全？
你认为：锁定在我的类中使用的私有静态对象是一种好的做法吗？例如，我有一个包含元素的Dictionary，在修改它时我会锁定（myList）。我更喜欢使用专用的System.Object字段，它只用作锁，但我的同事认为使用专用静态字段是可以的，因为它已经是私有的了。
任何一种方式都可以；但是，我更喜欢一个单独的只读静态对象来进行同步。这样，它的目的对于您正在执行的锁类型来说是显而易见的。
如果为了安全地使用字典或列表而进行锁定，您是否考虑过使用System.Generic.Collections.Concurrent对象？
此外，您是否考虑过ReaderWriterLock？这样，您可以允许多次读取，但可以安全地锁定，一次只允许一次写入。
更多信息
锁定单独的对象与锁定字典本身没有区别。CLR将创建或分配SyncBlock结构并管理锁计数，而不考虑被锁定的对象。更多信息请点击此处：http://msdn.microsoft.com/en-us/magazine/cc188793.aspx
我的想法：
字典的职责是存储数据，而不是同步线程。使用一个用于同步的单独对象，将其标记为私有只读，并适当命名，以便您知道该成员用于锁定。
你和你的队友不太可能对谁在什么时候锁定什么感到困惑。如果字典是双重任务，作为同步对象和字典，那么新队友可能不清楚是否存在锁定，锁定在字典上，他们不应该创建新的同步对象。
新队友可能不知道字典引用具有同步对象和字典的双重责任。该队友可能会试图在类外传递对字典的引用，因为字典可能会以意外的方式锁定，从而导致死锁。单独的同步对象可能会导致其他队友停止并重新考虑传递其引用。
如果该成员被标记为只读，并在调用锁之前进行初始化，那么您基本上可以保证该成员永远不会为null或被换成另一个引用。
CLR中有一些对象专门用于线程同步。SyncLock和Monitor.Enter在大多数情况下都很好，但切换到ReaderWriterLock可以获得更好的性能。不仅可以允许多个线程同时读取，还可以安全地阻止所有线程以允许同步写入。此处的快速示例：http://www.codekicks.com/2008/03/readerwriterlock-cnet-systemthreading.html