关于HashMap请移动详解文章：
链接: HashMap源代码研究-源代码一行注释
扩容将伴随着重新扩容hash分配，并将遍历hash表中的所有元素都非常耗时。在编写程序时，尽量避免resize。
HashMap扩容时使用rehash方法很巧妙，因为每次扩容都是翻倍，和原来计算的一样 (n-1)&hash相比之下，结果只是多了一个bit所以节点要么在原来的位置，要么分配到"原位置 旧容量"这个位置。 如何理解？例如，当我们从16扩展到32时，具体变化如下： 
因此，元素正在重新计算hash之后，因为n变成了两倍，所以n-1的标记范围在高位多1bit因此，新的index就会发生这样的变化： 注：5是假设计算的原始索引。这验证了上述描述：扩展后，节点要么在原位置，要么分配到"原位置 旧容量"这个位置。
因此，我们正在扩张HashMap的时候，不需要重新计算hash，只需原来的hash新增值bit是1还是0，如果是0，索引不会改变，如果是1，索引会变成原索引 oldCap(原位置 旧容量)。下图为16扩展为32resize示意图： 正因为如此巧妙rehash方法省去了重新计算hash与此同时，由于新的1bit是0还是1可以认为是随机的，在resize保证过程rehash之后，每个桶上的节点数必须小于等于原桶上的节点数，以确保rehash之后就不会出现更严重的情况了。hash冲突，将之前冲突的节点均匀分散到新桶中。