（部分）以下答案来自“ 升级Python技能”：检查字典。有关Python哈希表的更多信息，请参见The
Hood的Python Hash Tables：
当我们创建字典时，它的初始大小是多少？
- 从源代码中可以看出：
#define PyDict_MINSIZE 8
假设我们使用许多键值对进行更新，我想我们需要消除散列表。我想我们需要重新计算哈希函数，以适应新的更大哈希表的大小，同时保持与先前哈希表的某种逻辑关系。
每当我们添加键时，CPython都会检查哈希表的大小。如果表已满三分之二，它将调整哈希表的大小
GROWTH_RATE（当前设置为3），并插入所有元素：
#define GROWTH_RATE(d) ((d)->ma_used*3)
这
USABLE_FRACTION是我上面提到的三分之二：
#define USABLE_FRACTION(n) (((n) << 1)/3)
此外，索引计算为：
i = (size_t)hash & mask;
面具在哪儿
HASH_TABLE_SIZE-1。
处理哈希冲突的方法如下：
perturb >>= PERTURB_SHIFT;i = (i*5 + perturb + 1) & mask;
在源代码中说明：
The first half of collision resolution is to visit table indices via this recurrence: j = ((5*j) + 1) mod 2**i For any initial j in range(2**i), repeating that 2**i times generates each int in range(2**i) exactly once (see any text on random-number generation for proof). By itself, this doesn't help much: like linear probing (setting j += 1, or j -= 1, on each loop trip), it scans the table entries in a fixed order. This would be bad, except that's not the only thing we do, and it's actually *good* in the common cases where hash keys are consecutive. In an example that's really too small to make this entirely clear, for a table of size 2**3 the order of indices is: 0 -> 1 -> 6 -> 7 -> 4 -> 5 -> 2 -> 3 -> 0 [and here it's repeating] If two things come in at index 5, the first place we look after is index 2, not 6, so if another comes in at index 6 the collision at 5 didn't hurt it. Linear probing is deadly in this case because there the fixed probe order is the *same* as the order consecutive keys are likely to arrive. But it's extremely unlikely hash pres will follow a 5*j+1 recurrence by accident, and certain that consecutive hash pres do not. The other half of the strategy is to get the other bits of the hash pre into play. This is done by initializing a (unsigned) vrbl "perturb" to the full hash pre, and changing the recurrence to: perturb >>= PERTURB_SHIFT; j = (5*j) + 1 + perturb; use j % 2**i as the next table index; Now the probe sequence depends (eventually) on every bit in the hash pre, and the pseudo-scrambling property of recurring on 5*j+1 is more valuable, because it quickly magnifies small differences in the bits that didn't affect the initial index. Note that because perturb is unsigned, if the recurrence is executed often enough perturb eventually becomes and remains 0. At that point (very rarely reached) the recurrence is on (just) 5*j+1 again, and that's certain to find an empty slot eventually (since it generates every int in range(2**i), and we make sure there's always at least one empty slot).
