HashMap底层实现原理及面试问题

参考视屏链接：https://www.bilibili.com/video/BV1kJ411C7hC?t=5804

HashMap是基于Map接口的实现，采用key-value形式存储，在项目开发中，这种容器使用是非常广泛的，本文主要就是对HashMap的底层原理做个剖析，首先对比HashMap与HashTable的区别，然后以jdk1.7为例介绍HashMap的实现，再介绍jdk1.8做的改动。

对比：HashTable、HashMap

Hashtable 是早期Java类库提供的一个哈希表实现，本身是同步的，不支持 null 键和值，由于同步导致的性能开销，所以已经很少被推荐使用。
HashMap与 HashTable主要区别在于 HashMap 不是同步的，支持 null 键和值等。通常情况下，HashMap 进行 put 或者 get 操作，可以达到常数时间的性能，所以它是绝大部分利用键值对存取场景的首选
储存结构
既然HashMap是一种容器，首先需要了解他的储存结构，在HashMap中我们看到有如下属性

原来HashMap底层是用数组作为存储结构，那么Entry又是什么呢？

Entry的作用是把key、value封装成一个对象，next属性指向下一个Entry，由此我们可以得出HashMap的存储结构是数组+链表的结构，就像这样

构造函数
 
HashMap默认构造函数调用的是带有容量大小和加载因子两个参数的有参构造函数，默认传入的DEFAULT_INITIAL_CAPACITY为16，DEFAULT_LOAD_FACTOR为0.75，并且将initialCapacity赋值给threshold（阈值）

初始化与插入元素

插入元素之前，如果没有被初始化，则会进行初始化inflateTable，用threshold作为参数（这里是16），然后会把threshold转为大于等于本身的最小2的幂次方的值，因为16本身就是2的幂次方数，所以这里不变（HashMap数组大小必须为2的幂次方数），重新计算threshold（这里是12，加载因子的作用就是计算阈值），然后初始化数组，所以HashMap默认大小是16。

再回过头看put方法，初始化之后，会用一个hash算法计算key的哈希值（哈希算法有很多，可以根据需要自己实现，我们主要是讲原理），然后根据哈希值计算index下标

下标的计算方式用的是 hashValue & (length-1)，由于数组长度length也就是初始化时的capacity，为16。当数组长度为2的幂次方数时，length-1是一个低位全是1的二进制数（15转二进制数为1111），此时&(len-1)位运算与%len取模运算效果是一样的，为了提升性能HashMap使用了&位运算，这也就是长度必须要是2的幂次方的原因。
求得下标之后就可以获取对应位置的链表头，遍历链表，如果有相同就替换，否则添加新元素，addEntry方法调用的是createEntry方法

首先拿到index处的元素，然后基于之前的元素构建新的Entry，我们来看一下Entry的构造方法

构造方法将传入的旧元素作为next，得到的新Entry被放在数组的index处，因此元素的插入方式是在链表的头部。

扩容resize

我们再来看一下addEntry方法，在创建新元素之前，还会进行一次判断，如果元素数量大于阈值并且本次插入发生冲突，那么就会resize扩容，新建数组，大小为原来的两倍，将元素放入新容器

由扩容的机制和先插入元素后size++我们可以得出，当数组大小为默认的16时，元素个数最多为27个。
前12个元素插入同一个数组位置（12+15）
后面15个元素插入其他的数组位置

获取元素
 查找过程与插入过程相似，先用hash算法得到哈希值，再计算下标，然后遍历index处链表，判断是否存在相同key，存在则返回
jdk1.8差异
元素由Entry变为Node
transient Node<K,V>[] table;
其实没什么区别，只是改了个名称

jdk1.8将逻辑都放在一个方法里了，少了封装，减少了代码的可阅读性，基本思路差不多。

插入元素的时候jdk1.7是在链表的头部插入，jdk1.8是在链表的尾部插入元素，当链表的长度超过TREEIFY_THRESHOLD（值为8），并且元素总数超过64时，链表会转变为红黑树形结构，因为链表长度过长会导致查找效率下降，转为树形结构后，性能会有较大的提升。jdk1.8的数据结构为数组+ 红黑树的结构。

扩容时机，jdk1.8中只要元素数量超过了阈值就会扩容。

jdk1.8还有一种扩容时机，发生在转为树形结构时，如果当前数组大小小于MIN_TREEIFY_CAPACITY=64，则不会转为属性结构，而是发生扩容。

HashMap线程不安全
数据不一致主要是由两个方面：

put的时候导致的多线程数据不一致。比如有两个线程A和B，首先A希望插入一个key-value对到HashMap中，首先计算记录所要落到的 hash桶的索引坐标，然后获取到该桶里面的链表头结点，并且遍历到了链表的最后一个元素，此时线程A的时间片用完了，而此时线程B被调度得以执行，和线程A一样执行，只不过线程B成功将记录插到了桶里面，假设线程A插入的记录计算出来的 hash桶索引和线程B要插入的记录计算出来的 hash桶索引是一样的，那么当线程B成功插入之后，线程A再次被调度运行时，它依然持认为当前元素是最后一个元素，以至于它认为它应该这样做，如此一来就覆盖了线程B插入的记录，这样线程B插入的记录就凭空消失了，造成了数据不一致的行为。
resize而引起死循环。这种情况发生在HashMap自动扩容时，当2个线程同时检测到元素个数超过 数组大小 × 负载因子。此时2个线程会在put()方法中调用了resize()，两个线程同时修改一个链表结构会产生一个循环链表（JDK1.7中，会出现resize前后元素顺序倒置的情况）。接下来再想通过get()获取某一个元素，就会出现死循环。