为什么需要扩展？
为了节省创建的对象的内存消耗，HashMap最初仅在缺省情况下分配。
saticfinalintdefault _ initial _ capacity=14； 也就是说，默认数组大小为16个，但在HashMap源代码中，HashMap的扩展方法如下： 也就是说，如果存储在HashMap中的元素数大于threshold (容量*加载因子，通常是原始大小的两倍)，即%2=0的neshold。需要与2的幂相关我们知道计算机是二进制的，移位也只进行*2或/2。 因此，扩展大小必须满足此标准。 否则，会发生不必要的浪费和错误。
判断需要扩张的时期
我知道在什么场合会发生扩张。 让我们来看看扩展是如何实现的。
扩展方法
首先，判断本来容量是否已经是staticfinalintmaximum _ capacity=130； 否则，请重新创建新的Entry数组，将数组长度更改为newCapacity，然后调用transfer方法，将新的table和threshold指定给当前hashMap对象。 这里最重要的方法是传输器。 这是因为entransfer根据newCapacity重新计算此方法，方法如下：
rehash重新计算条目的散列位置
计算过程相对简单，类似于重新创建新的hashMap。 根据entry的key重新计算散列值，根据新数组的长度计算旧entry应该位于新数组中的位置，如果存在冲突，则链接entry。 该方法的一个有趣之处在于，是否刷新是可选的，但选择的方法取决于散列因子。 在这里暂时不讨论。 )执行这些东西后，hashMap扩展结束。
可见扩展成本并不低。 这是因为必须遍历时间复杂度为0(n )的数组，并对每个enrty进行散列计算。 因为要添加到新数组中，所以最好的方法是合理使用HashMap的构建方法来创建大小合适的HashMap，最大限度地减少扩展容量，而不浪费内存。 这个根据业务决定。
此外，还提出了为什么hashMap使用什么样的复杂结构，以及要素扩展到未填满数组的程度的问题。 这其实和HashMap哈希表的目的有关。 因为如果使用hashCode查找包含条目的HashMap数组的位置，然后遍历位于该数组位置的bucket，则查询的时间复杂度为o(1)。 这样和一般意义上的排列相比，可以看出质量飞跃性地高。 这也是HashMap花了很多时间做这些的理由。 关于从那里导出的冲突处理这样的问题将在后面叙述。