参考资料：
《Java 8系列之重新认识HashMap》（作者为美团技术团队）
《Java8的HashMap源码分析》（JKD版本为1.7）
《为什么Java8中HashMap链表使用红黑树而不是AVL树》
《JDK1.8以后的hashmap为什么在链表长度为8的时候变为红黑树》
《HashMap中红黑树TreeNode的split()方法源码分析》
写在开头：本文为个人学习笔记，内容比较随意，夹杂个人理解，如有错误，欢迎指正。
前言
周末专门学习了下java8中的HashMap，下面对几个重要知识点做下总结归纳。本文省略了对HashMap的大体介绍，直接解释java8中的难点，因此阅读此文需要对HashMap有基本的理解，下面先重点记忆下HashMap的重要知识点
（1）HashMap初始容量16，每次扩容都是2倍，引申得到HashMap的容量必为2的n次幂
（2）负载因子为0.75，该值过大，会导致冲突的几率加大，频繁扩容，过小可能导致空间的浪费
（3）java8中链表长度大于8，且数组长度大于等于64时会转换为红黑树
目录
（2）put 和 get 并发时会导致 get 到 null
（1）为什么使用的是红黑树而不是AVL树或者别的什么数据结构
一、hash及索引下标的计算
我们先从jdk1.7中的hash计算开始讲起：
/**
* 返回数组下标
*/
static int indexFor(int h, int length) {
return h & (length-1);
}上文是根据已经计算出的hash值得到索引下标的代码。
length为数组的长度，恒为2的n次幂，因此length-1的二进制表示，除最高位为0外，低位全部为1。假设这里length为8，有2个hash分别为3和15要计算索引，于是有：
length-1 0000 0111
3 0000 0011
--------------------------
& 0000 0011
=3
length-1 0000 0111
15 0000 1111
--------------------------
& 0000 0111
=7我们看到，对于一个长度为length的数组，假设其为2的n次幂，length-1的结果就是n个1，其与任何数（如上图中的3、15）相与的结果都是保留其低位，间接性的实现了取模的效果。但是我们为什么不直接取模呢，这是因为&运算直接使用二进制位计算，能更快的达到效果。由于数组长度恒为2的n次幂，所以该结论必然存在。这也是我们每次扩容都是2倍的原因之一。
在java8中我们采用同样的方法来计算索引下标，只不过计算过程放到了put方法当中。
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);理解了上面这一点，我们再来看java8中的hash计算：
static final int hash(Object key) {
int h;
// h = key.hashCode() 为第一步 取hashCode值
// h ^ (h >>> 16) 为第二步 高位参与运算
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}这里对于key.hashcode将其本身与自己无符号右移16位的结果相异或，参考下图。
把哈希值右移 16 位，也就正好是自己长度的一半，之后与原哈希值做异或运算，这样就混合了原哈希值中的高位和低位，不仅保留了低位的信息，还夹杂了高位的特征，大大增加了随机性。
二、put方法流程
下图来自美团技术团队，可以清晰的看出整个流程（注意：下图中链表转换红黑树的条件少了一个节点数大于64，即完整的转换条件为链表长度大于8，且数组长度大于等于64）
（1）判断键值对数组table[i]是否为空或为null，否则执行resize()进行扩容；
（2）根据键值key计算hash值得到插入的数组索引i，如果table[i]==null，直接新建节点添加，转向（6），如果table[i]不为空，转向（3）；
（3）判断table[i]的首个元素是否和key一样，如果相同直接覆盖value，否则转向（4），这里的相同指的是hashCode以及equals；
（4）判断table[i] 是否为treeNode，即table[i] 是否是红黑树，如果是红黑树，则直接在树中插入键值对，否则转向（5）；
（5）遍历table[i]，判断链表长度是否大于8且数组长度大于64，满足这两个条件则转为红黑树。在红黑树中执行插入操作，否则进行链表的插入操作；遍历过程中若发现key已经存在直接覆盖value即可；
（6）插入成功后，判断实际存在的键值对数量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;
}三、扩容
依然还是从1.7的扩容源码入手，我们可以看到，内部会新建一个数组，然后通过transfer方法
将原数组中的键值对依次加入到新数组中。
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);//修改阈值
}
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);
}
}
} 我们可以看到，transfer方法会遍历旧数组，对于每个数组元素，会遍历其中的每个节点，并重新计算其hash值，然后使用头插法将其插入到新的索引位置上。
假设现在size=2， 所以key = 3、7、5，扩容的过程如下。
我们发现一个有趣的现象，7、3都刚好移动了2位，刚好是扩容的大小，即2位，这里我们再结合二进制位来看下：
由于扩容直接加了1倍，因此相当于length-1原来的最右侧的0变为了1，因此大于length-1的值，同一的位置下的1也被释放，相当于在原位置+原容量的位置。
因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”
这个设计非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。
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
// 使用无参构造方法生成的HashMap在这里初始化table
// 在真正使用到的时候才初始化，避免了空间的浪费
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 { // preserve order
// 链表优化重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;
}从源码中我们看到，1.8中采用了尾插法来实现迁移。
四、线程安全
众所周知，HashMap是线程不安全的，虽然有modCount来记录HashMap内部结构发生变化的次数，但却无法保证值的变化的安全。内部结构发生变化指的是结构发生变化，例如put新键值对，但是某个key对应的value值被覆盖不属于结构变化。
这里插个题外话，1.7版本有个著名的结构变化的风险，就是头插法带来的死循环问题，不过这个问题由于1.8采取了新的扩容方法而修复了，所以这里不做额外赘述，有兴趣的可以自行了解。
（1）多线程下 put 会导致元素丢失
多线程同时执行 put 操作时，如果计算出来的索引位置是相同的，那会造成前一个 key 被后一个 key 覆盖，从而导致元素的丢失。
（2）put 和 get 并发时会导致 get 到 null
线程 A 执行put时，因为元素个数超出阈值而出现扩容，线程B 此时执行get。当线程 A 执行完 table = newTab 之后，线程 B 中的 table 此时也发生了变化，此时去 get 的时候就会 get 到 null 了，因为元素还没有迁移完成。
五、为什么使用红黑树
这个问题还可以细分为2个问题
（1）为什么使用的是红黑树而不是AVL树或者别的什么数据结构
因为虽然两者都能实现快速的查找（O(logN)），但是AVL追求的是绝对的平衡，这就导致每次增删操作都会引起AVL树结构的变化，需要O(logN)的时间来旋转，重建结构。而红黑树追求的是相对的平衡，最多两次旋转使其达到平衡（尽管可能需要检查O(logN)节点以确定旋转的位置）。旋转本身是O（1）操作，因为你只是移动指针。
（2）为什么数组大于64且链表大于8时才优化
简单来说，就是树的节点大小是正常大小的2倍，很消耗内存，因此进行了一定的平衡。在hash散列较为均匀的时候是不会利用到红黑树的。
六、红黑树与链表的互相转化
1、由链表转为红黑树
链表长度大于8，且数组长度大于等于64时会转换为红黑树
有的文章里说等于7即可，实际上是错的
遍历过程中p从第一个节点遍历到最后一个节点，但由于binCount是从0开始计数，所以在做树化判断时binCount的值等于 链表长度 - 1（注意此时的链表长度没有算新插入的节点）
但此时链表新插入了一个节点
p.next = newNode(hash, key, value, null);所以链表树化的那一刻，它的真实长度是binCount（7）+1（新增节点）+1=>TREEIFY_THRESHOLD（8），即：链表长度大于8时，treeifyBin()方法被调用
2、由于红黑树转为链表
（1）删除节点时触发
删除节点时，判断为红黑树，则会判断根节点、左右孩子以及左孙子节点是否为空，满足其一则认为红黑树中节点较少，已没有维持红黑树的必要，转换为链表。
if (root == null || root.right == null ||
(rl = root.left) == null || rl.left == null) {
tab[index] = first.untreeify(map); // too small
return;
}
（2）扩容时触发
第一步：遍历当前下标中所有节点，通过(hash & bit)得出的高位为0还是1得到2条链表。
第二步：
1、低位链表不为null，且长度小于等于6时，低位链表开始去树化操作。
2、低位链长度大于6，且高位链表不为空，低位链表进行树化
3、高位链表不为null，且长度小于等于6时，高位链表开始去树化操作。
4、高位链长度大于6，且低位链表不为空，高位链进行树化
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;
if ((e.hash & bit) == 0) {//区分树链表的高低位
if ((e.prev = loTail) == null)//低位尾部标记为null,表示还未开始处理，此时e是第一个要处理的低位树链表
//节点，故e.prev等于loTail都等于null
loHead = e;//低位树链表的第一个树链表节点
else
loTail.next = e;
loTail = e;
++lc;//低位树链表元素个数计数
}
else {
if ((e.prev = hiTail) == null)
hiHead = e;//高位树链表的第一个树链表节点
else
hiTail.next = e;
hiTail = e;
++hc;//高位树链表元素个数计数
}
}
if (loHead != null) {//低位树链表不为null
if (lc <= UNTREEIFY_THRESHOLD)//低位树链表元素个数若小于等于6
tab[index] = loHead.untreeify(map);//开始去树化操作(就是将元素TreeNode节点都转换成Node节点)
else {
tab[index] = loHead;
if (hiHead != null) // (else is already treeified) //若高位数链表头节点为空，说明还没有处理完高位
//，还不能进行树化操作
loHead.treeify(tab);//低位树链表元素个数若大于6且高位树链表头节点不等于null，开始将低位树链表真
//正树化成红黑树(前面都只是挂着TreeNode的名号，但实际只是链表结构，还没包含红黑树的特性，
//在这里才赋予了它红黑树的特性)
}
}
if (hiHead != null) {//高位树链表不为null
if (hc <= UNTREEIFY_THRESHOLD)//高位树链表元素个数若小于等于6
tab[index + bit] = hiHead.untreeify(map);//开始去树化操作(就是将元素TreeNode节点都转换成Node节点)
else {
tab[index + bit] = hiHead;
if (loHead != null) //若低位数链表头节点为空，说明还没有处理完低位，还不能进行树化操作
hiHead.treeify(tab);//高位树链表元素个数若大于6且低位树链表头节点不等于null，
//开始将高位树链表真正树化成红黑树
}
}
}
补充：
为什么负载因子是0.75？
很多文章中都提到了泊松分布和二项分布，但说实话，本人概率论学的实在不咋地，只能简要的概括为性能的折中考虑。
如果有想了解的朋友可以参考这边文章《HashMap的负载因子为什么是0.75》
443
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
