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<tkey tvalue></tkey>+ 外部锁（牺牲并发度） 若只是想「重置」，考虑新建实例（
dict = new ConcurrentDictionary<k>()</k>），比
Clear()更可预测
和 Dictionary + lock 相比，ConcurrentDictionary 真的更快吗？
取决于访问模式。在读多写少、key 分布均匀的场景下，
ConcurrentDictionary明显更快；但在高频单 key 写入（如计数器）或极短临界区下，粗粒度
lock可能反而更轻量。
它的分段锁（默认 31 段）减少了争用，但每次操作仍需哈希定位段、加锁、操作、解锁——这些开销在简单场景下未必优于一个
object锁。 测性能别只看吞吐，关注
lock的持有时间与竞争率（可用
Monitor.TryEnter统计等待）
ConcurrentDictionary的
Count属性是 O(n)，别在循环里反复读它 初始化时指定合理容量（如
new ConcurrentDictionary<int>(64)</int>），避免扩容时的全局重哈希锁 真正麻烦的从来不是「能不能用」，而是「哪条路径没锁住」「哪个假设悄悄失效了」。尤其当多个
ConcurrentDictionary方法串在一起，或者混用
Keys/
Values集合时，线程安全的边界就很容易滑出去。
