ConcurrentDictionary：适当的小初始容量

Question

我一直缺乏为ConcurrentDictionary<TKey, TValue> 选择适当初始容量的指导。

我的一般用例是您真正想要执行以下操作但不能执行的情况：

public static class StaticCache<T>
{
    public static readonly Action CompiledExpression = ...;
}

这种基于泛型的方法避免了字典查找，但只有当我们在编译时总是知道所需的类型时才能使用。如果我们在运行时只知道Type，我们就不能再使用这种方法了。下一个竞争者是ConcurrentDictionary<TKey, TValue>。

documentation 声明：

默认容量（DEFAULT_CAPACITY），代表初始桶数，是在构建大字典时，在非常小的字典大小和调整大小的数量之间进行权衡。此外，容量不应被小素数整除。默认容量为 31。

我的预期元素数量往往相对较少。有时小到 3 或 5 个，有时可能只有 15 个。因此：

• 应用程序生命周期内的插入次数非常最少，保证 [写入] 并发级别为 1，从而优化紧凑性和读取操作。
• 最好使用尽可能小的内存占用，以优化缓存行为。

由于默认初始容量为 31，我们可以通过使用较小的初始容量来潜在地减少对缓存的影响（以及增加字典保留在缓存中的可能性）。

这引发了以下问题：

1. 容量实际上是什么意思？

   • (A) 字典不需要增长来容纳这么多元素？
   • (B) A 的固定百分比，取决于字典的最大“丰满度”，例如75%？
   • (C) A 或 B 的近似值，取决于实际内容的哈希码如何分布它们？

2. 什么构成和不构成“小素数”？显然，31 没有。 11吗？ 17吗？ 23 吗？

3. 如果我们碰巧想要一个接近小素数的容量，我们可以选择什么容量呢？我们是简单地选择最接近的非素数，还是素数更适合容量，我们真的应该选择更大的素数吗？

Answer 1

在reference source 中为ConcurrentDictionary<TKey, TValue> 你可以看到：

Node[] buckets = new Node[capacity];

所以，容量就是哈希表的有效大小。不考虑“丰满度”。这个数字的唯一预处理是：

if (capacity < concurrencyLevel)
{
    capacity = concurrencyLevel;
}

其中concurrencyLevel 由您通过构造函数参数定义，或者是定义为PlatformHelper.ProcessorCount 的默认并发级别。

Dictionary<TKey,TValue> 对容量的处理方式不同。这里初始化为

private void Initialize(int capacity) {
    int size = HashHelpers.GetPrime(capacity);
    buckets = new int[size];
    ...
}

和HashHelpers.GetPrime 获得大于或等于指定容量的最小素数。高达7199369 的素数取自预先计算的数组。较大的计算是“艰难的方式”。有趣的是，考虑的最小素数是3。

很遗憾，HashHelpers 是一个内部类。

如果我理解正确的话，两种实现都会根据冲突的数量而不是基于特定的填充因子（“填充度”）来调整哈希表的大小。

如果你愿意

• 优化速度：取一个初始容量，它比预期的最大字典大小大 30% 左右。这样可以避免调整大小。
• 优化内存占用：取一个比最小预期大小大约 30% 的素数。
• 速度和内存占用之间的平衡：从上面取一个介于两者之间的数字。但无论如何，取一个素数。