在浏览Java {
"zipcode": "97358",
"polygon": [
{
"lat": 44.730418,
"lng": -122.544798
},
{
"lat": 44.763411,
"lng": -122.685015
},
{
"lat": 44.831045,
"lng": -122.616831
},
{
"lat": 44.863487,
"lng": -122.401282
},
{
"lat": 44.80795,
"lng": -122.40953
},
{
"lat": 44.730418,
"lng": -122.544798
}
]
}
的源代码时，我们可以看到密钥的第一个桶是用以下方法确定的：
HashMap根据我的理解，如果初始大小是 static int indexFor(int h, int length) { //h = hash of key
return h & (length-1); //length = capacity of array at
} // current time
（长度-1 = 15 = 1111），并且生成的密钥16的哈希值是k1（1 10100111 01011010），然后
108378方法将返回indexFor()（1010）。
现在，在添加一些内容后，容量已更改为10。现在，如果我想搜索密钥32（使用散列108378），它将再次使用相同的k1方法检查存储桶。现在，indexFor()代码段将返回h & (length-1)。 （108378＆amp; 31）。
我的问题是，如果调整表的大小，这个get方法将如何找到正确的存储区？
答案 0 :(得分：1)
如果调整表的大小，则length参数将更改，indexFor方法将返回不同的值。当表调整大小时，必须将当前表中的值移动到新表中，因此将为每个值计算新索引。
答案 1 :(得分：1)
当达到最大加载因子阈值时，会发生名为Rehashing的过程，并且所有元素都会移动到新表中。
当哈希表中的条目数超过产品时 哈希表是负载因子和当前容量 重新构建（即重建内部数据结构） 哈希表的桶数大约是桶的两倍。
地图中预期的条目数及其加载因子 在设定初始容量时应该考虑到这一点，所以 以尽量减少重新运作的次数。
答案 2 :(得分：0)
您看到的BehaviorSubject不是length报告的值。它是一个内部长度，表示哈希表的大小。在密集填充的哈希映射中，此长度可能小于map.size()，或者在稀疏填充的哈希映射中，该长度可能大于size()。它越小，找到的密钥越多，size()的评估就越相同，这意味着更多的密钥将被分组到桶中。
在一些（希望尽可能少）的时间点，地图决定h & (length-1)太小，造成太多碰撞，（每个桶中的键太多），所以它重新组织映射，将哈希表重新分配到更大的大小，重新计算所有哈希值，并在桶中重新分配密钥，以使length对所有哈希值仍然正确。