我在翻Java的HashMap源码的时候看到下面的
//The default initial capacity - MUST be a power of two.
static final int DEFAULT_INITIAL_CAPACITY = 16;
我的问题是为什么首先存在这个要求？我还看到允许创建具有自定义容量的 HashMap 的构造函数将其转换为 2 的幂：
int capacity = 1;
while (capacity < initialCapacity)
capacity <<= 1;
为什么容量总是必须是二的幂？
另外，当执行自动重新散列时，究竟会发生什么？哈希函数也改变了吗？
【问题讨论】：
标签： java hashmap hashtable hash
映射必须计算出用于任何给定键的内部表索引，将任何int 值（可能为负）映射到[0, table.length) 范围内的值。当 table.length 是 2 的幂时，可以真的廉价地完成 - 并且在 indexFor 中：
static int indexFor(int h, int length) {
return h & (length-1);
}
使用不同的表长度，您需要计算余数并确保它是非负数。这绝对是一个微优化，但可能是有效的:)
另外，当执行自动重新散列时，究竟会发生什么？哈希函数也改变了吗？
我不太清楚你的意思。使用了相同的哈希码（因为它们只是通过在每个键上调用 hashCode 来计算的），但是由于表长度的变化，它们在表中的分布不同。例如，当表长度为16时，5和21的哈希码最终都存储在表条目5中。当表长度增加到32时，它们将在不同的条目中。
【讨论】：
defaultWriteObject的调用中将其写出。
key.hashCode()。散列是在key.hashCode() 之上应用的补充散列函数。这样做是为了防止糟糕的 hashCode 实现可能导致超出预期的冲突。
理想的情况实际上是使用素数大小作为HashMap 的后备数组。这样，您的密钥将更自然地分布在整个阵列中。但是，这适用于 mod 划分，并且随着 Java 的每个版本，该操作变得越来越慢。
从某种意义上说，2 的力量是你能想象到的最差的表大小，因为糟糕的哈希码实现更有可能在数组中产生键冲突。
因此，您会在 Java 的 HashMap 实现中找到另一个非常重要的方法，即 hash(int)，它可以弥补糟糕的哈希码。
【讨论】：