HashMap所有核心底层原理
HashMap基本原理和优缺点
一句话讲， HashMap底层数据结构，JDK1.7数组+单向链表、JDK1.8数组+单向链表+红黑树。
HashMap的3个底层原理
首先你应该知道HashMap的核心方法之一就是put。我们带着如下几个问题来看下图：
-
hash值计算的算法是什么？就是key.hashCode()吗？
-
默认情况下，put第一个元素时候容量大小是多少？扩容阈值又是多少？
-
hash寻址如何进行的？
如上图所示，put方法调用了putVal方法，之后主要脉络是：
-
第一步调用了hash方法计算hash值。
-
第二步计算容量和扩容
-
第三步创建元素
如何计算hash值？
计算hash值的算法就在第一步，如图所示，对key值进行hashCode()后，对hashCode的值进行无符号右移16位和hashCode值进行了异或操作。为什么这么做呢？其实涉及了很多数学知识，简单的说就是尽可能让高16和低16位参与运算，可以减少hash值的冲突（数据结构算法课中可能叫散列碰撞）。
默认容量和扩容阈值是多少？
如上图所示，很明显第二步回调用resize方法，获取到默认容量为16，这个16在源码里是1<<4得到的，1左移4位得到的。之后由于默认扩容因子是0.75，所以两者相乘就是扩容大小阈值16*0.75=12。之后就分配了一个大小为16的Node[]数组，作为Key-Value对存放的数据结构。
最后一问题是，如何进行hash寻址的？
hash寻址其实就在数组中找一个位置的意思。用的算法其实也很简单，就是用数组大小和hash值进行n-1&hash运算，这个操作和对hash取模很类似，只不过这样效率更高而已。hash寻址后，就得到了一个位置，可以把key-value的Node元素放入到之前创建好的Node[]数组中了。
HashMap另外3个底层原理
还是老规矩，看如下图：
-
hash值如果计算的相同该怎么解决冲突？
当hash值计算一致，比如当hash值都是1100时，Key-Value对的Node节点还有一个next指针，会以单链表的形式，将冲突的节点挂在数组同样位置。这就是数据结构中所提到解决hash 的冲突方法之一：单链法。当然还有探测法+rehash法有兴趣的人可以回顾《数据结构和算法》相关书籍。
但是当hash冲突严重的时候，单链法会造成原理链接过长，导致HashMap性能下降，因为链表需要逐个遍历性能很差。所以JDK1.8对hash冲突的算法进行了优化。当链表节点数>=7个的时候，会自动转换为红黑树，自平衡的一种二叉树，有很多特点，比如区分红和黑节点等，具体大家可以看小灰算法图解。红黑树的遍历效率是O(logn)肯定比单链表的O(n)要好很多。
总结一句话就是，hash冲突使用单链表法+红黑树来解决的。
-
HashMap扩容后怎么进行rehash的？
上面的图，核心脉络是四步，源码具体的就不粘出来了。当put一个之后，map的size达到扩容阈值12，就会触发rehash。你可以看到如下具体思路：
-
新的数组容量为原来的2倍，比如16-32
-
新的扩容阈值也是原来的2倍，比如12->24
-
为新数组分配了空间newTab,原数组oldTab不为空，需要进行rehash操作
-
rehash有3种情况，数组位置如果有值，进行rehash。（这一步是rehash核心中的核心）有如下三种情况：
情况1:如果数组位置只有一个值：使用新的容量进行rehash，即e.hash & (newCap - 1)
情况2:如果数组位置有链表，根据 e.hash & oldCap == 0进行判断，结果为0的使用原位置，否则使用index + oldCap位置,放入元素形成新链表。
至于为什么可以分为两个链表，这里说明一下。就是hash寻址算法对一个数组下标的所有节点，扩容后进行重新计算的时候，会发现计算出来的位置要么是在原来的index，要么实在原来的index + oldCap的位置，这是hash寻址的一个特点，所以基于这一个既定的结论，就去判断一下每个节点重新hash寻址之后是原来的位置还是index + oldCap的位置就行了（如何判断，就是源码图的第一个红框框出来的），判断是在原来的位置然后一个新的链表，在index + oldCap的位置也形成一个新的链表，这样计算完之后只要把新的两个链表挂在新的数组的 index 和 index + oldCap就行了（如何挂的，就是源码图的第二个红框框出来的）。这样就避免了对每个节点重新进行hash寻址算法，重新放到hash表中的过程，大大提高了效率，这也就是JDK1.8的HashMap扩容rehash算法优化。
情况3：如果数组位置有红黑树，根据split方法，同样根据 e.hash & oldCap == 0进行树节点个数统计，如果个数<=6，将树的结果恢复为普通Node，否则使用index + oldCap，调整红黑树位置。
其实原理跟链表的差不多，就是链表拆成两个链表，红黑树这个拆成两个红黑树，分别挂到新的数组的位置上，只不过最后加个判断，就是判断这个红黑树是需要变成链表还是继续是红黑树。
所以在JDK1.8的rehash算法优化就是对原来的链表或者红黑树进行拆分成两部分，然后分别挂在原来数组的位置和 数组的位置 + oldCap的位置，这样做就避免了大量的节点进行重新hash寻址算法和重新放到hash表的过程，大大增加了扩容效率。
final void split(HashMap<K,V> map, Node<K,V>[] tab, int index, int bit) { TreeNode<K,V> b = this; // Relink into lo and hi lists, preserving order TreeNode<K,V> loHead = null, loTail = null; TreeNode<K,V> hiHead = null, hiTail = null; int lc = 0, hc = 0; for (TreeNode<K,V> e = b, next; e != null; e = next) { next = (TreeNode<K,V>)e.next; e.next = null; if ((e.hash & bit) == 0) { if ((e.prev = loTail) == null) loHead = e; else loTail.next = e; loTail = e; ++lc; } else { if ((e.prev = hiTail) == null) hiHead = e; else hiTail.next = e; hiTail = e; ++hc; } } if (loHead != null) { if (lc <= UNTREEIFY_THRESHOLD) tab[index] = loHead.untreeify(map); else { tab[index] = loHead; if (hiHead != null) // (else is already treeified) loHead.treeify(tab); } } if (hiHead != null) { if (hc <= UNTREEIFY_THRESHOLD) tab[index + bit] = hiHead.untreeify(map); else { tab[index + bit] = hiHead; if (loHead != null) hiHead.treeify(tab); } } }
你有兴趣的话，可以分别画一下这三种情况的图。这里给大家一个图，假设都出发了以上三种情况结果如下所示：
-
指定大小的HashMap，扩容阈值算法是什么？
最后我们来看下，new HashMap(100)指定容量大小后的原理，如下代码：
public HashMap(int initialCapacity) { this(initialCapacity, DEFAULT_LOAD_FACTOR); } public HashMap(int initialCapacity, float loadFactor) { if (initialCapacity < 0) throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity); if (initialCapacity > MAXIMUM_CAPACITY) initialCapacity = MAXIMUM_CAPACITY; if (loadFactor <= 0 || Float.isNaN(loadFactor)) throw new IllegalArgumentException("Illegal load factor: " + loadFactor); this.loadFactor = loadFactor; this.threshold = tableSizeFor(initialCapacity); }
上面源码核心脉络，3个if主要是校验了一堆，没做什么事情，之后赋值了扩容因子，不传递使用默认值0.75，扩容阈值threshold通过tableSizeFor(initialCapacity);进行计算。注意这里只是计算了扩容阈值，没有初始化数组。代码如下：
static final int tableSizeFor(int cap) { int n = cap - 1; n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16; return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; }
竟然不是大小*扩容因子？
n |= n >>> 1这句话，是在干什么？n |= n >>> 1等价于n = n | n >>>1; 而|表示位运算中的或，n>>>1表示无符号右移1位。遇到这种情况，之前你应该学到了，如果碰见复杂逻辑和算法方法就是画图或者举例子。这里你就可以举个例子：假设现在指定的容量大小是100,n=cap-1=99，那么计算过程应该如下：
n是int类型，java中一般是4个字节，32位。所以99的二进制：0000 0000 0000 0000 0000 0000 0110 0011。
举例：cap=100 n=cap-1 n = n | n >>> 1如下： 0000 0000 0000 0000 0000 0000 0110 0011 十进制 0000 0000 0000 0000 0000 0000 0011 0001 十进制49 0000 0000 0000 0000 0000 0000 0111 0011 十进制115 n = n | n >>> 2如下： 0000 0000 0000 0000 0000 0000 0111 0011 十进制 115 0000 0000 0000 0000 0000 0000 0001 1100 十进制 28 0000 0000 0000 0000 0000 0000 0111 1111 十进制127 n = n | n >>> 4如下： 0000 0000 0000 0000 0000 0000 0111 1111 十进制 127 0000 0000 0000 0000 0000 0000 0001 1111 十进制 31 0000 0000 0000 0000 0000 0000 0111 1111 十进制127 n = n | n >>> 8 0000 0000 0000 0000 0000 0000 0111 1111 十进制 127 0000 0000 0000 0000 0000 0000 0000 0000 十进制 0 0000 0000 0000 0000 0000 0000 0111 1111 十进制127 n = n | n >>> 16 0000 0000 0000 0000 0000 0000 0111 1111 十进制 127 0000 0000 0000 0000 0000 0000 0000 0000 十进制 0 0000 0000 0000 0000 0000 0000 0111 1111 十进制127
最后n+1=128，方法返回，赋值给threshold=128。再次注意这里只是计算了扩容阈值，没有初始化数组。
为什么这么做呢？一句话，为了提高hash寻址和扩容计算的的效率。
因为无论扩容计算还是寻址计算，都是二进制的位运算，效率很快。另外之前你还记得取余(%)操作中如果除数是2的幂次方则等同于与其除数减一的与(&)操作。即 hash%size = hash & (size-1)。这个前提条件是除数是2的幂次方。
你可以再回顾下resize代码，看看指定了map容量，第一次put会发生什么。会将扩容阈值threshold，这样在第一次put的时候就会调用newCap = oldThr;使得创建一个容量为threshold的数组，之后从而会计算新的扩容阈值newThr为newCap*0.75=128*0.75=96。也就是说map到了96个元素就会进行扩容。
JDK1.7 HashMap死循环问题？
在JDK1.8引入红黑树之前,JDK1.7由于只有单向链表解决hash冲突，除了遍历性能可能会慢，还有几率在多线程同时扩容，rehash的时候发生死循环问题，造成cpu100%。虽然把hashMap用到多线程很不合理，但是有时候面试总会考这么***钻的问题。面试圈有时候还是比较复杂的。。。
造成死循环的这个问题，过程比较复杂，这一节可能讲不完了。这里给大家抛砖引玉下。
造成死循环的核心脉络有如下几步：
1、首先原位置得有hash冲突，比如链表元素有4个。
2、之后需要有2个线程，同时添加元素，均满足扩容条件，进行扩容
3、一个线程刚刚进行了rehash操作，之后另一个线程开始rehash操作，会形成环向链表。
4、get操作时候发生无限死循环，cpu可能达到100%
如下图：
