之前虽然很频繁使用java的hashmap，但一直都是纯用，至于里面怎么实现的，一直都是糊里糊涂的。今年4月份跳槽找工作，大概看了一下HashMap的源码，在面试过程中也被多位面试官问到HashMap的相关问题，有些问题也没回答出来。本来几个月前就想着写一篇相关源码解析的博客（主要是加深自己的理解），一直拖到现在，接下来就跟我一起看下HashMap的实现（基于jdk8）。
HashMap实现了Map，Cloneable，Serializable三个接口，Map定义了必要方法，Cloneable意味着HashMap是可被clone的，Serializable以为这HashMap可以被序列化。但是AbstractMap是什么鬼？打开AbstractMap的源码就会发现注释第一句就告诉你，AbstractMap给Map提供了一个骨架，事实上它实现了Map的几乎所有的方法，除了entrySet()。AbstractMap既然实现了Map接口，那为什么HashMap还要实现Map接口？ 好吧关于这个问题，有人说是个作者的一个失误，见StackOverflow，我觉得这个说法站不住脚啊，如果是个失误，为啥到jdk10还没被修复，跳过这个问题。
打开HashMap的源码，跳过一堆注释，最先看到的是几个常量，这几个常量是缺省时的默认值，非常重要，它们决定这HashMap在使用过程中内部的发生的一些行为，我们挨个看一下。
long serialVersionUID = 362498820763181265L; //用来在序列化时校验用的
int DEFAULT_INITIAL_CAPACITY = 1 << 4; //缺省时HashMap的初始容量 16
int MAXIMUM_CAPACITY = 1 << 30; //最大容量
float DEFAULT_LOAD_FACTOR = 0.75f; //缺省时的默认负载因子，当map中的存储量占总容量的75%以上，hashmap就会把自身容量扩张一倍
int TREEIFY_THRESHOLD = 8; // 触发树化阀值
int MIN_TREEIFY_CAPACITY = 64; // 真正树化阀值
了解一个类，应该最先从其构造函数开始，HashMap可选的构造参数并不多，最核心的就这一个构造方法，如下。
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);
}
这个构造函数做的事很简单，只是初始化了两个值，一个是负载因子，如果用户用自定义切校验通过就会抛弃默认的0.75负载因子。另一个是threshold，loadFactor是个负载因子的比例，threhold才是实际值，HashMap会根据threhold具体值来做resize()。这里我们顺带看下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;
}
这个函数就就是找到最小那个比cap大的2^n。
如上所示，其实构造函数什么都没做。内部空间初始化也没做，那什么时候做呢？其实HashMap存储初始化的动作都是插入值的时候做的，这样设计有个好处，可以避免你虽然new了一个HashMap，但写入数据导致的资源浪费。
接下来我们看下HashMap内部是怎么存储数据的。HashMap中有个内部静态类Node<K,V>，这个用来存储数据的实体，看下代码。
static class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
V value;
Node<K,V> next;
/**
* 省略一些简单方法
*/
}
这个类里除了用户可见的K，V之外，还额外存储了hash值，这个hash值就是K的hash值，单独存下是为了优化，不需要每次用到的时候都计算K的hash值。next这个就是单链表的next指针了，HashMap解决hash值冲突的方式就是是开一条单链表，Jdk8之后就不仅仅是单链表了，后续我们会详解介绍。
HashMap中有个Node<K,V>[] table; 这个数组就是所有数据存储的地方了。它会在第一次插入数据时发现table为null候才被初始化。
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
else {
Node<K,V> e; K k;
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) {
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
break;
}
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;
if (++size > threshold)
resize();
afterNodeInsertion(evict);
return null;
}
既然贴出来了这段代码了，我们就先来看下这段，再看HashMap的resize()。最开始就检查table，如果table是null，就用resize做初始化，然后在安插新节点。如果遇到hash值碰撞，如果发现是同一个key，就覆盖。否在有两种情况，要么单链表插入，要么红黑树插入，一个HashMap的内部存储可能长这个样子，树化后的某些单链表可能会变成一颗树(示意图，并不代表真实情况)。
这里就遇到jdk对于hashmap指针碰撞的优化了，如果过多的K,V都有同样的hash值，就会变成一条非常长的链，增删查的性能就非常低了。所以jdk8在链表长度达到8的时候就会触发链表的树话，把单链表变成一个红黑树，可以把各种操作的时间复杂度从O(n)降低到O(logn)。
事实上，链表长度到8，虽然会触发树化，但并不一定会树化，而是会优先选择resize()，只有链表长度达到64才会树化，其实我并不理解为什么要再设个64的阀值才会树化，可能是在节点树少的时候，树的平局操作时间复杂度不会比单链表的优太多吧。
我觉得在HashMap中resize()是HashMap的核心，也是很多问题的根源。虽然resize()对用户不可见，但它是保证HashMap性能最重要的一般，当然它也是HashMap并发问题的罪魁祸首。
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;
}
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);
}
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) {
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;
do {
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
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;
}
大体上就是新建一个newTab，是原来table大小的两倍，然后把原有数据做放到newTab中。先不管Tree是怎么裂变的（还没搞懂），我们来看下单链表怎么裂变的。 这里直接把一个单链表裂变成了两个。在odltab中第j位置的单链表，裂变成两条单链表，一条放newtab中j位置，另一条放newtab中i+oldcap的位置，每个j都是这么做的，就是这么神奇， 很长时间我一直没理解这么简单处理，如何保证在同一条链表中的节点都有相同的hash值？
其实也很简单，就是按hash值第oldCap那位0和1做了区分。因为我们cap每次都是以2为系数增长的，然后按cap-1为掩码来计算位置的，当容量扩大一倍后，只会有一部分最高位是1的才需要移动。比如hash值最后4位都是是0101的节点，其在newtab中新的位置要么是10101，要么是00101。
今天最后一个问题，为什么HashMap不是线程安全的？ 罪魁祸首还是resize()，如果在多线程插入的情况下，多个线程有可能同时执行resize()，多线程操作一个单链表，很大几率会出现数据一致性的问题，甚至有可能会在链表中出现环。
