HashMap 这套八股，不得背个十来遍？

HashMap、HashTable、ConcurrentHashMap 这一套感觉今年面试都不怎么问了，场景题越来越多，求职的门槛越来越高，这种常见的面试题问出来大概率就是要送波分了。

1. 讲讲 HashMap 的底层结构和原理

HashMap 就是以 Key-Value 的方式进行数据存储的一种数据结构嘛，在我们平常开发中非常常用，它在 JDK 1.7 和 JDK 1.8 中底层数据结构是有些不一样的。总体来说，JDK 1.7 中 HashMap 的底层数据结构是数组 + 链表，使用 Entry 类存储 Key 和 Value；JDK 1.8 中 HashMap 的底层数据结构是数组 + 链表/红黑树，使用 Node 类存储 Key 和 Value。当然，这里的 Entry 和 Node 并没有什么不同，我们来看看 Node 类的源码：

// HashMap 1.8 内部使用这个数组存储所有键值对transient Node<K,V>[] table;

每一个节点都会保存自身的 hash、key 和 value、以及下个节点。咱先画个简略的 HashMap 示意图：

因为 HashMap 本身所有的位置都为 null 嘛，所以在插入元素的时候即 put 操作时，会根据 key 的 hash 去计算出一个 index 值，也就是这个元素将要插入的位置。

举个例子：比如 put(“小牛肉”，20)，我插入了一个 key 为 “小牛肉” value 为 20 的元素，这个时候我们会通过哈希函数计算出这个元素将要插入的位置，假设计算出来的结果是 2：

我们刚刚还提到了链表，Node 类里面也确实定义了一个 next 属性，那么为啥需要链表呢？

首先，数组的长度是有限的对吧，在有限的数组上使用哈希，那么哈希冲突是不可避免的，很有可能两个元素计算得出的 index 是相同的，那么如何解决哈希冲突呢？拉链法。也就是把 hash 后值相同的元素放在同一条链表上。比如说：

当然这里还有一个问题，那就是当 Hash 冲突严重时，在数组上形成的链表会变的越来越长，由于链表不支持索引，要想在链表中找一个元素就需要遍历一遍链表，那显然效率是比较低的。为此，JDK 1.8 引入了红黑树，当链表的长度大于 8 的时候就会转换为红黑树，不过，在转换之前，会先去查看 table 数组的长度是否大于 64，如果数组的长度小于 64，那么 HashMap 会优先选择对数组进行扩容 resize，而不是把链表转换成红黑树。

看下 JDK 1.8 下 HashMap 的完整示意图，应该画的比较清晰了：

2. 新的 Entry/Node 节点在插入链表的时候，是怎么插入的？

在 JDK 1.7 的时候，采用的是头插法，看下图：

不过 JDK 1.8 改成了尾插法，这是为什么呢？因为 JDK 1.7 中采用的头插法在多线程环境下可能会造成循环链表问题。

首先，我们之前提到，数组容量是有限的，如果数据多次插入并到达一定的数量就会进行数组扩容，也就是resize 方法。什么时候会进行 resize 呢？与两个因素有关：

1）Capacity：HashMap 当前最大容量/长度

2）LoadFactor：负载因子，默认值0.75f

如果当前存入的数据数量大于 Capacity * LoadFactor 的时候，就会进行数组扩容 resize。就比如当前的 HashMap 的最大容量大小为 100，当你存进第 76 个的时候，判断发现需要进行 resize了，那就进行扩容。当然，HashMap 的扩容不是简单的扩大点容量这么简单的。

扩容 resize 分为两步：

1）扩容：创建一个新的 Entry/Node 空数组，长度是原数组的 2 倍

2）ReHash：遍历原 Entry/Node 数组，把所有的 Entry/Node 节点重新 Hash 到新数组

为什么要 ReHash 呢？直接复制到新数组不行吗？

显然是不行的，因为数组的长度改变以后，Hash 的规则也随之改变。index 的计算公式是这样的：

index = HashCode(key) & (Length - 1)
比如说数组原来的长度（Length）是 4，Hash 出来的值是 2 ，然后数组长度翻倍了变成 16，显然 Hash 出来的值也就会变了。画个图解释下：