Hashmap321

介绍：
先看看HashMap类头部的源码：

public class HashMap<K,V>

extends AbstractMap<K,V>

implements Map<K,V>, Cloneable, Serializable

HashMap基于哈希表的 Map 接口的实现。此实现提供所有可选的映射操作，并允许使用 null 值和 null 键。
HashMap 的实例有两个参数影响其性能：初始容量和负载因子。容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。负载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行 rehash 操作（即重建内部数据结构），从而哈希表将具有大约两倍的桶数。

HashMap存储结构

属性分析：

static final int DEFAULT_INITIAL_CAPACITY = 16;
HashMap默认的初始化容量是16，如上图所示：对于HashMap中桶数量的值必须是2的N次幂，而且这个是HashMap强制规定的。这样做的原因就是因为计算机进行2次幂的运算是非常高效的，仅通过位移操作就可以完成2的N次幂的运算。

static final int MAXIMUM_CAPACITY = 1 << 30;

MAXIMUM_CAPACITY是HashMap中散列桶数量的最大值，从上面的代码可知这个最大值为2的32次幂，即1073741824。

static final float DEFAULT_LOAD_FACTOR = 0.75f;
默认的负载因子，如果在在创建HashMap的构造函数中没有指定负载因子，则指定该HashMap的默认负载因子为0.75，这意味着当HashMap中条目的数量达到了条目数量75%时，HashMap将进行resize操作以增加桶的数量。
int threshold;
threshold是HashMap的重构阈值，它的值为容量和负载因子的乘积。在HashMap中所有桶中条目的总数量达到了这个重构阈值之后，HashMap将进行resize操作以自动扩容。

final float loadFactor;
loadFactor表示HashMap的负载因子，它和容量一样都是HashMap扩容的决定性因素。

哈希冲突
哈希是通过对数据进行再压缩，提高效率的一种解决方法。但由于通过哈希函数产生的哈希值是有限的，而数据可能比较多，导致经过哈希函数处理后仍然有不同的数据对应相同的哈希值。这时候就产生了哈希冲突。

HashMap之1.7和1.8的区别

• 底层数据结构不一样，1.7是数组+链表，1.8则是数组+链表+红黑树结构（当链表长度大于8，转为红黑树）
• JDK1.8中resize()方法在表为空时，创建表；在表不为空时，扩容；而JDK1.7中resize()方法负责扩容，inflateTable()负责创建表。
• 1.8中没有区分键为null的情况，而1.7版本中对于键为null的情况调用putForNullKey()方法。但是两个版本中如果键为null，那么调用hash()方法得到的都将是0，所以键为null的元素都始终位于哈希表table【0】中。
• 当1.8中的桶中元素处于链表的情况，遍历的同时最后如果没有匹配的，直接将节点添加到链表尾部；而1.7在遍历的同时没有添加数据，而是另外调用了addEntry()方法，将节点添加到链表头部。
• 1.7中新增节点采用头插法，1.8中新增节点采用尾插法。这也是为什么1.8不容易出现环型链表的原因。
• 1.7中是通过更改hashSeed值修改节点的hash值从而达到rehash时的链表分散，而1.8中键的hash值不会改变，rehash时根据（hash&oldCap）==0将链表分散。
• 1.8rehash时保证原链表的顺序，而1.7中rehash时有可能改变链表的顺序（头插法导致）。
• 在扩容的时候：1.7在插入数据之前扩容，而1.8插入数据成功之后扩容。