C# 并发字典ConcurrentDictionary方法 C#如何实现线程安全的字典操作

AddOrUpdate 不是原子的，因其先执行工厂函数再插入或更新，多线程下同一 key 可能多次调用工厂函数且仅保留最后一次结果；工厂函数须为纯函数，否则副作用会导致问题。

ConcurrentDictionary 的 AddOrUpdate 为什么不是原子的？

AddOrUpdate 看似一步到位，实际是「先读再写」：它会先调用 key 对应的 updateValueFactory（或 addValueFactory），再尝试插入或更新。如果多个线程同时触发对同一个 key 的 AddOrUpdate，可能多次执行工厂函数，且最终只保留最后一次写入结果。

这不是 bug，而是设计使然——它不保证工厂函数只执行一次。若工厂逻辑有副作用（如发 http 请求、修改外部状态），就会出问题。

• 安全用法：工厂函数必须是纯函数（无副作用、幂等）
• 替代方案：对关键逻辑加锁，或改用 GetOrAdd + 显式 TryUpdate
• 注意 updateValueFactory 参数是旧值，不是当前线程看到的“最新”值，可能已过期

TryGetValue 和 ContainsKey 在高并发下会返回不一致结果吗？

会。因为 ConcurrentDictionary 不提供跨操作的事务性保证。ContainsKey 返回 true 后，紧接着调用 TryGetValue，仍可能返回 false——中间 key 被其他线程删掉了。

这不是线程不安全，而是「最终一致性」模型的体现：每个方法自身线程安全，但组合使用时无同步语义。

• 永远不要写 if (dict.ContainsKey(k)) dict.TryGetValue(k, out v)
• 直接用 TryGetValue 一次完成「查+取」，它比 ContainsKey + 索引器更高效也更可靠
• ContainsKey 仅适合做存在性探针（比如日志打点、监控），不用于控制流程分支

Clear() 方法在遍历时调用会导致异常吗？

不会抛出 InvalidOperationException，但遍历结果不可靠：Clear() 是立即清空内部桶数组的，而正在执行的 foreach 或 GetEnumerator() 可能仍在读旧结构，导致漏项、重复项，甚至跳过刚插入的项。

它不阻塞遍历，也不等待遍历结束——这是性能换一致性的典型取舍。

• Clear() 后继续遍历，行为未定义，.net 不承诺任何顺序或完整性
• 需要强一致性？改用 lock 包裹整个字典操作，或换 Dictionary + 外部锁（牺牲并发度）
• 若只是想「重置」，考虑新建实例（dict = new ConcurrentDictionary()），比 Clear() 更可预测

和 Dictionary + lock 相比，ConcurrentDictionary 真的更快吗？

取决于访问模式。在读多写少、key 分布均匀的场景下，ConcurrentDictionary 明显更快；但在高频单 key 写入（如计数器）或极短临界区下，粗粒度 lock 可能反而更轻量。

它的分段锁（默认 31 段）减少了争用，但每次操作仍需哈希定位段、加锁、操作、解锁——这些开销在简单场景下未必优于一个 Object 锁。

• 测性能别只看吞吐，关注 lock 的持有时间与竞争率（可用 Monitor.TryEnter 统计等待）
• ConcurrentDictionary 的 count 属性是 O(n)，别在循环里反复读它
• 初始化时指定合理容量（如 new ConcurrentDictionary(64)），避免扩容时的全局重哈希锁

真正麻烦的从来不是「能不能用」，而是「哪条路径没锁住」「哪个假设悄悄失效了」。尤其当多个 ConcurrentDictionary 方法串在一起，或者混用 Keys/Values 集合时，线程安全的边界就很容易滑出去。