HashMap源码分析
HashMap
HashMap根据键的hashCode值存储数据，大多数情况下可以直接定位到它的值，因而具有很快的访问速度，但遍历顺序却是不确定的。 HashMap最多只允许一条记录的键为null，允许多条记录的值为null。HashMap非线程安全，即任一时刻可以有多个线程同时写HashMap，可能会导致数据的不一致。如果需要满足线程安全，可以用 Collections的synchronizedMap方法使HashMap具有线程安全的能力，或者使用ConcurrentHashMap。
public class HashMap<K,V> extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable {
构造方法
HashMap中有四个构造方法，它们分别如下：
static final int MAXIMUM_CAPACITY = 1 << 30;
// 指定“容量大小”和“加载因子”的构造函数
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);
}
// 指定“容量大小”的构造函数
public HashMap(int initialCapacity) {
this(initialCapacity, DEFAULT_LOAD_FACTOR);
}
// 默认构造函数。初始容量为16，默认加载因子为0.75
public HashMap() {
this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}
// 包含另一个“Map”的构造函数，加载因子为默认的0.75
public HashMap(Map<? extends K, ? extends V> m) {
this.loadFactor = DEFAULT_LOAD_FACTOR;
putMapEntries(m, false);
}
putMapEntries方法是putAll和Map其中一个构造器（参数为Map类型）的底层实现
final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
int s = m.size();
if (s > 0) {
// 判断table是否已经初始化
if (table == null) { // pre-size
// 未初始化，s为m的实际元素个数
float ft = ((float)s / loadFactor) + 1.0F;
int t = ((ft < (float)MAXIMUM_CAPACITY) ?
(int)ft : MAXIMUM_CAPACITY);
// 计算得到的t大于阈值，则初始化阈值
if (t > threshold)
threshold = tableSizeFor(t);
}
// 已初始化，并且m元素个数大于阈值，进行扩容处理
else if (s > threshold)
resize();
// 将m中的所有元素添加至HashMap中
for (Map.Entry<? extends K, ? extends V> e : m.entrySet()) {
K key = e.getKey();
V value = e.getValue();
putVal(hash(key), key, value, false, evict);
}
}
}
观察上面的构造器可以发现，我们在创建HashMap对象的时候，也可以传入一个指定的容量initialCapacity。传入的initialCapacity的大小最好是2的幂次方，如果不是，则HashMap会利用一个tableSizeFor方法将传入的initialCapacity变为大于initialCapacity同时又最接近它的2的幂次方。
tableSizeFor方法的计算逻辑如下：
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;
}
演示案例：
存储结构
JDK1.8之前HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。
JDK1.8之后（包括JDK1.8）HashMap的组成多了红黑树，在满足下面两个条件之后，会执行链表转红黑树操作，以此来加快搜索速度。
- 链表长度大于阈值（默认为 8）
- HashMap 数组长度超过 64
那么HashMap在底层中是如何实现这样的结构的呢？下面来进行分析：
（1）在HashMap类中，有一个比较重要的属性，就是Node[] table，即哈希桶数组，明显它是一个Node的数组
transient Node<K,V>[] table;
根据注释可以知道，该表（Node数组）在首次使用时初始化，并根据需要调整大小。在为它分配容量时，长度始终是2的幂。查看一下Node类表达的含义：
static class Node<K,V> implements Map.Entry<K,V> {
final int hash;//用来定位数组索引位置
final K key;
V value;
Node<K,V> next;
Node(int hash, K key, V value, Node<K,V> next) {
this.hash = hash;
this.key = key;
this.value = value;
this.next = next;
}
public final K getKey() { return key; }
public final V getValue() { return value; }
public final String toString() { return key + "=" + value; }
public final int hashCode() {
return Objects.hashCode(key) ^ Objects.hashCode(value);
}
public final V setValue(V newValue) {
V oldValue = value;
value = newValue;
return oldValue;
}
public final boolean equals(Object o) {
if (o == this)
return true;
if (o instanceof Map.Entry) {
Map.Entry<?,?> e = (Map.Entry<?,?>)o;
if (Objects.equals(key, e.getKey()) &&
Objects.equals(value, e.getValue()))
return true;
}
return false;
}
}
Node是HashMap的一个内部类，实现了Map.Entry接口，本质上就是作为哈希表中的基本元素存在的，即上图中黑色圆圈表示的就是一个Node对象。
一个Node对象存储了一个键值对，其中这个Node对象的hash属性和key属性都被final修饰了，说明在初始化以后，值就不能改变了。该类还重写了equals方法，两个Node对象是否相等的判断逻辑是：
1）如果指定的对象和这个对象本身是同一个对象，直接返回true；
2）如果指定对象中的key和value分别与调用equals方法的对象的key和value的值相等，那么就说明两个Node对象是相等。
Node类中还有一个属性Node<K,V> next，用于指向链表中的下一个node。所以可知，Node对象就是哈希表中的基本元素，通过hash值确定它在数组中的索引位置，还含有一个存储链表中其下一个节点的引用的属性next。同时，一个Node对象初始化以后，key和hash都是不能修改的，值可以修改。
（2）HashMap就是使用哈希表来存储的。但是哈希表可能会产生哈希冲突，为了解决哈希冲突的可以采用开放地址法和链地址法等来解决问题，Java中HashMap采用了”拉链法“，即数组+链表的组合。也就是说创建一个链表数组，在每个数组元素上都有一个链表结构，当数据被Hash后，得到数组下标，把数据放在对应下标元素的链表上。
JDK1.8 之前 HashMap底层是数组和链表结合在一起使用也就是链表散列。 HashMap通过key的hashCode经过扰动函数（hash方法）处理过后得到hash值，然后通过 (n - 1) & hash判断当前元素在数组中的存放的位置（这里的n指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的hash值以及key是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。
所谓扰动函数指的就是HashMap的hash方法。使用hash方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法换句话说使用扰动函数之后可以减少碰撞。
(n - 1) & hash：
if ((p = tab[i = (n - 1) & hash]) == null)
JDK1.8的hash方法：
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
JDK1.7的HashMap的hash方法：
static int hash(int h) {
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
相比于JDK1.8 的hash方法 ，JDK 1.7 的hash方法的性能会稍差一点点，因为毕竟扰动了4次。
为什么HashMap的长度是2的幂次方？
为了能让HashMap存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀。Hash值的范围值-2147483648到2147483647，前后加起来大概40亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但问题是一个40亿长度的数组，内存是放不下的。所以这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来作为存放的位置，也就是对应的数组下标。
我们首先想到的方法是采用%取模的操作。但是在模运算当中，如果模运算的除数是2的幂次，则这个模运算等价于被除数与（除数减1）的与（&）操作，也就是说，length如果是2的n次方，hash值与数组长度的取模运算可以等价为：
hash % length == hash & (length - 1)
采用二进制位操作&，相对于%能够提高运算效率，这就解释了HashMap的长度为什么是2的幂次方。
重要字段
从HashMap的默认构造函数源码可知，构造函数就是对下面几个字段进行初始化：
int threshold; // 当前容量下所能容纳的最大的key-value对数量
final float loadFactor; // 负载因子
int modCount;
int size;
首先，Node[] table的初始化长度length(默认值是16)，LoadFactor为负载因子(默认值是0.75)，threshold是HashMap当前容量和负载因子的限制下所能容纳的最大数据量的Node(键值对)个数。threshold = length * Load factor。也就是说，在数组定义好长度之后，负载因子越大，所能容纳的键值对个数越多。
table的初始化是在第一次使用时进行：
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
在resize方法中会判断table是否为0，以及阈值是否为0，如果都为0，说明还未被初始化，需要进行初始化：
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
结合阈值threshold的定义公式可知，threshold就是在此LoadFactor和length(数组长度)对应下允许的最大元素数目，超过这个数目就重新resize(扩容)，扩容后的HashMap容量是之前容量的两倍。扩容是也是由resize方法完成的，其源码如下：
if (oldCap > 0) {
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
可见容量和阈值均变成了原来的两倍。默认的负载因子0.75是对空间和时间效率的一个平衡选择，建议大家不要修改，除非在时间和空间比较特殊的情况下，如果内存空间很多而又对时间效率要求很高，可以降低负载因子Load factor的值；相反，如果内存空间紧张而对时间效率要求不高，可以增加负载因子loadFactor的值，这个值可以大于1。
size这个字段记录的是HashMap中实际存在的键值对数量。和Node table数组的长度length、容纳最大键值对数量threshold是不一样的。
modCount字段主要用来记录HashMap内部结构发生变化的次数，主要用于迭代的快速失败。强调一点，内部结构发生变化指的是结构发生变化，例如put新键值对，但是某个key对应的value值被覆盖不属于结构变化。
在HashMap中，哈希桶数组table的长度length大小必须为2的n次方(一定是合数)，HashMap采用这种非常规设计，主要是为了在取模和扩容时做优化，同时为了减少冲突，HashMap定位哈希桶索引位置时，也加入了高位参与运算的过程。常规的设计是把桶的大小设计为素数。相对来说素数导致冲突的概率要小于合数，Hashtable初始化桶大小为11，就是桶大小设计为素数的应用（Hashtable扩容后不能保证还是素数）。
这里存在一个问题，即使负载因子和Hash算法设计的再合理，也免不了会出现拉链过长的情况，一旦出现拉链过长，则会严重影响HashMap的性能。于是，在JDK1.8版本中，对数据结构做了进一步的优化，引入了红黑树。而当链表长度太长（默认超过8）时，链表就转换为红黑树，利用红黑树快速增删改查的特点提高HashMap的性能，其中会用到红黑树的插入、删除、查找等算法。（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）
存储数据的流程
在HashMap中，用于存放数据的方法有put、putAll等方法，这些方法最终都会调用一个putVal方法将数据存放到集合中：
public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}
public void putAll(Map<? extends K, ? extends V> m) {
putMapEntries(m, true);
}
1、确定哈希桶数组索引位置
在调用putVal方法之前，它们都会先计算传入的键值对的hash值：
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
第一步取key的hashCode值，第二步高位参与运算。在JDK1.8的实现中，优化了高位运算的算法，是通过hashCode()的高16位异或低16位实现的：(h = k.hashCode()) ^ (h >>> 16)，主要是从速度、功效、质量来考虑的，这么做可以在数组table的length比较小的时候，也能保证考虑到高低Bit都参与到Hash的计算中，同时不会有太大的开销。
计算完hash之后，将计算的hash值传入到putVal方法中，进行取模运算。所以Hash算法本质上就是三步：取key的hashCode值、高位运算、取模运算。
取模运算：
if ((p = tab[i = (n - 1) & hash]) == null)
这个方法非常巧妙，它通过h & (table.length -1)来得到该对象的保存位，而HashMap底层数组的长度总是2的n次方，这是HashMap在速度上的优化。当length总是2的n次方时，h& (length-1)运算等价于对length取模，也就是h%length，但是&比%具有更高的效率。
2、put流程
HashMap的put方法执行过程可以通过下面的流程图来理解：
// 此处传入的hash值已经是通过key的hashcode值进行高位异或运算之后的
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
// 如果tab（哈希桶数组）为空，则进行初始化创建
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
// 计算要添加的对象在数组中的index（元素应该放入哪个桶中），并对null做处理
if ((p = tab[i = (n - 1) & hash]) == null)
//如果计算出的索引位置为null（桶为空，新生成结点放入桶中），那么就直接插入键值对(此时，这个结点是放在数组中)
tab[i] = newNode(hash, key, value, null);
// 桶中已经存在元素
else {
Node<K,V> e; K k;
// 计算出的数组中的index位置不为null
// 判断传入的键值对的key与数组中index位置的key是否相等（就是桶中第一个元素），如果相等则直接覆盖value
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
e = p;
// 判断这个位置存储的结构是否为红黑树，如果是的话，直接将键值对插入到红黑树中
else if (p instanceof TreeNode)
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
// 当前位置存储的结构是链表
else {
//循环遍历链表中的节点
for (int binCount = 0; ; ++binCount) {
// 如果在链表中未找到与要插入的节点的key相同的节点，那么插入一个新的节点来存储
// 采用链表插入方式是尾插法
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;
}
}
// 此处如果e不为空，说明找到了重复的key，直接替换掉旧值
if (e != null) { // existing mapping for key
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)
e.value = value;
afterNodeAccess(e);
// 返回旧值
return oldValue;
}
}
// 结构性修改，如果只是替换旧值，不算做结构修改
++modCount;
// 当前哈希表中的元素数量超过最大容量，进行扩容
if (++size > threshold)
resize();
afterNodeInsertion(evict);
return null;
}
3、扩容机制
扩容(resize)就是为哈希表重新分配容量，当不断地向HashMa集合里添加元素，而HashMap集合内部的数组无法装载更多的元素时，集合就需要扩大数组的长度，以便能装入更多的元素。当然Java里的数组是无法自动扩容的，方法是使用一个新的数组代替已有的容量小的数组。
进行扩容，会伴随着一次重新 hash 分配，并且会遍历 hash 表中所有的元素，是非常耗时的。在编写程序中，要尽量避免 resize。
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) {
// MAXIMUM_CAPACITY = 1 << 30 = 1073741824
// 容量超过这个值，就不再扩容了
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}
// 没超过最大值，就将容量扩大为原来的两倍
// DEFAULT_INITIAL_CAPACITY = 1 << 4 = 16
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
// 如果扩容后的容量小于最大容量同时旧的容量大于等于16，就将阈值扩大两倍
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);
}
// 计算新的阈值，也就是这次扩容之后，下一次再进行扩容应该元素数量大于多少
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的元素都移动到新的数组中的bucket中
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 { // preserve order
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
// 将原数组中位于同一个桶中的对象，重新计算在新数组中的位置
// 索引位置没有变的串成一个链表放入新数组的对应索引位置下
// 索引位置变为"原索引+oldCap"的串成一个链表放入新数组的对应索引位置下
// 采用的是尾插法，所以旧的链表插入到新的数组中时，链表的中元素不会倒置
do {
next = e.next;
// 如果为0，说明该对象在的索引没有变
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
// 不为0，说明该对象在新数组中索引位置变味了"原索引+oldCap"
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
}
重点讲解：
在将原有数组中的每个bucket的元素都移动到新的数组中的bucket中的时候，对于每个桶中的元素，它们在新的集合中的位置可能会发生一些变化。我们知道，元素被分配到哪个哈希桶中，是根据对象的key的hash值，然后与哈希桶数组的长度取模得到的。当我们扩充table的容量时，其长度也发生了变化，那么元素在table中的位置也应该随之变化，那么需要重新按照原来的方式计算么？如果这样的话，太耗费时间了，JDK1.8对此做了优化：
首先，假设初始容量为n = 16，此时有连个键值对存入了哈希表中：
哈希值 index
hash(key1) 0000 0101 0000 0101 5
hash(key2) 0001 0101 0000 0101 5
n-1 0000 1111
对哈希桶数组进行扩容，变为原来的两倍 n = 32
哈希值 index
hash(key1) 0000 0101 0000 0101 5
hash(key2) 0001 0101 0001 0101 21 = 5 + 16
n-1 0001 1111
可以看出，元素的位置在扩容之后要么是在原位置，要么是在原位置再移动2次幂的位置。哈希桶数组在容量扩大之后，因为容量n变为2倍，那么n-1的mask范围在高位多1bit，此时再与元素的hash值进行与运算，新的index就会发生类似上面的变化。
至于是否位置变化，取决于新的n-1在mask范围的最高位的1与hash值二进制形式中对应位置的元素与（&）运算之后是0还是1，如果是0，那么无需变化；如果是1，那么该对象的索引变为"原索引+oldCap"
这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。
由于将旧链表迁移到新链表时，采用的是尾插法，所以旧的链表插入到新的数组中时，链表的中元素不会倒置
获取数据
获取HashMap中的数据，主要是通过调用get方法，传入指定的key，获取对应的value。下面分析以下get方法的源码：
public V get(Object key) {
Node<K,V> e;
// 先去计算传入key的hash值，然后传入getNode方法中，依据key和其hash值寻找value
return (e = getNode(hash(key), key)) == null ? null : e.value;
}
final Node<K,V> getNode(int hash, Object key) {
Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
// 查找key在哪个桶中
if ((tab = table) != null && (n = tab.length) > 0 &&
(first = tab[(n - 1) & hash]) != null) {
// 判断传入的key是不是桶中的第一个元素
if (first.hash == hash && // always check first node
((k = first.key) == key || (key != null && key.equals(k))))
return first;
// 传入的key不是桶中的第一个键值对，继续在桶中寻找
if ((e = first.next) != null) {
// 在树中get
if (first instanceof TreeNode)
return ((TreeNode<K,V>)first).getTreeNode(hash, key);
// 在链表中get
do {
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
return e;
} while ((e = e.next) != null);
}
}
return null;
}
线程安全性
HashMap是线程不安全的，其主要体现：
- 在jdk1.7中，在多线程环境下，扩容时会造成环形链
在对table进行扩容到newTable时，需要将原来数据转移到newTable中，在转移元素的过程中，使用的是头插法，也就是链表的顺序会翻转，这是造成死循环的主要原因。
死循环发生在HashMap的扩容函数中，根源在transfer函数中，jdk1.7中HashMap的transfer方法如下：
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; } } }
-
在jdk1.7中，在多线程环境下，扩容时会造成数据丢失。（原因同上）
-
在jdk1.8中，在多线程环境下，进行put操作时会发生数据覆盖的情况。
在jdk1.8中对HashMap进行了优化，在发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程的情况下仍然不安全。
发生数据覆盖的主要原因在于HashMap中的putVal方法中的这段代码：
if ((p = tab[i = (n - 1) & hash]) == null) tab[i] = newNode(hash, key, value, null);这是jdk1.8中HashMap中put操作的主函数， 注意这两行代码，如果没有hash碰撞则会直接插入元素。假设有线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，所以这线程A、B都会进入第一行代码中。此时可能存在一种情况，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，问题出现：线程A会把线程B插入的数据给覆盖，发生线程不安全。
- 在jdk1.8中，put和get并发时，可能导致get为null
场景：线程1执行put时，因为元素个数超出threshold而导致扩容，由于扩容时是会创建一个新的空的Node数组然后赋值给成员变量table的，如果线程2此时执行get，有可能导致这个问题。
resize方法的代码片段：
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap]; table = newTab;
HashMap与Hashtable的区别
- 线程是否安全：
HashMap是非线程安全的，HashTable是线程安全的,因为HashTable内部的方法基本都经过synchronized修饰。（如果你要保证线程安全的话就使用ConcurrentHashMap吧！）； - 效率： 因为线程安全的问题，
HashMap要比HashTable效率高一点。另外，HashTable基本被淘汰，不要在代码中使用它； - 对 Null key 和 Null value 的支持：
HashMap可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个；HashTable 不允许有 null 键和 null 值，否则会抛出NullPointerException。 - 初始容量大小和每次扩充容量大小的不同 ： ① 创建时如果不指定容量初始值，
Hashtable默认的初始大小为 11，之后每次扩充，容量变为原来的 2n+1。HashMap默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。② 创建时如果给定了容量初始值，那么 Hashtable 会直接使用你给定的大小，而HashMap会将其扩充为 2 的幂次方大小（HashMap中的tableSizeFor()方法保证，下面给出了源代码）。也就是说HashMap总是使用 2 的幂作为哈希表的大小,后面会介绍到为什么是 2 的幂次方。 - 底层数据结构： JDK1.8 以后的
HashMap在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。Hashtable 没有这样的机制。
