前言
HashMap是java中大家经常使用的容器之一，采用哈希算法（映射算法，散列算法），将不定长的数据压缩成定长的数据，这串定长值我们称为哈希值，并将不同的哈希值分组存起来，每一个分组我们认为是一个槽。我们将不同的数据格式通过哈希算法，将其映射到不同的槽内，当我们需要取数据时，把需要的数据转化成哈希值，再凭借哈希值去找对应的槽，然后便可以将数据取出来.
数据存储结构
如下图所示，相比较JDK1.7的数据结构(数组+单向链表),在JDK1.8中HashMap引入了红黑树，那为什么要引入红黑树呢，主要是为了解决哈希碰撞以后因链表过长而导致索引查询过慢的问题，换成红黑树之后能够有效的避免了 Hash Collision DoS （Hash碰撞的拒绝式服务攻击）,红黑树的引入将增删改查的时间复杂度从O(n)改善为O(log n)。
HashMap类中有一个非常重要的字段，就是 Node[] table，即哈希桶数，Node是HashMap的一个内部类，实现了Map.Entry接口，本质是就是一个映射(键值对)。
HashMap就是使用哈希表来存储的，哈希表为解决冲突，可以采用开放地址法和链地址法等来解决问题，Java中HashMap采用了链地址法。链地址法，简单来说，就是数组加链表的结合。在每个数组元素上都有一个链表结构，当数据被Hash后，得到数组下标，把数据放在对应下标元素的链表上。
如果哈希桶数组很大，即使较差的Hash算法也会比较分散，如果哈希桶数组数组很小，即使好的Hash算法也会出现较多碰撞，所以就需要在空间成本和时间成本之间权衡，根据实际情况确定哈希桶数组的大小，并在此基础上设计好的hash算法减少Hash碰撞。那么通过什么方式来控制map使得Hash碰撞的概率又小、哈希桶数组（Node[] table）占用空间又少呢？答案就是好的Hash算法和扩容机制。在理解Hash和扩容流程之前，我们得先了解下HashMap的几个重要参数：
首先，Node[] table的初始化长度length(默认值是16)，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中实际存在的键值对数量。注意和table的长度length、容纳最大键值对数量threshold的区别。而modCount字段主要用来记录HashMap内部结构发生变化的次数，主要用于迭代的快速失败。强调一点，内部结构发生变化指的是结构发生变化，例如put新键值对，但是某个key对应的value值被覆盖不属于结构变化。
在HashMap中，哈希桶数组table的长度length大小必须为2的n次方(一定是合数)，这是一种非常规的设计，常规的设计是把桶的大小设计为素数。相对来说素数导致冲突的概率要小于合数，Hashtable初始化桶大小为11，就是桶大小设计为素数的应用（Hashtable扩容后不能保证还是素数）。HashMap采用这种非常规设计，主要是为了在取模和扩容时做优化，同时为了减少冲突，HashMap定位哈希桶索引位置时，也加入了高位参与运算的过程。
这里存在一个问题，即使负载因子和Hash算法设计的再合理，也免不了会出现拉链过长的情况，一旦出现拉链过长，则会严重影响HashMap的性能。于是，在JDK1.8版本中，对数据结构做了进一步的优化，引入了红黑树。而当链表长度太长（默认超过8）时，链表就转换为红黑树，利用红黑树快速增删改查的特点提高HashMap的性能，其中会用到红黑树的插入、删除、查找等算法。
哈希算法的实现
HashMap定位数组索引位置，直接决定了hash方法的离散性能，为了提高存储key-value的数组下标位置 的随机性和分布均匀性，尽量避免出现hash值冲突，在JDK1.7是通过以下两个方法来计算位置的，hash方法主要是计算hash码值通过使用hashCode() + 4次位运算 + 5次异或运算（总共9次扰动），indexFor则是将对哈希码扰动处理后的结果 与运算(&) （数组长度-1）最终得到存储在数组table的位置（即数组下标、索引）.
JDK1.7hash算法实现如下：
JDK1.8hash算法实现：
源码中没有直接采用经过hashCode方法处理的哈希码作为存储数组table的下标位置是为了解决计算出来的哈希码可能不在数组大小范围内，从而导致无法匹配存储位置问题(哈希码 &（数组长度-1）巧妙的解决)；
为什么在计算数组下标前，需对哈希码进行二次处理：扰动处理？主要是为了加大哈希码低位的随机性，使得分布更均匀，从而提高对应数组存储下标位置的随机性和均匀性，最终减少Hash冲突。
这个方法非常巧妙，它通过h & (table.length -1)来得到该对象的保存位，而HashMap底层数组的长度总是2的n次方，这是HashMap在速度上的优化。当length总是2的n次方时，h& (length-1)运算等价于对length取模，也就是h%length，但是&比%具有更高的效率。
