Java 为什么hashmap会根据总大小而不是填充的存储桶调整大小

我心里有一个疑问：：

当前java中的HashMap在

totalSize（插入的元素数）>arrayLength*loadFactor

因此，它使表加倍并重新灰化所有键值

但假设Key类中的hashcode硬编码为1，那么每次元素都会以链表方式插入索引1。但是我们的

bucketaray

将根据总大小调整不必要的大小。因此，它将继续增加

bucketaray

大小，而元素将与此类hashcode实现放在同一个bucket中

我有一个问题，我们是否应该检查填充桶的大小，而不是总大小

---

我知道这样的哈希代码会影响性能。我问这是一个合乎逻辑的问题。

HashMap

有一些代码试图改进糟糕的

hashCode（）

实现，但它无法改进总是返回相同值的糟糕的

hashCode（）

实现

无论是否调整

HashMap

的大小，这样的

hashCode（）

都会带来糟糕的性能。因此，

HashMap

的这种糟糕用法并不能证明像您建议的那样添加特殊逻辑是合理的

---

密钥的

hashCode（）

实现的假设是，它将在

HashMap

容器中尽可能均匀地分配密钥。因此，bucket中的平均条目数（即条目数除以bucket数）应该能够很好地估计何时应该调整

HashMap

的大小，并且不需要检查单个bucket的大小

如果

hashcode

总是返回相同的值

这是一个糟糕的实现，没有逻辑支持不应该做的事情

hashcode

可能不是常量函数，HashMap无法知道哈希函数是否为常量类型，因此明智的做法是调整

HashMap

的大小，因为如果突然

hashcode

变为非常量函数，则调整大小可能会导致更好的值分布

---

想象一个大小为12的哈希映射，其中包含9个项目。假设巧合的是，

#hashCode（）

只返回3的倍数-它仍然是一个有缺陷的哈希代码，但它不是一个人为的边缘情况，例如常量哈希代码为1。这意味着在这种情况下，只有四个桶（0、3、6和9）将填充1或2个元素

使用您的方法，这个hashmap将永远不会调整大小，冲突列表将永远增长，性能将受到影响。但是，如果您根据总大小调整它的大小，使用75%的负载因子（即添加第十个元素时的负载因子），您将得到一个包含24个bucket的贴图，其中8个将被填充

基于总大小的增长将冲突列表保持在一个合理的大小，而实际的不完美哈希函数是合理的，因为期望每个哈希函数至少都尽可能地分发哈希代码是合理的。这意味着增加散列映射将导致比以前更满的存储桶，即使仍然存在集群和空存储桶

---

基本上，您的建议是在边缘情况下优化内存使用，而在更可能的情况下不优化访问性能（即映射的主要目的）。

FYI，这是。与跟踪使用的存储桶相比，使用total元素可以简化实现。很可能HashMap开发人员没有将他们的设计建立在某个人不需要使用HashMap的基础上，或者做了一些非常愚蠢的事情，比如对每个元素使用相同的键，或者提供了一个糟糕的hashCode（）function@nos“或者提供一个错误的hashCode（）函数”实际上，我们采取了一些措施来降低糟糕的哈希函数对性能的影响。我知道这样的哈希代码会影响性能。我问这是一个合乎逻辑的问题。@RajatGoyal

HashMap

应该以某种方式使用。建议使用一个不好的使用示例作为更改现有实现的理由（在正确使用

HashMap

时效果很好）对我来说似乎不符合逻辑。@Eran同意你的看法。