为何ConcurrentDictionary查询性能优于普通Dictionary？

1. 你的基准测试可能存在这些潜在问题 #

• 测试环境没对齐：如果用Debug模式跑测试，JIT优化未启用，结果毫无参考性；另外如果没做预热（先跑几轮测试再统计），第一次运行的JIT编译开销会拉高耗时，导致结果失真。
• 查询方法不一致：普通Dictionary用[]索引会在键不存在时抛异常，而TryGetValue才是和ConcurrentDictionary对等的安全查询方式——如果你的测试里Dictionary用了[]，两者的逻辑成本不一样，性能对比不公平。
• 单线程测试的特殊性：ConcurrentDictionary在单线程读场景下有专门的无锁优化，几乎没锁开销，但如果是多线程写场景，它的锁开销才会体现出来，你当前的测试场景可能没覆盖到写并发。
• 样本量与随机性不足：小数据量（1-50）的测试结果容易受偶然因素影响，比如某次测试的哈希冲突特别少，单次结果不代表普遍情况，需要多次运行取平均值。
• GC干扰：测试前没强制GC的话，内存回收的开销会混入性能统计，导致数据不准。

2. 这个结果有合理的技术逻辑 #

ConcurrentDictionary的性能表现并非偶然，核心在于它的实现优化：

• 无锁读路径：它用分段锁保证线程安全，但单线程读场景下完全不需要加锁——通过volatile变量保证内存可见性，读操作的开销和普通Dictionary几乎一致，甚至更低。
• 哈希结构优化：部分.NET版本中，ConcurrentDictionary的哈希算法和冲突处理逻辑比普通Dictionary更高效，小数据量下哈希冲突更少，查询更快。
• 单线程场景针对性优化：新版.NET（如.NET Core 3.0+）对ConcurrentDictionary做了单线程优化，移除了不必要的锁检查逻辑，进一步降低了单线程下的开销。
• 缓存行对齐：ConcurrentDictionary的内部结构做了缓存行对齐，减少CPU缓存失效的概率，提升了查询的缓存命中率，在小数据量下优势更明显。

3. 绝对不要始终使用ConcurrentDictionary #

要根据场景选择合适的集合：

• 单线程场景：优先用普通Dictionary。ConcurrentDictionary即使在单线程下，写操作（增删改）依然有额外开销（比如更新volatile变量、检查分段锁），内存占用也更大（分段结构带来的冗余内存），Dictionary在单线程下写更快、内存更省。
• 多线程读写并发场景：必须用ConcurrentDictionary（或其他线程安全集合），此时它的分段锁能在保证线程安全的同时，提供比全局锁集合更好的性能。
• 只读/极少写的多线程场景：可以用普通Dictionary配合ReaderWriterLockSlim，或者初始化后保持只读，这种方案的性能比ConcurrentDictionary更好，但前提是能严格控制写入操作。

内容的提问来源于stack exchange，提问作者Zyo