Map 扩容过程描述错误

[mcrwayfun]

原文

搬迁的目的就是将老的 buckets 搬迁到新的 buckets。而通过前面的说明我们知道，应对条件 1，新的 buckets 数量是之前的一倍，应对条件 2，新的 buckets 数量和之前相等。

对于条件 1，从老的 buckets 搬迁到新的 buckets，由于 bucktes 数量不变，因此可以按序号来搬，比如原来在 0 号 bucktes，到新的地方后，仍然放在 0 号 buckets。

对于条件 2，就没这么简单了。要重新计算 key 的哈希，才能决定它到底落在哪个 bucket。例如，原来 B = 5，计算出 key 的哈希后，只用看它的低 5 位，就能决定它落在哪个 bucket。扩容后，B 变成了 6，因此需要多看一位，它的低 6 位决定 key 落在哪个 bucket。这称为 rehash。

条件1是buckets数量翻倍，条件2是sizeSameGrow，下面描述错误，与上下文不一致。

[mikeqoo1]

應該改成這樣 @mcrwayfun

搬迁的目的就是将老的 buckets 搬迁到新的 buckets。而通过前面的说明我们知道，应对条件 1[if !h.sameSizeGrow()]，新的 buckets 数量和之前相等，应对条件 2，新的 buckets 数量是之前的一倍。

[canaan-wang]

对于条件 2，其实元素没那么多，但是 overflow bucket 数特别多，说明很多 bucket 都没装满。解决办法就是开辟一个新 bucket 空间，将老 bucket 中的元素移动到新 bucket，使得同一个 bucket 中的 key 排列地更紧密。这样，原来，在 overflow bucket 中的 key 可以移动到 bucket 中来。结果是节省空间，提高 bucket 利用率，map 的查找和插入效率自然就会提升。

关于map触发扩容这里的原因，我有些疑问。原文说在最初向map中写入数据，如果数据过于分散会导致空间利用率不高而开始重组。但是我感觉代码这里更像是为了应对一个kv极多的map，在删除大量kv后而产生大量较空的bucket而写的。感觉初始时候就遇到缩容重组的概率也太低了。那点内存也不太值得进行重组，也许后面还要继续增加呢。

[qcrao]

原文

搬迁的目的就是将老的 buckets 搬迁到新的 buckets。而通过前面的说明我们知道，应对条件 1，新的 buckets 数量是之前的一倍，应对条件 2，新的 buckets 数量和之前相等。

对于条件 1，从老的 buckets 搬迁到新的 buckets，由于 bucktes 数量不变，因此可以按序号来搬，比如原来在 0 号 bucktes，到新的地方后，仍然放在 0 号 buckets。

对于条件 2，就没这么简单了。要重新计算 key 的哈希，才能决定它到底落在哪个 bucket。例如，原来 B = 5，计算出 key 的哈希后，只用看它的低 5 位，就能决定它落在哪个 bucket。扩容后，B 变成了 6，因此需要多看一位，它的低 6 位决定 key 落在哪个 bucket。这称为 rehash。

条件1是buckets数量翻倍，条件2是sizeSameGrow，下面描述错误，与上下文不一致。

笔误。你可以提个 pr 成为 contributor^_^