带锁或Concurency词典的字典？
这在multithreading应用程序中是首选：带锁对象的字典或并发字典
哪个有效，我为什么要使用其中一个？
编辑1：将Guid存储为键，将bool存储为值。
编辑2：超过2个工作线程和一个UI线程。
仔细阅读ConcurrentDictionary 。 它有一些不明显的特点。
这里是其中的一些：
- 如果两个线程调用
AddOrUpdate则无法保证将调用哪个工厂AddOrUpdate，甚至不能保证如果工厂AddOrUpdate将生成某个项目，该项目将存储在字典中。 - 通过
GetEnumerator调用获得的枚举器不是快照，可以在枚举期间进行修改（不会导致任何exception）。 -
Keys和Values属性是相应集合的快照，可能与实际字典状态不对应。 - 等等
所以请再次阅读ConcurrentDictionary ，并确定是否需要这种行为。
希望这可以帮助！
我会说你有以下选择。
一些新的Framework 4.0类：
- ConcurrentDictionary 。 工作快速可靠。
- ConcurrentBag 。 它是无序的对象集合 ，因此它的工作速度更快，但如果您不需要排序则适合。
- ConcurrentStack 。 它是经典LIFO （ 后进先出）数据结构的实现，提供线程安全访问，无需外部同步
- ConcurrentQueue 。 它是一个线程安全的FIFO （ 先进先出 ） 集合 。
所有新的4.0类都运行得更快，但有levanovd提到的一些function。 您可以在此处找到这些类的性能比较。
早期版本的一些经典解决方案：
- 字典 + 监视器 。 简单包裹锁定
- 字典 + ReaderWriterLock 。 比前一个好，因为有读写锁。 因此，几个线程可以读取，只需一个 – 写入。
- Dictionary + ReaderWriterLockSlim 。 这只是前一个的优化。
- 哈希表 。 根据我的经验，这是最慢的方法。 检查Hashtable.Synchronized（）方法，它是微软准备好的解决方案。
如果我有使用Framework v3.5的限制，我会使用Dictionary + ReaderWriterLock或ReaderWriterLockSlim 。
当您使用锁定对象实现字典时，您的主要关注点似乎是线程安全。 看来，concurrentDictionary已经解决了这个问题。 我认为重新发明轮子是没有意义的。
我认为两者都将提供线程安全，但是使用带锁定对象的Dictionary会将可以同时访问Dictionary的线程数限制为1.使用Concurrent Dictionary时，可以指定并发级别（即可以访问Dictionary的线程数）兼）。 如果性能确实重要，我相信Concurrent Dictionary应该是你的选择。