Java集合------HashMap 源码详细分析（JDK1.8）

HashMap 源码详细分析（JDK1.8）

一、概述

​ 本篇文章对我们开发中常用的一个集合类 - HashMap来详细的分析一下。HashMap最早出现在JDK1.2中，底层基于散列算法实现，HashMap允许null键和null值，在计算键的哈希值时，null的哈希值为0。HashMap并不保证键值对的顺序，这意味着在进行某些操作后，键值对的顺序可能会发生变化。另外HashMap是非线程安全类，在多线程环境下可能会存在问题。

二、原理

​ 在JDK1.8之前，HashMap是使用拉链式的散列算法，在JDK1.8中引入了红黑树优化过长的链表。数据结构示意图如下：

三、源码分析

​ 与JDK1.7相比，JDK1.8对于HashMap进行了一些优化。比如引入了红黑树解决链表过长效率低的问题，重写resize方法等。

一、成员变量

static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; //默认初始化大小 16 
static final int MAXIMUM_CAPACITY = 1 << 30;		//最大容量 1073741824
static final float DEFAULT_LOAD_FACTOR = 0.75f;     //负载系数 0.75 用于扩容
static final int TREEIFY_THRESHOLD = 8;				//链表长度大于该参数转红黑树
static final int UNTREEIFY_THRESHOLD = 6;			//当树的节点数小于等于该参数转成链表
static final int MIN_TREEIFY_CAPACITY = 64;			// 当桶数组容量小于该值时，优先进行扩容，而不是树化
transient Node<K,V>[] table;	//这是一个Node类型的数组（也有称作Hash桶）
static final Entry<?,?>[] EMPTY_TABLE = {
    
    };         //初始化的默认数组
transient int size;     //HashMap中元素的数量
int threshold;          //判断是否需要调整HashMap的容量的阀值 
final float loadFactor; //负载系数
transient int modCount; //表示当前HashMap修改次数

二、构造方法分析

​ HashMap的构造方法有四个。一般都是初始化一些重要的变量，如loadFactor和threshold。底层的数据结构则是延迟到插入键值对的时候在进行初始化。

HashMap想关构造方法如下：

//这个构造方法只是初始化了负载系数为0.75，然后其他的参数都是默认的
public HashMap() {
    
    
    this.loadFactor = DEFAULT_LOAD_FACTOR; 
}
//初始化了HashMap的初始容量
public HashMap(int initialCapacity) {
    
    
    this(initialCapacity, DEFAULT_LOAD_FACTOR);
}
//初始化了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;
    //看到这里是否会有疑惑? threshold 不是阀值吗？不是该等于tableSizeFor(initialCapacity) * loadFactor才对吗？ 慢慢往下看，扩容机制里解答
    this.threshold = tableSizeFor(initialCapacity);
}
//将另一个HashMap中的映射拷贝到自己的存储结构中，一般不常用。
public HashMap(Map<? extends K, ? extends V> m) {
    
    
    this.loadFactor = DEFAULT_LOAD_FACTOR;
    putMapEntries(m, false);
} 

看到这里我们发现除了我们不常用的第四种初始化以外，其他三种我们应该还是多多少少用过的，这里面我们来看看threshold是怎么初始化的。
源码如下：

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;
}

如果对位运算不熟悉的同学看到上面的代码可能有点难受，也不知道上面写的这是干啥的，那我们就来一起分析分析吧，来画一画就好了。
最后还要加个1，然后就会变为0001 000 --> 16，这样应该就比较容易理解这是用来找到大于等于传入值cap的最小2次幂。
说完了初始阈值的计算过程，再来说说负载因子（loadFactor）。对于 HashMap 来说，负载因子是一个很重要的参数，该参数反应了 HashMap 桶数组的使用情况（假设键值对节点均匀分布在桶数组中）。通过调节负载因子，可使 HashMap 时间和空间复杂度上有不同的表现。当我们调低负载因子时，HashMap 所能容纳的键值对数量变少。扩容时，重新将键值对存储新的桶数组里，键的键之间产生的碰撞会下降，链表长度变短。此时，HashMap 的增删改查等操作的效率将会变高，这里是典型的拿空间换时间。相反，如果增加负载因子（负载因子可以大于1），HashMap 所能容纳的键值对数量变多，空间利用率高，但碰撞率也高。这意味着链表长度变长，效率也随之降低，这种情况是拿时间换空间。至于负载因子怎么调节，这个看使用场景了。一般情况下，我们用默认值就可以了。

三、查找

HashMap 的查找操作比较简单，原理即先定位键值对所在的桶的位置，然后再对链表或红黑树进行查找。通过这两步即可完成查找，该操作相关代码如下：

public V get(Object key) {
    
    
    Node<K,V> e;
    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;
    //1.查看键值对所在的位置
    if ((tab = table) != null && (n = tab.length) > 0 &&
        (first = tab[(n - 1) & hash]) != null) {
    
    
        //检查第一个节点是否就是我们要找的键，是就返回
        if (first.hash == hash && // always check first node
            ((k = first.key) == key || (key != null && key.equals(k))))
            return first;
        if ((e = first.next) != null) {
    
    
            //如果first是TreeNode类型，则调用红黑树查找方法
            if (first instanceof TreeNode)
                return ((TreeNode<K,V>)first).getTreeNode(hash, key);
            //对链表进行查找
            do {
    
    
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    return e;
            } while ((e = e.next) != null);
        }
    }
    return null;
}

在查找键值对所在位置的时候，大家可能对first = tab[(n - 1) & hash])有点疑惑。疑惑为什么(n - 1) & hash就是桶所在的位置。这里简单解释一下，HashMap 中桶数组的大小 length 总是2的幂，此时(n - 1) & hash 等价于对 length 取余。但取余的计算效率没有位运算高，所以也是一个小的优化。举个例子说明一下吧，假设 hash = 185，n = 16。
计算过程示意图如下：

			hash:1011 1001
			n-1 :0000 1111  &
------------------------------
  (n - 1) & hash:0000 1001
这就相当于该键是放在下标为9的位置

在上面源码中，除了查找相关逻辑，还有一个计算 hash 的方法。这个方法源码如下：

static final int hash(Object key) {
    
    
	int h;
	return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

看这个方法的逻辑好像是通过位运算重新计算 hash，那么这里为什么要这样做呢？为什么不直接用键的 hashCode 方法产生的 hash 呢？
这样做有两个好处，我来简单解释一下。我们再看一下上面求余的计算图，图中的 hash 是由键的 hashCode 产生。计算余数时，由于 n 比较小，hash 只有低4位参与了计算，高位的计算可以认为是无效的。这样导致了计算结果只与低位信息有关，高位数据没发挥作用。为了处理这个缺陷，我们可以上图中的 hash 高4位数据与低4位数据进行异或运算，即 hash ^ (hash >>> 4)。通过这种方式，让高位数据与低位数据进行异或，以此加大低位信息的随机性，变相的让高位数据参与到计算中。此时的计算过程如下：

			hash:1011 1001
	  hash >>> 4:0000 1011 ^
---------------------------------
 hash^(hash>>>4):1011 0010
             n-1:0000 1111 &
---------------------------------
      (n-1)&hash:0000 0010

在 Java 中，hashCode 方法产生的 hash 是 int 类型，32 位宽。前16位为高位，后16位为低位，所以要右移16位。
上面所说的是重新计算 hash 的一个好处，除此之外，重新计算 hash 的另一个好处是可以增加 hash 的复杂度。当我们覆写 hashCode 方法时，可能会写出分布性不佳的 hashCode 方法，进而导致 hash 的冲突率比较高。通过移位和异或运算，可以让 hash 变得更复杂，进而影响 hash 的分布性。这也就是为什么 HashMap 不直接使用键对象原始 hash 的原因了。

四、遍历

​ 和查找查找一样，遍历操作也是大家使用频率比较高的一个操作。对于 遍历 HashMap，我们一般都会用下面的两种方式：

for (Object key : hashMap.keySet()) {
    
    
    Object value = hashMap.get(key);
}

for (Map.Entry<Object, Object> objectObjectEntry : hashMap.entrySet()) {
    
    
    Object key = objectObjectEntry.getKey();
    Object value = objectObjectEntry.getValue();
}

​ 从上面代码片段中可以看出，大家一般都是对 HashMap 的 key 集合或 Entry 集合进行遍历。上面代码片段中用 foreach 遍历 keySet 方法产生的集合，在编译时会转换成用迭代器遍历，等价于：

Set keys = hashMap.keySet();
Iterator ite = keys.iterator();
while(ite.hasNext()){
    
    
    Object key = ite.next();
    Object value = hashMap.get(key);
}

​ 大家在遍历 HashMap 的过程中会发现，多次对 HashMap 进行遍历时，遍历结果顺序都是一致的。但这个顺序和插入的顺序一般都是不一致的。产生上述行为的原因是怎样的呢。我先把遍历相关的代码贴出来：

public Set<K> keySet() {
    
    
    Set<K> ks = keySet;
    if (ks == null) {
    
    
        ks = new KeySet();
        keySet = ks;
    }
    return ks;
}
//键的集合
final class KeySet extends AbstractSet<K> {
    
    
    public final int size()                 {
    
     return size; }
    public final void clear()               {
    
     HashMap.this.clear(); }
    public final Iterator<K> iterator()     {
    
     return new KeyIterator(); }
    public final boolean contains(Object o) {
    
     return containsKey(o); }
    public final boolean remove(Object key) {
    
    
        return removeNode(hash(key), key, null, false, true) != null;
    }
    // 省略。。。
}

// 迭代器
final class KeyIterator extends HashIterator implements Iterator<K> {
    
    
    public final K next() {
    
     return nextNode().key; }
}

abstract class HashIterator {
    
    
    Node<K,V> next;        // next entry to return
    Node<K,V> current;     // current entry
    int expectedModCount;  // for fast-fail
    int index;             // current slot

    HashIterator() {
    
    
        expectedModCount = modCount;
        Node<K,V>[] t = table;
        current = next = null;
        index = 0;
        if (t != null && size > 0) {
    
     // advance to first entry
            // 寻找第一个包含链表节点引用的桶
            do {
    
    } while (index < t.length && (next = t[index++]) == null);
        }
    }

    public final boolean hasNext() {
    
    
        return next != null;
    }

    final Node<K,V> nextNode() {
    
    
        Node<K,V>[] t;
        Node<K,V> e = next;
        if (modCount != expectedModCount)
            throw new ConcurrentModificationException();
        if (e == null)
            throw new NoSuchElementException();
        if ((next = (current = e).next) == null && (t = table) != null) {
    
    
            //寻找下一个包含链表节点引用的桶
            do {
    
    } while (index < t.length && (next = t[index++]) == null);
        }
        return e;
    }
	//省略。。。
}

​ 如上面的源码，遍历所有的键时，首先要获取键集合KeySet对象，然后再通过 KeySet 的迭代器进行遍历。KeyIterator 类继承自HashIterator类，核心逻辑也封装在 HashIterator 类中。HashIterator 的逻辑并不复杂，在初始化时，HashIterator 先从桶数组中找到包含链表节点引用的桶。然后对这个桶指向的链表进行遍历。遍历完成后，再继续寻找下一个包含链表节点引用的桶，找到继续遍历。找不到，则结束遍历。

​ 抛两个问题给大家。在 JDK 1.8 版本中，为了避免过长的链表对 HashMap 性能的影响，特地引入了红黑树优化性能。但在上面的源码中并没有发现红黑树遍历的相关逻辑，这是为什么呢？对于被转换成红黑树的链表该如何遍历呢？大家可以先想想，本文后续会有答案。

五、插入

一、插入逻辑分析

通过前面的分析，大家对 HashMap 低层的数据结构应该了然于心了。即使我不说，大家也应该能知道 HashMap 的插入流程是什么样的了。首先肯定是先定位要插入的键值对属于哪个桶，定位到桶后，再判断桶是否为空。如果为空，则将键值对存入即可。如果不为空，则需将键值对接在链表最后一个位置，或者更新键值对。这就是 HashMap 的插入流程，是不是觉得很简单。当然，大家先别高兴。这只是一个简化版的插入流程，真正的插入流程要复杂不少。首先 HashMap 是变长集合，所以需要考虑扩容的问题。其次，在 JDK 1.8 中，HashMap 引入了红黑树优化过长链表，这里还要考虑多长的链表需要进行优化，优化过程又是怎样的问题。引入这里两个问题后，大家会发现原本简单的操作，现在略显复杂了。

现在我将先分析插入操作的源码，扩容、树化（链表转为红黑树，下同）以及其他和树结构相关的操作，随后将在独立的两小结中进行分析。接下来，先来看一下插入操作的源码：

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;
    // 判断是否初始化hash桶 没初始化就进行初始化
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
    // 如果hash桶中不包含该键值对节点，就直接新建一个节点然后引入即可
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    else {
    
    
        Node<K,V> e; K k;
        // 如果键的值以及节点 hash 等于链表中的第一个键值对节点时，则将 e 指向该键值对
        if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))
            e = p;
        // 如果桶中的引用类型为 TreeNode，则调用红黑树的插入方法
        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;
                }
                // 条件为 true，表示当前链表包含要插入的键值对，终止遍历
                if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
                    break;
                p = e;
            }
        }
        // 判断要插入的键值对是否存在 HashMap 中
        if (e != null) {
    
     // existing mapping for key
            V oldValue = e.value; //获取原本的值
            // onlyIfAbsent 表示是否仅在 oldValue 为 null 的情况下更新键值对的值，onlyIfAbsent一般为false
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
    // 键值对数量超过阈值时，则进行扩容
    if (++size > threshold)
        resize();
    afterNodeInsertion(evict);
    return null;
}

​ 插入操作的入口方法是 put(K,V)，但核心逻辑在V putVal(int, K, V, boolean, boolean) 方法中。putVal 方法主要做了这么几件事情：

• 当桶数组 table 为空时，通过扩容的方式初始化 table
• 查找要插入的键值对是否已经存在，存在的话根据条件判断是否用新值替换旧值
• 如果不存在，则将键值对链入链表中，并根据链表长度决定是否将链表转为红黑树
• 判断键值对数量是否大于阈值，大于的话则进行扩容操作

二、扩容机制

​ 在 Java 中，数组的长度是固定的，这意味着数组只能存储固定量的数据。但在开发的过程中，很多时候我们无法知道该建多大的数组合适。建小了不够用，建大了用不完，造成浪费。如果我们能实现一种变长的数组，并按需分配空间就好了。好在，我们不用自己实现变长数组，Java 集合框架已经实现了变长的数据结构。比如 ArrayList 和 HashMap。对于这类基于数组的变长数据结构，扩容是一个非常重要的操作。下面就来聊聊 HashMap 的扩容机制。

​ 在 HashMap 中，桶数组的长度均是2的幂，阈值大小为桶数组长度与负载因子的乘积。当 HashMap 中的键值对数量超过阈值时，进行扩容。

​ HashMap 的扩容机制与其他变长集合的套路不太一样，HashMap 按当前桶数组长度的2倍进行扩容，阈值也变为原来的2倍（如果计算过程中，阈值溢出归零，则按阈值公式重新计算）。扩容之后，要重新计算键值对的位置，并把它们移动到合适的位置上去。以上就是 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;
    // 当table不为null时 代表已经初始化了的
    if (oldCap > 0) {
    
    
       	// 当table容量超过容量的最大值 不在扩容
        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
        //初始化时，将threshold的值赋给newCap，这个threshold就是在初始化时暂时用来存储了initialCapacity
        newCap = oldThr;
    else {
    
     // zero initial threshold signifies using defaults
        //容量默认为16，阈值为默认容量与默认负载因子乘积12
        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;
    //初始化hash桶
    @SuppressWarnings({
    
    "rawtypes","unchecked"})
    Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
    table = newTab;
    //如果旧的hash桶中有数据就遍历映射到心的hash桶中
    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;
}

以上就是扩容的源码，有点长慢慢看他的逻辑。其实这个扩容也是做了三件事，分别是：

• 计算新桶数组的容量 newCap 和新阈值 newThr
• 根据计算出的 newCap 创建新的桶数组，桶数组 table 也是在这里进行初始化的
• 将键值对节点重新映射到新的桶数组里。如果节点是 TreeNode 类型，则需要拆分红黑树。如果是普通节点，则节点按原顺序进行分组。

​ 前两个我就不讲了，自己可以看着源码多想想，主要讲一下最后的将键值对节点怎么重新映射到新的hash桶中的过程。

​ 在 JDK 1.8 中，重新映射节点需要考虑节点类型。对于树形节点，需先拆分红黑树再映射。对于链表类型节点，则需先对链表进行分组，然后再映射。需要的注意的是，分组后，组内节点相对位置保持不变。关于红黑树拆分的逻辑将会放在下一小节说明，先来看看链表是怎样进行分组映射的。

​ 我们都知道往底层数据结构中插入节点时，一般都是先通过模运算计算桶位置，接着把节点放入桶中即可。事实上，我们可以把重新映射看做插入操作。在 JDK 1.7 中，也确实是这样做的。但在 JDK 1.8 中，则对这个过程进行了一定的优化，逻辑上要稍微复杂一些。在详细分析前，我们先来回顾一下 hash 求余的过程：

​ 上图中，桶数组大小 n = 16，hash1 与 hash2 不相等。但因为只有后4位参与求余，所以结果相等。当桶数组扩容后，n 由16变成了32，对上面的 hash 值重新进行映射：

​ 扩容后，参与模运算的位数由4位变为了5位。由于两个 hash 第5位的值是不一样，所以两个 hash 算出的结果也不一样。上面的计算过程并不难理解，继续往下分析。

假设我们上图的桶数组进行扩容，扩容后容量 n = 16，重新映射过程如下:

依次遍历链表，并计算节点 hash & oldCap 的值。如下图所示

​ 如果值为0，将 loHead 和 loTail 指向这个节点。如果后面还有节点 hash & oldCap 为0的话，则将节点链入 loHead 指向的链表中，并将 loTail 指向该节点。如果值为非0的话，则让 hiHead 和 hiTail 指向该节点。完成遍历后，可能会得到两条链表，此时就完成了链表分组,最后再将这两条链接存放到相应的桶中，完成扩容。如下图：

​ 从上图可以发现，重新映射后，两条链表中的节点顺序并未发生变化，还是保持了扩容前的顺序。以上就是 JDK 1.8 中 HashMap 扩容的代码讲解。另外再补充一下，JDK 1.8 版本下 HashMap 扩容效率要高于之前版本。如果大家看过 JDK 1.7 的源码会发现，JDK 1.7 为了防止因 hash 碰撞引发的拒绝服务攻击，在计算 hash 过程中引入随机种子。以增强 hash 的随机性，使得键值对均匀分布在桶数组中。在扩容过程中，相关方法会根据容量判断是否需要生成新的随机种子，并重新计算所有节点的 hash。而在 JDK 1.8 中，则通过引入红黑树替代了该种方式。从而避免了多次计算 hash 的操作，提高了扩容效率。

三、链表树化、红黑树链化与拆分

一、链表树化

​ JDK 1.8 对 HashMap 实现进行了改进。最大的改进莫过于在引入了红黑树处理频繁的碰撞，代码复杂度也随之上升。比如，以前只需实现一套针对链表操作的方法即可。而引入红黑树后，需要另外实现红黑树相关的操作。红黑树是一种自平衡的二叉查找树，本身就比较复杂。本篇文章中并不打算对红黑树展开介绍，本文仅会介绍链表树化需要注意的地方。至于红黑树详细的介绍，如果大家有兴趣，可以参考我的另一篇文章 - 红黑树详细分析

代码如下：

static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
    
    
    TreeNode<K,V> parent;  // red-black tree links
    TreeNode<K,V> left;
    TreeNode<K,V> right;
    TreeNode<K,V> prev;    // needed to unlink next upon deletion
    boolean red;
    TreeNode(int hash, K key, V val, Node<K,V> next) {
    
    
        super(hash, key, val, next);
    }
}
//将普通节点链表转为红黑树
final void treeifyBin(Node<K,V>[] tab, int hash) {
    
    
    int n, index; Node<K,V> e;
    // hash桶容量小于64的时候优先扩容，而不是树化
    if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)
        resize();
    else if ((e = tab[index = (n - 1) & hash]) != null) {
    
    
        // 将普通节点链表转为树形节点链表
        TreeNode<K,V> hd = null, tl = null;
        do {
    
    
            TreeNode<K,V> p = replacementTreeNode(e, null);
            if (tl == null)
                hd = p;
            else {
    
    
                p.prev = tl;
                tl.next = p;
            }
            tl = p;
        } while ((e = e.next) != null);
        if ((tab[index] = hd) != null)
            // 将树形节点链表转为红黑树
            hd.treeify(tab);
    }
}

TreeNode<K,V> replacementTreeNode(Node<K,V> p, Node<K,V> next) {
    
    
    return new TreeNode<>(p.hash, p.key, p.value, next);
}

在扩容过程中，树化要满足两个条件：

1. 链表长度大于等于 TREEIFY_THRESHOLD —> 8
2. 桶数组容量大于等于 MIN_TREEIFY_CAPACITY —> 64

第一个条件比较好理解，这里就不说了。这里来说说加入第二个条件的原因，个人觉得原因如下：

​ 当桶数组容量比较小时，键值对节点 hash 的碰撞率可能会比较高，进而导致链表长度较长。这个时候应该优先扩容，而不是立马树化。毕竟高碰撞率是因为桶数组容量较小引起的，这个是主因。容量小时，优先扩容可以避免一些列的不必要的树化过程。同时，桶容量较小时，扩容会比较频繁，扩容时需要拆分红黑树并重新映射。所以在桶容量比较小的情况下，将长链表转成红黑树是一件吃力不讨好的事。

​ 回到上面的源码中，我们继续看一下 treeifyBin 方法。该方法主要的作用是将普通链表转成为由 TreeNode 型节点组成的链表，并在最后调用 treeify 是将该链表转为红黑树。TreeNode 继承自 Node 类，所以 TreeNode 仍然包含 next 引用，原链表的节点顺序最终通过 next 引用被保存下来。我们假设树化前，链表结构如下：

​ HashMap 在设计之初，并没有考虑到以后会引入红黑树进行优化。所以并没有像 TreeMap 那样，要求键类实现 comparable 接口或提供相应的比较器。但由于树化过程需要比较两个键对象的大小，在键类没有实现 comparable 接口的情况下，怎么比较键与键之间的大小了就成了一个棘手的问题。为了解决这个问题，HashMap 是做了三步处理，确保可以比较出两个键的大小，代码如下：

//转为红黑树
final void treeify(Node<K,V>[] tab) {
    
    
    TreeNode<K,V> root = null;
    for (TreeNode<K,V> x = this, next; x != null; x = next) {
    
    
        next = (TreeNode<K,V>)x.next;
        x.left = x.right = null;
        //当根节点为null是先添加为根节点
        if (root == null) {
    
    
            x.parent = null;
            x.red = false;
            root = x;
        }
        else {
    
    
            K k = x.key;
            int h = x.hash;
            Class<?> kc = null;
            for (TreeNode<K,V> p = root;;) {
    
    
                int dir, ph;
                K pk = p.key;
                //比较两个键之间的hash大小
                if ((ph = p.hash) > h)
                    dir = -1;
                else if (ph < h)
                    dir = 1;
                //检测键类是否实现了 Comparable 接口，如果实现调用 compareTo 方法进行比较
                else if ((kc == null &&
                          (kc = comparableClassFor(k)) == null) ||
                         (dir = compareComparables(kc, k, pk)) == 0)
                    //如果仍未比较出大小，就需要进行仲裁了
                    dir = tieBreakOrder(k, pk);

                TreeNode<K,V> xp = p;
                //根据上面的比较dir<=0就在left
                if ((p = (dir <= 0) ? p.left : p.right) == null) {
    
    
                    x.parent = xp;
                    if (dir <= 0)
                        xp.left = x;
                    else
                        xp.right = x;
                    root = balanceInsertion(root, x);
                    break;
                }
            }
        }
    }
    moveRootToFront(tab, root);
}

通过上面的代码比较，最终就可以比较出孰大孰小。比较出大小后就可以构造红黑树了，最终构造出的红黑树如下：

橙色的箭头表示 TreeNode 的 next 引用。由于空间有限，prev 引用未画出。可以看出，链表转成红黑树后，原链表的顺序仍然会被引用仍被保留了（红黑树的根节点会被移动到链表的第一位），我们仍然可以按遍历链表的方式去遍历上面的红黑树。这样的结构为后面红黑树的切分以及红黑树转成链表做好了铺垫，我们继续往下分析。

二、红黑树拆分

​ 扩容后，普通节点需要重新映射，红黑树节点也不例外。按照一般的思路，我们可以先把红黑树转成链表，之后再重新映射链表即可。这种处理方式是大家比较容易想到的，但这样做会损失一定的效率。不同于上面的处理方式，HashMap 实现的思路则是上好佳。如上节所说，在将普通链表转成红黑树时，HashMap 通过两个额外的引用 next 和 prev 保留了原链表的节点顺序。这样再对红黑树进行重新映射时，完全可以按照映射链表的方式进行。这样就避免了将红黑树转成链表后再进行映射，无形中提高了效率。

代码如下：

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;
    //前面讲过ThreeNode保留了next所以这里可以继续使用next来进行遍历
    //遍历然后对红黑树进行分组，与之前链表分组类似
    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)
                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) {
    
    
        //如果lohead不为空且长度小于等于6，就将其转为链表
        if (lc <= UNTREEIFY_THRESHOLD)
            tab[index] = loHead.untreeify(map);
        else {
    
    
            tab[index] = loHead;
            //hihead如果为null证明红黑树并未被分割，也就不用重新树化
            if (hiHead != null) // (else is already treeified)
                loHead.treeify(tab);
        }
    }
    if (hiHead != null) {
    
    
        if (hc <= UNTREEIFY_THRESHOLD)
            tab[index + bit] = hiHead.untreeify(map);
        else {
    
    
            tab[index + bit] = hiHead;
            if (loHead != null)
                hiHead.treeify(tab);
        }
    }
}

​ 从源码上可以看得出，重新映射红黑树的逻辑和重新映射链表的逻辑基本一致。不同的地方在于，重新映射后，会将红黑树拆分成两条由 TreeNode 组成的链表。如果链表长度小于 UNTREEIFY_THRESHOLD，则将链表转换成普通链表。否则根据条件重新将 TreeNode 链表树化。举个例子说明一下，假设扩容后，重新映射上图的红黑树，映射结果如下：

三、红黑树链化

​ 前面说过，红黑树中仍然保留了原链表节点顺序。有了这个前提，再将红黑树转成链表就简单多了，仅需将 TreeNode 链表转成 Node 类型的链表即可。相关代码如下：

final Node<K,V> untreeify(HashMap<K,V> map) {
    
    
    Node<K,V> hd = null, tl = null;
    //遍历ThreeNode链表，并用Node替换
    for (Node<K,V> q = this; q != null; q = q.next) {
    
    
        //替换节点类型
        Node<K,V> p = map.replacementNode(q, null);
        if (tl == null)
            hd = p;
        else
            tl.next = p;
        tl = p;
    }
    return hd;
}
Node<K,V> replacementNode(Node<K,V> p, Node<K,V> next) {
    
    
    return new Node<>(p.hash, p.key, p.value, next);
}

六、删除

HashMap 的删除操作并不复杂，仅需三个步骤即可完成。

• 第一步是定位桶位置，
• 第二步遍历链表并找到键值相等的节点，
• 第三步删除节点。

相关源码如下：

public V remove(Object key) {
    
    
    Node<K,V> e;
    return (e = removeNode(hash(key), key, null, false, true)) == null ? null : e.value;
}

final Node<K,V> removeNode(int hash, Object key, Object value, boolean matchValue, boolean movable) {
    
    
    Node<K,V>[] tab; Node<K,V> p; int n, index;
    // 1.找到桶的位置
    if ((tab = table) != null && (n = tab.length) > 0 && (p = tab[index = (n - 1) & hash]) != null) {
    
    
        Node<K,V> node = null, e; K k; V v;
        // 2.hash相同 key相同 则将 node 指向该节点
        if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))
            node = p;
        else if ((e = p.next) != null) {
    
    
            if (p instanceof TreeNode)
                // 2.如果是 TreeNode 类型，调用红黑树的查找逻辑定位该节点
                node = ((TreeNode<K,V>)p).getTreeNode(hash, key);
            else {
    
    
                // 2.遍历链表，找到待删除节点
                do {
    
    
                    if (e.hash == hash &&
                        ((k = e.key) == key ||
                         (key != null && key.equals(k)))) {
    
    
                        node = e;
                        break;
                    }
                    p = e;
                } while ((e = e.next) != null);
            }
        }
        // 3. 删除节点，并修复链表或红黑树
        if (node != null && (!matchValue || (v = node.value) == value || (value != null && value.equals(v)))) {
    
    
            if (node instanceof TreeNode)
                ((TreeNode<K,V>)node).removeTreeNode(this, tab, movable);
            else if (node == p)
                tab[index] = node.next;
            else
                p.next = node.next;
            ++modCount;
            --size;
            afterNodeRemoval(node);
            return node;
        }
    }
    return null;
}

七、细节分析

被 transient 所修饰 table 变量

​ 如果大家细心阅读 HashMap 的源码，会发现桶数组 table 被申明为 transient。transient 表示易变的意思，在 Java 中，被该关键字修饰的变量不会被默认的序列化机制序列化。我们再回到源码中，考虑一个问题：桶数组 table 是 HashMap 底层重要的数据结构，不序列化的话，别人还怎么还原呢？

​ 这里简单说明一下吧，HashMap 并没有使用默认的序列化机制，而是通过实现readObject/writeObject两个方法自定义了序列化的内容。这样做是有原因的，试问一句，HashMap 中存储的内容是什么？不用说，大家也知道是键值对。所以只要我们把键值对序列化了，我们就可以根据键值对数据重建 HashMap。有的朋友可能会想，序列化 table 不是可以一步到位，后面直接还原不就行了吗？这样一想，倒也是合理。但序列化 talbe 存在着两个问题：

1. table 多数情况下是无法被存满的，序列化未使用的部分，浪费空间
2. 同一个键值对在不同 JVM 下，所处的桶位置可能是不同的，在不同的 JVM 下反序列化 table 可能会发生错误。

​ 以上两个问题中，第一个问题比较好理解，第二个问题解释一下。HashMap 的等方法第一步就是根据 hash 找到键所在的桶位置，但如果键没有覆写 hashCode 方法，计算 hash 时最终调用 Object 中的 hashCode 方法。但 Object 中的 hashCode 方法是 native 型的，不同的 JVM 下，可能会有不同的实现，产生的 hash 可能也是不一样的。也就是说同一个键在不同平台下可能会产生不同的 hash，此时再对在同一个 table 继续操作，就会出现问题。

八、多线程下可能会出现的问题

一、数据丢失

​ 在下面源码注释的位置，线程已经拿到了头结点和hash桶，若此时cpu时间让出，而在该线程重新获得cpu时间前，这个hash桶已经发被其他线程更改过，那么在该线程重入后，他将持有一个过期的桶和头结点，并且覆盖之前其他线程的记录，造成了数据丢失。

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;
    //在这里时已经拿到了头节点---1
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    //省略。。。
}

二、size（）不准确

/**
 * The number of key-value mappings contained in this map.
 */
transient int size;

我们看到，size只是用了transient关键字修饰（不参与序列化）,也就是说，在各个线程中的size副本不会及时同步，在多个线程操作的时候，size将会被覆盖。
--------------最后感谢大家的阅读，愿大家技术越来越流弊！--------------

--------------也希望大家给我点支持，谢谢各位大佬了！！！--------------