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 集合时，线程安全的边界就很容易滑出去。 
