在框架中，字典的选择要比列表少得多。只有三个主流的非并发 IDictionary<TKey, TValue> 实现，此外还有 ExpandoObject （第14章已介绍过）、 ConcurrentDictionary （将 在介绍其他并发集合时介绍）和 RouteValueDictionary （用于路由Web请求，特别是在ASP.NET MVC中）也实现了该接口。
注意，字典的主要目的在于为值提供有效的键查找。
B.3.1 Dictionary<TKey, TValue>
如果没有特殊需求， Dictionary<TKey, TValue> 将是字典的默认选择，就像 List<T> 是 列表的默认实现一样。它使用了散列表，可以实现有效的查找（参见http://mng.bz/qTdH），虽然 这意味着字典的效率取决于散列函数的优劣。可使用默认的散列和相等函数（调用键对象本身的 Equals 和 GetHashCode ），也可以在构造函数中指定 IEqualityComparer<TKey> 作为参数。 最简单的示例是用不区分大小写的字符串键实现字典，如代码清单B-1所示。
var comparer = StringComparer.OrdinalIgnoreCase;
var dict = new Dictionary<string, int>(comparer);
dict["Test"] = 10;
Console.WriteLine(dict["Test"]);
尽管字典中的键必须唯一，但散列码并不需要如此。两个不等的键完全有可能拥有相同的散 列码；这就是散列冲突（hash collision） ① ，尽管这多少会降低字典的效率，但却可以正常工作。 如果键是易变的，并且散列码在插入后发生了改变，字典将会失败。易变的字典键总是一个坏主 意，但如果确实不得不使用，则应确保在插入后不会改变。
散列表的实现细节是没有规定的，可能会随时改变，但一个重要的方面可能会引起混淆：尽 管 Dictionary<TKey, TValue> 有时可能会按顺序排列，但无法保证总是这样。如果向字典添加 了若干项然后迭代，你会发现项的顺序与插入时相同，但请不要信以为真。有点不幸的是，刻意 添加条目以维持排序的实现可能会很怪异，而碰巧自然扰乱了排序的实现则可能带来更少的混淆。
与 List<T> 一样， Dictionary<TKey, TValue> 将条目保存在数组中，并在必要的时候进 行扩充，且扩充的平摊复杂度为O(1)。如果散列合理，通过键访问的复杂度也为O(1)；而如果所 有键的散列码都相等，由于要依次检查各个键是否相等，因此最终的复杂度为O(n)。在大多数实 际场合中，这都不是问题。
B.3.2 SortedList<TKey, TValue> 和 SortedDictionary<TKey, TValue>
乍一看可能会以为名为 SortedList<,> 的类为列表，但实则不然。这两个类型都是字典， 并且谁也没有实现 IList<T> 。如果取名为 ListBackedSortedDictionary 和 TreeBacked- SortedDictionary 可能更加贴切，但现在改已经来不及了。
这两个 类有很多共 同点：比较 键时都使用 IComparer<TKey> 而 不是 IEquality- Comparer<TKey> ，并且键是根据比较器排好序的。在查找值时，它们的性能均为O(log n)，并 且都能执行二进制搜索。但它们的内部数据结构却迥然不同： SortedList<,> 维护一个排序的 条 目 数 组 ， 而 SortedDictionary<,> 则 使 用 的 是 红 黑 树 结 构 （ 参 见 维 基 百 科 条 目 http://mng.bz/K1S4）。这导致了插入和移除时间以及内存效率上的显著差异。如果要创建一个排 序的字典， SortedList<,> 将被有效地填充，想象一下保持 List<T> 排序的步骤，你会发现向 列表末尾添加单项是廉价的（若忽略数组扩充的话将为O(1)），而随机添加项则是昂贵的，因为 涉及复制已有项（最糟糕的情况是O(n)）。向 SortedDictionary<,> 中的平衡树添加项总是相 当廉价（复杂度为O(log n)），但在堆上会为每个条目分配一个树节点，这将使开销和内存碎片比 使用 SortedList<,> 键值条目的数组要更多。
这两种集合都使用单独的集合公开键和值，并且这两种情况下返回的集合都是活动的，因为 它们将随着基础字典的改变而改变。但 SortedList<,> 公开的集合实现了 IList<T> ，因此可以 使用排序的键索引有效地访问条目。
我不想因为谈论了这么多关于复杂度的内容而给你造成太大困扰。如果不是海量数据，则可 不必担心所使用的实现。如果字典的条目数可能会很大，你应该仔细分析这两种集合的性能特点， 然后决定使用哪一个。
B.3.3 ReadOnlyDictionary<TKey, TValue>
熟悉了B.2.5节中介绍的 withReadOnlyCollection<T> 后， ReadOnlyDictionary<TKey, TValue> 应该也不会让你感到特别意外。 ReadOnlyDictionary<TKey, TValue> 也只是一个 围绕已有集合（本例中指 IDictionary<TKey, TValue> ）的包装器而已，可隐藏显式接口实 现后所有发生变化的操作，并且在调用时抛出 NotSupportedException 。
与只读列表相同， ReadOnlyDictionary<TKey, TValue> 的确只是一个包装器；如果基 础集合（传入构造函数的集合）发生变化，则这些修改内容可通过包装器显现出来。
原文地址：https://www.cnblogs.com/kikyoqiang/p/10187350.html