在Java基础中，集合类是很关键的一块知识点，也是日常开发的时候经常会用到的。比如List、Map这些在代码中也是很常见的。

个人认为，关于HashMap的实现，JDK的工程师其实是做了很多优化的，要说所有的JDK源码中，哪个类埋的彩蛋最多，那我想HashMap至少可以排前五。

也正是因为如此，很多细节都容易被忽视，今天我们就来关注其中一个问题，那就是：

为什么HashMap的负载因子设置成0.75，而不是1也不是0.5？这背后到底有什么考虑？

大家千万不要小看这个问题，因为负载因子是HashMap中很重要的一个概念，也是高端面试的一个常考点。

另外，这个值得设置，有些人会用错的，比如前几天我的《阿里巴巴Java开发手册建议创建HashMap时设置初始化容量，但是多少合适呢？》这篇文章中，就有读者这样回复：

既然有人会尝试着去修改负载因子，那么到底改成1是不是合适呢？为什么HashMap不使用1作为负载因子的默认值呢？

什么是loadFactory

首先我们来介绍下什么是负载因子（loadFactory），如果读者对这部分已经有了解，那么可以直接跨过这一段。

我们知道，第一次创建HashMap的时候，就会指定其容量（如果未显示制定，默认是16，详见 为啥HashMap的默认容量是16？ ），那随着我们不断的向HashMap中put元素的时候，就有可能会超过其容量，那么就需要有一个扩容机制。

所谓扩容，就是扩大HashMap的容量:

void addEntry(int hash, K key, V value, int bucketIndex) {  
    if ((size >= threshold) && (null != table[bucketIndex])) {  
        resize(2 * table.length);  
        hash = (null != key) ? hash(key) : 0;
        bucketIndex = indexFor(hash, table.length);        }  
    createEntry(hash, key, value, bucketIndex);  
}  
复制代码

从代码中我们可以看到，在向HashMap中添加元素过程中，如果 元素个数（size）超过临界值（threshold） 的时候，就会进行自动扩容（resize），并且，在扩容之后，还需要对HashMap中原有元素进行rehash，即将原来通中的元素重新分配到新的桶中。

在HashMap中，临界值（threshold） = 负载因子（loadFactor） * 容量（capacity）。

loadFactor是装载因子，表示HashMap满的程度，默认值为0.75f，也就是说默认情况下，当HashMap中元素个数达到了容量的3/4的时候就会进行自动扩容。（相见 HashMap中傻傻分不清楚的那些概念 ）

为什么要扩容

还记得前面我们说过，HashMap在扩容到过程中不仅要对其容量进行扩充，还需要进行rehash！所以，这个过程其实是很耗时的，并且Map中元素越多越耗时。

rehash的过程相当于对其中所有的元素重新做一遍hash，重新计算要分配到那个桶中。

那么，有没有人想过一个问题，既然这么麻烦，为啥要扩容？HashMap不是一个数组链表吗？不扩容的话，也是可以无限存储的呀。为啥要扩容？

这其实和哈希碰撞有关。

哈希碰撞

我们知道，HashMap其实是底层基于哈希函数实现的，但是哈希函数都有如下一个基本特性：根据同一哈希函数计算出的散列值如果不同，那么输入值肯定也不同。但是，根据同一散列函数计算出的散列值如果相同，输入值不一定相同。

两个不同的输入值，根据同一散列函数计算出的散列值相同的现象叫做碰撞。

衡量一个哈希函数的好坏的重要指标就是发生碰撞的概率以及发生碰撞的解决方案。

而为了解决哈希碰撞，有很多办法，其中比较常见的就是链地址法，这也是HashMap采用的方法。详见 全网把Map中的hash()分析的最透彻的文章，别无二家。

HashMap将数组和链表组合在一起，发挥了两者的优势，我们可以将其理解为链表的数组。

HashMap基于链表的数组的数据结构实现的

我们在向HashMap中put元素的时候，就需要先定外到是数组中的哪条链表，然后把这个元素挂在这个链表的后面。

当我们从HashMap中get元素的时候，也是需要定位到是数组中的哪条链表，然后再逐一遍历链表中的元素，直到查找到需要的元素为止。

可见，HashMap通过链表的数组这种结构，解决了hash冲突的问题。

但是，如果一个HashMap中冲突太高，那么数组的链表就会退化为链表。这时候查询速度会大大降低。