HashMap(二)扩容

想要了解HashMap的扩容机制你要有这两个问题
1、什么时候才需要扩容
2、HashMap的扩容是什么

1、什么时候才需要扩容
当HashMap中的元素个数超过数组大小（数组长度）* loadFactor(负载因子)时，就会进行数组扩容，loadFactor的默认值(DEFAULT_FACTOR)是0.75，这是一个折中的取值。也就是说，默认情况下，数组大小为16，那么当HashMap中的元素个数超过160.75=12（这个值就是阈值或者边界值threshold值）的时候，就把数组的大小扩展为216，即扩大一倍，然后重新计算每个元素在数组中的位置，而这是一个非常耗性能的操作，所以如果我们已经预知HashMap中元素的个数，那么预知元素的个数能够有效的提高HashMap的性能。

补充：
当HashMap中的其中一个链表的对象个数如果达到了8个，此时如果数组长度没有达到64，那么HashMap会先扩容解决，如果已经达到了64，那么这个链表会变成红黑树，节点类型由Node变成TreeNode类型。当然，如果映射关系被移除后，下次执行resize方法时判断树的节点个数低于6，也会再把树转换为链表。

2、HashMap的扩容是什么？
进行扩容，会伴随着一次重新hash分配，并且会遍历hash表中所有的元素，是非常耗时的。在编写程序中，要尽量避免resize.
HashMap在进行扩容时，使用的rehash方式非常巧妙，因为每次扩容都是翻倍，与原来计算的(n-1)&hash的结果相比，只是多了一个bit位，所以结点要么就在原来的位置，要么就被分配到"原位置+旧容量"这个位置。
例如我们从16扩展为32时，具体的变化如下所示：

因此元素在重新计算hash之后，因为n变为2倍，那么n-1的标记范围在高位多1bit(红色)，因此新的index就会发生这样的变化。

说明
5是假设计算出来的原来的索引。这样就验证了上述所描述的：扩容之后所以结点要么就在原来的位置，要么就被分配到“原位置+旧容量”这个位置。
因此，我们在扩容HashMap的时候，不需要重新计算hash,只需要看看原来的hash值新增的那个bit是1还是0就可以了，是0的话索引没变，是1的话索引变成“原位置+旧容量”。可以看看下图为16扩充为32的resize示意图：

正是因为这样巧妙的rehash方式，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，在resize的过程中保证了rehash之后每个桶上的结点数一定小于等于原来桶上的结点数，保证了rehash之后不会出现更严重的hash冲突，均匀的把之前的冲突结点分散到新的桶中了。