.NET中Dictionary为何非线程安全？并发读写如何导致异常？

Question

.NET 中 `Dictionary` 默认非线程安全，因其内部未对哈希表扩容（rehash）、桶数组修改、节点插入/删除等操作加锁或采用无锁同步机制。当多个线程同时执行写操作（如 `Add`、`Remove`）时，可能引发哈希桶链表结构不一致、数组越界或 `NullReferenceException`；更隐蔽的是——**并发读写**（如一线程调用 `Count` 或 `ContainsKey`，另一线程正触发扩容）会导致 `InvalidOperationException: "Collection was modified..."` 或内存损坏（.NET 6+ 启用 `ConcurrentDictionary` 优化后仍可能抛出 `ArgumentException`）。即使仅多线程读取，在字典发生结构性变更（如扩容重散列）的瞬态窗口期，也可能因读取到部分更新的桶数组而返回脏数据或崩溃。根本原因在于其设计目标是单线程高性能，所有线程安全责任交由调用方承担。

Answer 1

```html

一、现象层：典型并发异常复现与日志特征

在高并发 Web API 或后台任务中，Dictionary<string, object> 被多个线程共享写入时，常见抛出：NullReferenceException（访问已置空的 entries 数组项）、IndexOutOfRangeException（桶索引越界）、以及最频繁的 InvalidOperationException: "Collection was modified; enumeration operation may not execute."。该异常并非仅限于 foreach 枚举——Count 属性读取、ContainsKey 查找、甚至 TryGetValue 均可能触发，因其底层均依赖 version 字段校验结构性变更。

二、机制层：Dictionary 内存布局与非安全临界点剖析

Dictionary<TKey,TValue> 采用开放寻址+链地址混合哈希结构，核心字段包括：Entry[] entries（桶节点数组）、int[] buckets（哈希桶首节点索引）、int count、int version（修改计数器）及 int freeList（空闲链表头）。所有写操作（Add/Remove/Clear）均直接修改这些字段，且 无任何内存屏障（MemoryBarrier）或 volatile 语义保障跨核可见性。扩容（rehash）时需原子性重建 buckets 和 entries，但实际执行为分步非原子操作——先分配新数组，再逐项迁移，最后交换引用。此窗口期即为并发灾难温床。

三、验证层：最小可复现实验与竞态路径图

graph LR
    A[Thread-1: Add key1] --> B{触发扩容？}
    B -- 是 --> C[分配 newEntries/newBuckets]
    C --> D[开始迁移 entry #0~#n/2]
    E[Thread-2: ContainsKey key2] --> F[读取旧 buckets[key2.GetHashCode%oldLength]]
    F --> G[可能指向已迁移/未迁移/空闲 entry]
    G --> H[NullReference 或脏值]
    D --> I[更新 version++]
    I --> J[Thread-3: Count get → 检查 version ≠ cached → throw InvalidOperationException]

四、对比层：ConcurrentDictionary 的演进与边界

特性	Dictionary<K,V>	ConcurrentDictionary<K,V>	备注
扩容策略	全局锁 + 全量 rehash	分段锁（.NET Core 3.0+ 改为无锁分段扩容）	.NET 6 后支持 TryAdd 无锁插入
读写一致性	无保证（脏读/崩溃）	最终一致性（读不阻塞，但可能见旧值）	GetEnumerator() 返回快照视图
异常语义	InvalidOperationException 高频	ArgumentException 仅当键重复且 addValueFactory 抛出	规避了 “Collection was modified” 类异常

五、方案层：生产级线程安全选型矩阵

1. 纯读多写少：用 ImmutableDictionary<K,V> + Interlocked.CompareExchange 替换，牺牲写性能保读一致性；
2. 读写均衡：首选 ConcurrentDictionary<K,V>，但须禁用 Keys/Values 属性（返回非线程安全包装器）；
3. 强一致性要求：外层加 ReaderWriterLockSlim，读用 EnterReadLock，写用 EnterWriteLock；
4. 领域特定优化：如缓存场景，可用 Lazy<T> 包装 value，配合 GetOrAdd 避免重复初始化竞争；
5. 诊断辅助：启用 DOTNET_SYSTEM_THREADING_USEGLOBALLOCK=1（.NET 7+）强制降级为全局锁模式，用于快速定位是否为并发问题。

六、根因层：设计哲学与性能契约

Dictionary<TKey,TValue> 的非线程安全绝非缺陷，而是明确的设计契约——其 O(1) 平均查找、极低内存开销（无锁结构体字段）、零分配扩容（.NET 5+）等优势，全部建立在“单线程调用上下文”假设之上。微软文档明确声明：“This class is not thread safe for concurrent writes. It is also not safe for concurrent reads and writes.”。将线程安全责任移交调用方，既保持核心类型轻量，又避免为不需并发的 90% 场景支付同步成本。真正的工程成熟度，体现在能否精准识别该契约边界，并在架构层主动隔离共享状态。

```