一：HashMap的整体实现
HashMap是由Hash表来实现的，数组+链表（1.8加入红黑树）的方式实现的，通过key的hash值与数组长度取余来获取应插入数组的下标，如果产生Hash冲突，在原下标位置转为链表，当链表长度到达8并且数组长度大于等于64则转为红黑树。通过以上描述我们提以下问题：
1、什么是Hash表
我们知道数组的特点是：寻址容易，插入和删除困难。
链表的特点是：寻址困难，插入和删除容易。
那么我们能不能综合两者的特性，做出一种寻址容易，插入删除也容易的数据结构？答案是肯定的，这就是我们要提起的哈希表，哈希表有多种不同的实现方法，HashMap中最常用的一种方法——拉链法，我们可以理解为“链表的数组”，如图：
2、JDK1.8为什么引入红黑树？
Hash算法设计的再合理，也免不了会出现拉链过长的情况，一旦出现拉链过长，则会严重影响HashMap的性能。于是，在JDK1.8版本中，对数据结构做了进一步的优化，引入了红黑树。而当链表长度太长（默认超过8）时，链表就转换为红黑树，利用红黑树快速增删改查的特点提高HashMap的性能，其中会用到红黑树的插入、删除、查找等算法。
深入了解红黑树请移步这里https://blog.csdn.net/v_july_v/article/details/6105630
3、用什么方式解决Hash冲突？
解决Hash冲突方法有：开放地址法（线性探测再散列，二次探测再散列，伪随机探测再散列）、再哈希法、链地址法、建立公共溢出区。
HashMap使用链地址法来解决Hash冲突。
二：字段信息
transient Node<K,V>[] table; transient int size; transient int modCount; int threshold; final float loadFactor;
table是Hash表的数组结构，初始默认大小为16，里面存储Node信息
static class Node<K,V> implements Map.Entry<K,V> { final int hash; //用来定位数组索引位置 final K key; V value; Node<K,V> next; //链表的下一个node Node(int hash, K key, V value, Node<K,V> next) { ... } public final K getKey(){ ... } public final V getValue() { ... } public final String toString() { ... } public final int hashCode() { ... } public final V setValue(V newValue) { ... } public final boolean equals(Object o) { ... } }
Node是HashMap的一个内部类，实现了Map.Entry接口，本质是就是一个映射(键值对)。
Load factor为负载因子(默认值是0.75)，threshold是HashMap所能容纳的最大数据量的Node(键值对)个数。threshold = length * Load factor。也就是说，在数组定义好长度之后，负载因子越大，所能容纳的键值对个数越多。
threshold就是在此Load factor和length(数组长度)对应下允许的最大元素数目，超过这个数目就重新resize(扩容)，扩容后的HashMap容量是之前容量的两倍。默认的负载因子0.75是对空间和时间效率的一个平衡选择，建议不要修改，除非在时间和空间比较特殊的情况下，如果内存空间很多而又对时间效率要求很高，可以降低负载因子Load factor的值；相反，如果内存空间紧张而对时间效率要求不高，可以增加负载因子loadFactor的值，这个值可以大于1。
size是HashMap中实际存在的键值对数量，而modCount字段主要用来记录HashMap内部结构发生变化的次数，主要用于迭代的快速失败。强调一点，内部结构发生变化指的是结构发生变化，例如put新键值对，但是某个key对应的value值被覆盖不属于结构变化。
三：HashMap的hash方法原理
四：put方法
判断键值对数组table[i]是否为空或为null，否则执行resize()进行扩容。
根据键值key计算hash值得到插入的数组索引i，如果table[i]==null，直接新建节点添加，转向步骤6，如果table[i]不为空，转向步骤3。
判断table[i]的首个元素是否和key一样，如果相同直接覆盖value，否则转向步骤4，这里的相同指的是hashCode以及equals。
判断table[i] 是否为treeNode，即table[i] 是否是红黑树，如果是红黑树，则直接在树中插入键值对，否则转向步骤5。
遍历table[i]，判断链表长度是否大于8，大于8的话把链表转换为红黑树，在红黑树中执行插入操作，否则进行链表的插入操作；遍历过程中若发现key已经存在直接覆盖value即可。
插入成功后，判断实际存在的键值对数量size是否超多了最大容量threshold，如果超过，进行扩容。
public V put(K key, V value) { return putVal(hash(key), key, value, false, true); } final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) { Node<K,V>[] tab; Node<K,V> p; int n, i; // 步骤1：tab为空则创建 if ((tab = table) == null || (n = tab.length) == 0) n = (tab = resize()).length; // 步骤2：计算index，并对null做处理 if ((p = tab[i = (n - 1) & hash]) == null) tab[i] = newNode(hash, key, value, null); else { Node<K,V> e; K k; // 步骤3：节点key存在，直接覆盖value if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k)))) e = p; // 步骤4：判断该链为红黑树 else if (p instanceof TreeNode) e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); // 步骤5：该链为链表 else { for (int binCount = 0; ; ++binCount) { if ((e = p.next) == null) { p.next = newNode(hash, key, value, null); //链表长度大于8转换为红黑树进行处理 if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st treeifyBin(tab, hash); break; } // key已经存在直接覆盖value if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k)))) break; p = e; } } if (e != null) { // existing mapping for key V oldValue = e.value; if (!onlyIfAbsent || oldValue == null) e.value = value; afterNodeAccess(e); return oldValue; } } ++modCount; // 步骤6：超过最大容量 就扩容 if (++size > threshold) resize(); afterNodeInsertion(evict); return null; }
HashMap的扩容机制---resize()
什么时候扩容：当向容器添加元素的时候，会判断当前容器的元素个数，如果大于等于阈值(知道这个阈字怎么念吗？不念fa值，念yu值四声)---即当前数组的长度乘以加载因子的值的时候，就要自动扩容啦。
扩容(resize)就是重新计算容量，向HashMap对象里不停的添加元素，而HashMap对象内部的数组无法装载更多的元素时，对象就需要扩大数组的长度，以便能装入更多的元素。当然Java里的数组是无法自动扩容的，方法是使用一个新的数组代替已有的容量小的数组，就像我们用一个小桶装水，如果想装更多的水，就得换大水桶。
先看一下什么时候，resize();
/** * HashMap 添加节点 * * @param hash 当前key生成的hashcode * @param key 要添加到 HashMap 的key * @param value 要添加到 HashMap 的value * @param bucketIndex 桶，也就是这个要添加 HashMap 里的这个数据对应到数组的位置下标 */ void addEntry(int hash, K key, V value, int bucketIndex) { //size：The number of key-value mappings contained in this map. //threshold：The next size value at which to resize (capacity * load factor) //数组扩容条件：1.已经存在的key-value mappings的个数大于等于阈值 // 2.底层数组的bucketIndex坐标处不等于null if ((size >= threshold) && (null != table[bucketIndex])) { resize(2 * table.length);//扩容之后，数组长度变了 hash = (null != key) ? hash(key) : 0;//为什么要再次计算一下hash值呢？ bucketIndex = indexFor(hash, table.length);//扩容之后，数组长度变了，在数组的下标跟数组长度有关，得重算。 } createEntry(hash, key, value, bucketIndex); } /** * 这地方就是链表出现的地方，有2种情况 * 1，原来的桶bucketIndex处是没值的，那么就不会有链表出来啦 * 2，原来这地方有值，那么根据Entry的构造函数，把新传进来的key-value mapping放在数组上，原来的就挂在这个新来的next属性上了 */ void createEntry(int hash, K key, V value, int bucketIndex) { HashMap.Entry<K, V> e = table[bucketIndex]; table[bucketIndex] = new HashMap.Entry<>(hash, key, value, e); size++; }
我们分析下resize的源码，鉴于JDK1.8融入了红黑树，较复杂，为了便于理解我们仍然使用JDK1.7的代码，好理解一些，本质上区别不大，具体区别后文再说。
void resize(int newCapacity) { //传入新的容量 Entry[] oldTable = table; //引用扩容前的Entry数组 int oldCapacity = oldTable.length; if (oldCapacity == MAXIMUM_CAPACITY) { //扩容前的数组大小如果已经达到最大(2^30)了 threshold = Integer.MAX_VALUE; //修改阈值为int的最大值(2^31-1)，这样以后就不会扩容了 return; } Entry[] newTable = new Entry[newCapacity]; //初始化一个新的Entry数组 transfer(newTable); //！！将数据转移到新的Entry数组里 table = newTable; //HashMap的table属性引用新的Entry数组 threshold = (int) (newCapacity * loadFactor);//修改阈值 }
这里就是使用一个容量更大的数组来代替已有的容量小的数组，transfer()方法将原有Entry数组的元素拷贝到新的Entry数组里。
void transfer(Entry[] newTable) { Entry[] src = table; //src引用了旧的Entry数组 int newCapacity = newTable.length; for (int j = 0; j < src.length; j++) { //遍历旧的Entry数组 Entry<K, V> e = src[j]; //取得旧Entry数组的每个元素 if (e != null) { src[j] = null;//释放旧Entry数组的对象引用（for循环后，旧的Entry数组不再引用任何对象） do { Entry<K, V> next = e.next; int i = indexFor(e.hash, newCapacity); //！！重新计算每个元素在数组中的位置 e.next = newTable[i]; //标记[1] newTable[i] = e; //将元素放在数组上 e = next; //访问下一个Entry链上的元素 } while (e != null); } } }
static int indexFor(int h, int length) { return h & (length - 1); }
newTable[i]的引用赋给了e.next，也就是使用了单链表的头插入方式，同一位置上新元素总会被放在链表的头部位置；这样先放在一个索引上的元素终会被放到Entry链的尾部(如果发生了hash冲突的话），这一点和Jdk1.8有区别（不再使用头插法，因为会存在并发问题），下文详解。在旧数组中同一条Entry链上的元素，通过重新计算索引位置后，有可能被放到了新数组的不同位置上。
从上面的for循环内部开始说起吧:详细解释下，这个转存的过程。和怎么个头插入法（看代码更容易，就是循环的换到另一个连表上，如果冲突）.
Entry<K, V> e = src[j];
这句话，就把原来数组上的那个链表的引用就给接手了，所以下面src[j] = null;可以放心大胆的置空，释放空间。告诉gc这个地方可以回收啦。
继续到do while 循环里面，
Entry<K, V> next = e.next;
int i = indexFor(e.hash, newCapacity);计算出元素在新数组中的位置
下面就是单链表的头插入方式转存元素啦
关于这个 单链表的头插入方式 的理解，我多说两句。
这地方我再看的时候，就有点蒙了，他到底怎么在插到新的数组里面的？
要是在插入新数组的时候，也出现了一个数组下标的位置处，出现了多个节点的话，那又是怎么插入的呢？
1，假设现在刚刚插入到新数组上，因为是对象数组，数组都是要默认有初始值的，那么这个数组的初始值都是null。不信的可以新建个Javabean数组测试下。
那么e.next = newTable[i],也就是e.next = null啦。然后再newTable[i] = e;也就是 说这个时候，这个数组的这个下标位置的值设置成这个e啦。
2，假设这个时候，继续上面的循环，又取第二个数据e2的时候，恰好他的下标和刚刚上面的那个下标相同啦，那么这个时候，是又要有链表产生啦、
e.next = newTable[i];，假设上面第一次存的叫e1吧，那么现在e.next = newTable[i];也就是e.next = e1；
然后再，newTable[i] = e;，把这个后来的赋值在数组下标为i的位置，当然他们两个的位置是相同的啦。然后注意现在的e，我们叫e2吧。e2.next指向的是刚刚的e1，e1的next是null。
这就解释啦：先放在一个索引上的元素终会被放到Entry链的尾部。这句话。
关于什么时候resize（）的说明：
看1.7的源码上说的条件是：
if ((size >= threshold) && (null != table[bucketIndex])) {。。。}
其中
size表示当前hashmap里面已经包含的元素的个数。
threshold：threshold = (int) Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1);
一般是容量值X加载因子。
而1.8的是：
if (++size > threshold){}
其中
size：The number of key-value mappings contained in this map.和上面的是一样的
threshold：newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
也是一样的，
最后总结一下：就是这个map里面包含的元素，也就是size的值，大于等于这个阈值的时候，才会resize（）；
具体到实际情况就是：假设现在阈值是4；在添加下一个假设是第5个元素的时候，这个时候的size还是原来的，还没加1，size=4，那么阈值也是4的时候，
当执行put方法，添加第5个的时候，这个时候，4 >= 4。元素个数等于阈值。就要resize（）啦。添加第4的时候，还是3 >= 4不成立，不需要resize（）。
经过这番解释，可以发现下面的这个例子，不应该是在添加第二个的时候resize（），而是在添加第三个的时候，才resize（）的。
这个也是我后来再细看的时候，发现的。当然，这个咱可以先忽略，重点看如何resize（），以及如何将旧数据移动到新数组的
下面我们讲解下JDK1.8做了哪些优化。经过观测可以发现，我们使用的是2次幂的扩展(指长度扩为原来2倍)，所以，
经过rehash之后，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。对应的就是下方的resize的注释。
/** * Initializes or doubles table size. If null, allocates in * accord with initial capacity target held in field threshold. * Otherwise, because we are using power-of-two expansion, the * elements from each bin must either stay at same index, or move * with a power of two offset in the new table. * * @return the table */ final Node<K,V>[] resize() { }
看下图可以明白这句话的意思，n为table的长度，图（a）表示扩容前的key1和key2两种key确定索引位置的示例，图（b）表示扩容后key1和key2两种key确定索引位置的示例，其中hash1是key1对应的哈希值(也就是根据key1算出来的hashcode值)与高位与运算的结果。
元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：
因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”（加原数组的长度），可以看看下图为16扩充为32的resize示意图：
这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。有兴趣的同学可以研究下JDK1.8的resize源码，写的很赞，如下:
final Node<K,V>[] resize() { Node<K,V>[] oldTab = table; int oldCap = (oldTab == null) ? 0 : oldTab.length; int oldThr = threshold; int newCap, newThr = 0; if (oldCap > 0) { // 超过最大值就不再扩充了，就只好随你碰撞去吧 if (oldCap >= MAXIMUM_CAPACITY) { threshold = Integer.MAX_VALUE; return oldTab; } // 没超过最大值，就扩充为原来的2倍 else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY && oldCap >= DEFAULT_INITIAL_CAPACITY) newThr = oldThr << 1; // double threshold } else if (oldThr > 0) // initial capacity was placed in threshold newCap = oldThr; else { // zero initial threshold signifies using defaults newCap = DEFAULT_INITIAL_CAPACITY; newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY); } // 计算新的resize上限 if (newThr == 0) { float ft = (float)newCap * loadFactor; newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ? (int)ft : Integer.MAX_VALUE); } threshold = newThr; @SuppressWarnings({"rawtypes"，"unchecked"}) Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap]; table = newTab; if (oldTab != null) { // 把每个bucket都移动到新的buckets中 for (int j = 0; j < oldCap; ++j) { Node<K,V> e; if ((e = oldTab[j]) != null) { oldTab[j] = null; if (e.next == null) newTab[e.hash & (newCap - 1)] = e; else if (e instanceof TreeNode) //如果是红黑树节点 ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); else { // 链表优化重hash的代码块 Node<K,V> loHead = null, loTail = null; Node<K,V> hiHead = null, hiTail = null; Node<K,V> next; do { next = e.next; // 原索引 if ((e.hash & oldCap) == 0) { if (loTail == null) loHead = e; else loTail.next = e; loTail = e; } // 原索引+oldCap else { if (hiTail == null) hiHead = e; else hiTail.next = e; hiTail = e; } } while ((e = next) != null); // 原索引放到bucket里 if (loTail != null) { loTail.next = null; newTab[j] = loHead; } // 原索引+oldCap放到bucket里 if (hiTail != null) { hiTail.next = null; newTab[j + oldCap] = hiHead; } } } } } return newTab; }
先略过红黑树的情况，描述下简单流程，在JDK1.8中发生hashmap扩容时，遍历hashmap每个bucket里的链表，每个链表可能会被拆分成两个链表，不需要移动的元素置入loHead为首的链表，需要移动的元素置入hiHead为首的链表，然后分别分配给老的buket和新的buket。
补充一下jdk 1.8中，HashMap扩容时红黑树的表现
扩容时，如果节点是红黑树节点，就会调用TreeNode的split方法对当前节点作为跟节点的红黑树进行修剪
... else if (e instanceof TreeNode) //如果是红黑树节点 ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); ...
//参数介绍 //tab 表示保存桶头结点的哈希表 //index 表示从哪个位置开始修剪 //bit 要修剪的位数（哈希值） 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; //如果当前节点哈希值的最后一位等于要修剪的 bit 值 if ((e.hash & bit) == 0) { //就把当前节点放到 lXXX 树中 if ((e.prev = loTail) == null) loHead = e; else loTail.next = e; //然后 loTail 记录 e loTail = e; //记录 lXXX 树的节点数量 ++lc; } else { //如果当前节点哈希值最后一位不是要修剪的 //就把当前节点放到 hXXX 树中 if ((e.prev = hiTail) == null) hiHead = e; else hiTail.next = e; hiTail = e; //记录 hXXX 树的节点数量 ++hc; } } if (loHead != null) { //如果 lXXX 树的数量小于 6，就把 lXXX 树的枝枝叶叶都置为空，变成一个单节点 //然后让这个桶中，要还原索引位置开始往后的结点都变成还原成链表的 lXXX 节点 //这一段元素以后就是一个链表结构 if (lc <= UNTREEIFY_THRESHOLD) tab[index] = loHead.untreeify(map); else { //否则让索引位置的结点指向 lXXX 树，这个树被修剪过，元素少了 tab[index] = loHead; if (hiHead != null) // (else is already treeified) loHead.treeify(tab); } } if (hiHead != null) { //同理，让 指定位置 index + bit 之后的元素 //指向 hXXX 还原成链表或者修剪过的树 if (hc <= UNTREEIFY_THRESHOLD) tab[index + bit] = hiHead.untreeify(map); else { tab[index + bit] = hiHead; if (loHead != null) hiHead.treeify(tab); } } }
从上述代码可以看到，HashMap 扩容时对红黑树节点的修剪主要分两部分，先分类、再根据元素个数决定是还原成链表还是精简一下元素仍保留红黑树结构。
1.分类
指定位置、指定范围，让指定位置中的元素 （hash & bit) == 0 的，放到 lXXX 树中，不相等的放到 hXXX 树中。
2.根据元素个数决定处理情况
符合要求的元素（即 lXXX 树），在元素个数小于等于 6 时还原成链表，最后让哈希表中修剪的痛 tab[index] 指向 lXXX 树；在元素个数大于 6 时，还是用红黑树，只不过是修剪了下枝叶；
不符合要求的元素（即 hXXX 树）也是一样的操作，只不过最后它是放在了修剪范围外 tab[index + bit]。
(1) 扩容是一个特别耗性能的操作，所以当程序员在使用HashMap的时候，估算map的大小，初始化的时候给一个大致的数值，避免map进行频繁的扩容。
(2) 负载因子是可以修改的，也可以大于1，但是建议不要轻易修改，除非情况非常特殊。
(3) HashMap是线程不安全的，不要在并发的环境中同时操作HashMap，建议使用ConcurrentHashMap。
(4) JDK1.8引入红黑树大程度优化了HashMap的性能。
(5) 还没升级JDK1.8的，现在开始升级吧。HashMap的性能提升仅仅是JDK1.8的冰山一角。
六：为什么1.8之后超过8会转化为红黑树
为什么不是平衡二叉树？
AVL树(平衡二叉树)
AVL树是带有平衡条件的二叉查找树，一般是用平衡因子差值判断是否平衡并通过旋转来实现平衡，左右子树高度差不超过1，和红黑树相比，AVL树是严格的平衡二叉树，平衡条件必须满足(所有结点的左右子树高度差不超过1)。不管我们是执行插入还是删除操作，只要不满足上面的条件，就要通过旋转来保存平衡，而因为旋转非常耗时，由此我们可以知道AVL树适合用于插入与删除次数比较少，但查找多的情况。
局限性：
由于维护这种高度平衡所付出的代价比从中获得的效率收益还大，故而实际的应用不多，更多的地方是用追求局部而不是非常严格整体平衡的红黑树。当然，如果应用场景中对插入删除不频繁，只是对查找要求较高，那么AVL还是较优于红黑树。
红黑树
一种二叉查找树，但在每个节点增加一个存储位表示结点的颜色，可以是红或黑(非红即黑)。通过对任何一条从根到叶子的路径上各个节点着色的方式的限制，红黑树确保没有一条路径会比其他路径长出两倍，因此，红黑树是一中弱平衡二叉树(由于是弱平衡，可以看到，在相同的节点情况下，AVL树的高度低于红黑树)，相对于要求严格的AVL树来说，它的旋转次数少，插入最多两次旋转，删除最多三次旋转，所以对于搜索，插入，删除操作较多的情况下，我们就用红黑树。
特点：
结点非红即黑
根结点是黑色的
每个叶子节点(NULL节点)是黑色的
每个红色节点的两个子节点都是黑色的。(不能有两连续的红色节点)
从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点。
、
JDK1.8中HashMap优化分析
1. hash算法优化
// jdk1.8 HashMap中hash源码 static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); }
源码解读：
用 （key的hash值） 与 （key的hash值右移16位）进行异或运算
例如：
HashMap<String,String> hashMap = new HashMap<>(); // 1 hashMap.put("test1","测试数据1"); // 2 hashMap.put("test2","测试数据2"); // 3
详细过程：
// 对第二行中的key进行hash： // hash后： h = 110251487 // 二进制的表示形式为： 0000 0110 1001 0010 0100 1101 1101 1111 // 对其右移16位： 0000 0000 0000 0000 0000 0110 1001 0010 // 进行异或运算： 0000 0110 1001 0010 0100 1011 0100 1101 // 转回二进制为： 110250829
右移16位：将高16位推到了低16位上，高16位用0来补齐 ^表示异或：a、b两个值不同，则异或结果为1。如果相同，异或结果为0 &表与运算：两位同时为“1”，结果才为“1”，否则为0
优化的实质是将高16位与低16位进行异或运算（结果中与之前高十六位是一致）。
这么做的目的是：是希望低16位中同时保留低16位与高16位的特征，尽量避免key的低16位近似，以免发生hash冲突
2. 寻址算法优化
核心：hash & (n-1)
第一步中异或后的值 与 数组长度-1进行 &(与) 运算
0000 0110 1001 0010 0100 1011 0100 1101
0000 0000 0000 0000 0000 0000 0000 1111（假设数组长度16 ，15的二进制）
因为15的高16位都为0，所以与运算结果都是0，一般数组的值都比较小，所以核心点在低16位的与运算；
问题：为什么不再像JDK1.7一样进行取模运算？
答 ：取模运算相对来说性能比较差一些，hash&(n-1) 与取模操作效果一样，但是与运算的性能更高
问题：为什么hash&(n-1)和hash值对数组长度取模效果一样？
答：数学上得到结论，当数组长度是2的幂次时，hash值对数组长度取模的效果和 hash&(n-1) 是一样的。
寻址算法优化的目的：用与运算代替取模，提升性能。
3. 解决hash碰撞问题
多个key的hash值，与 n-1 (数组长度减一) ，与运算之后，依旧会出现定位的位置相同问题，即 hash碰撞
解决方式为：
如果发现定位到的位置已有元素，则在该位置挂一个链表，在链表里放多个元素，用来解决hash碰撞问题。
在使用get方法时，如果发现该位置是一个链表，则遍历该链表，拿到该key对应的元素。
但是当链表的长度过长时，性能会下降，时间复杂度为O(n)
所以当检测到链表达到一定长度时（当链表长度大于8的时候转换为红黑树），将链表转化为红黑树，来提升性能，红黑树的时间复杂度为：logn
4. 扩容
当put时检测到数组满了，则进行扩容，扩容的方式是2倍扩容
进行rehash时，使用key的hash与新的数组长度-1进行与运算，判断结果的高位是否多出一个 bit 的 1，如果没多，那么就是原来的index，如果多了出来，那么就是index+oldCap（原来的index+原来数组的长度），通过这个方式，可以避免rehash时，用每个hash对新的数组.length进行取模，取模性能不高，位运算的性能比较高
5. jdk1.7中扩容后死循环问题
HashMap扩容导致死循环的主要原因：
在于扩容过程中使用头插法将oldTable中的单链表中的节点插入到newTable的单链表中，所以newTable中的单链表会倒置oldTable中的单链表。那么在多个线程同时扩容的情况下就可能导致扩容后的HashMap中存在一个有环的单链表，从而导致后续执行get操作的时候，会触发死循环，引起CPU的100%问题。所以一定要避免在并发环境下使用HashMap。
jdk1.7 HashMap扩容时死循环问题
jdk1.7 hashmap在resize时进行扩容时，会导致死循环，主要是因为jdk1.7采用的是头插法
void transfer(Entry[] newTable, boolean rehash) { int newCapacity = newTable.length; for (Entry<K,V> e : table) { while(null != e) { Entry<K,V> next = e.next; if (rehash) { e.hash = null == e.key ? 0 : hash(e.key); } int i = indexFor(e.hash, newCapacity); e.next = newTable[i]; newTable[i] = e; e = next; } } }
假如hashmap有一个链表的数据是A,B,C。
当进行扩容时，有两个线程进行处理。
假如
1.线程1扩容时，执行到e=A，然后next是B，这时候线程1的时间片结束
2.线程2此时进行扩容，执行e=A，next 是B，再往下执行，此时链表的结构是 B->A,此时线程2时间片结束
3.线程1进入数据区再进行处理，A处理完之后处理B，但是由于B之前已经next指向了A，现在又拿到了A，根据头插法A又要插在B前面，即A->B，但是又是之前已经又B->A这样的结构，这样就形成了循环链表。
在hashmap的get时候，如果给A或者B还可以取得到，如果get C 那就取不到，就会死循环，CPU占据100%
HashCode计算方法
前一次的结果*31+本次的ascall值，结果作为下次循环的输入。
参考：
(7条消息) JDK1.8中HashMap优化分析_dwhhome的博客-CSDN博客
(7条消息) jdk1.7 HashMap扩容时死循环问题_xby7437的博客-CSDN博客_hashmap扩容时死循环问题