Dictionary与ConcurrentDictionary适用场景咨询及数组越界异常排查

这问题我太熟了！之前帮好几个朋友排查过类似的Dictionary数组越界问题，大概率是你新增的代码引入了多线程并发读写的场景——而Dictionary本身根本扛不住这种情况，这也是它和线程安全集合（比如ConcurrentDictionary）最核心的适用场景区别。

先说说你遇到的异常根源 #

Dictionary<TKey, TValue> 是非线程安全的集合，内部的哈希表结构（比如存储键值对的数组）在扩容、添加/删除元素时，没有任何线程同步机制。当多个线程同时对它进行读写操作时，会直接破坏内部数组的状态——比如一个线程正在扩容数组，另一个线程还在访问旧数组的索引，就会抛出「Index was outside the bounds of the array.」这种诡异的异常。你之前的代码稳定，就是因为构造函数初始化加键值对是单线程场景，完全在Dictionary的安全范围内。

两者的适用场景差异 #

1. Dictionary<TKey, TValue> 适用场景 #

• 单线程环境：这是它的舒适区，读写速度极快，内存开销小，适合不需要考虑并发的业务逻辑（比如你之前构造函数里的初始化操作）。
• 只读/极少写的多线程场景：如果只是多线程读取，且能保证整个生命周期内几乎没有写操作（比如初始化后就不再修改），可以勉强用，但最好还是用 Dictionary.AsReadOnly() 包装一下，避免意外的写操作。
• 完全可控的线程访问场景：比如你能通过自己的锁逻辑（比如lock）严格保证同一时间只有一个线程在写，其他线程要么等待要么只读，这种情况下用Dictionary比线程安全集合的性能更高。

2. ConcurrentDictionary<TKey, TValue> 适用场景 #

• 多线程并发读写场景：这是它的设计初衷，内部用了分段锁、无锁算法等优化机制，能安全处理多个线程同时读写的情况，不会出现数组越界、数据错乱、枚举异常等问题。
• 无法完全控制线程访问的场景：比如你的新增代码里用到了异步任务、线程池线程，或者第三方组件会并发操作这个集合，自己加锁又容易出现死锁、锁粒度太大导致性能下降的问题，直接用ConcurrentDictionary省心又高效。
• 需要原子操作的场景：比如你需要实现「不存在则添加，存在则更新」「获取或创建」这类逻辑，ConcurrentDictionary提供了AddOrUpdate、GetOrAdd等原子方法，不用自己写复杂的锁逻辑就能安全实现。

给你的修复建议 #

如果你的新增代码确实引入了并发读写，直接把Dictionary替换成ConcurrentDictionary就能解决这个数组越界的问题——不需要改太多代码，大部分方法（比如TryGetValue）的调用方式都是兼容的。如果不想换集合，那就要在所有读写操作外面加上lock锁，但性能会比ConcurrentDictionary差一些，而且要注意锁对象不能是集合本身（最好用单独的私有锁对象）。

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