Java的HashMap原理总结（问答式学习）

HashMap原理详解，包括面试会问到的一些问题的总结。

Java重要知识点总结如下：

文章目录

• • • 1. 介绍下 HashMap 的底层数据结构
    • • 1.1 为什么要改成 数组+链表+红黑树？
      • 1.2 什么时候用链表？什么时候用红黑树？
      • 1.3 为什么链表转红黑树的阈值是8？
      • 1.4 为什么转回链表节点是用的6而不是复用8？
    • 2. 讲一下 HashMap 的重要属性
    • • 2.1 HashMap 有哪些重要属性？分别用于做什么的？
      • 2.2 threshold 除了用于存放扩容阈值还有其他作用吗？
      • 2.3 HashMap 的默认初始容量是多少？HashMap 的容量有什么限制吗？
      • 2.4 2的N次方是怎么算的？代码解释一下。
      • 2.5 HashMap 的容量必须是 2 的 N 次方，这是为什么？
      • 2.6 HashMap 的默认初始容量是 16，为什么是16而不是其他的？
      • 2.7 负载因子默认初始值为什么是0.75而不是其他的？
    • 3. HashMap 的插入（get）流程是怎么样的？
    • • 3.1 图里刚开始有个计算 key 的 hash 值，是怎么设计的？
      • 3.2 为什么要将 hashCode 的高16位参与运算？
    • 4. HashMap 的扩容（resize）流程介绍下？
    • • 4.1 红黑树和链表都是通过 e.hash & oldCap == 0 来定位在新表的索引位置，这是为什么？
    • 5. HashMap 的线程安全
    • • 5.1 HashMap 是线程安全的吗？
      • 5.2 介绍一下死循环问题？
      • 5.3 介绍一下数据覆盖问题？
    • 6. 总结下 JDK 1.8 主要进行了哪些优化？
    • 7. 除了 HashMap，还用过哪些 Map，在使用时怎么选择？

1. 介绍下 HashMap 的底层数据结构

我们现在用的都是 JDK 1.8，底层是由 数组+链表+红黑树 组成，如下图，而在 JDK 1.8 之前是由 数组+链表 组成。

1.1 为什么要改成 数组+链表+红黑树？

主要是为了提升在 hash 冲突严重时（链表过长）的查找性能，使用链表的查找性能是 O(n)，而使用红黑树是 O(logn)。

1.2 什么时候用链表？什么时候用红黑树？

• 对于插入，默认情况下是使用链表节点。

  当同一个索引位置的节点在新增后达到9个（阈值8）：如果此时数组长度大于等于 64，则会触发链表节点转红黑树节点（treeifyBin）；而如果数组长度小于64，则不会触发链表转红黑树，而是会进行扩容，因为此时的数据量还比较小。

• 对于移除，当同一个索引位置的节点在移除后达到 6 个，并且该索引位置的节点为红黑树节点，会触发红黑树节点转链表节点（untreeify）。

1.3 为什么链表转红黑树的阈值是8？

在进行方案设计时，必须考虑的两个很重要的因素是：时间和空间。对于 HashMap 也是同样的道理，简单来说，阈值为8是在时间和空间上权衡的结果。

红黑树节点大小约为链表节点的2倍，在节点太少时，红黑树的查找性能优势并不明显，付出2倍空间的代价不值得。

1.4 为什么转回链表节点是用的6而不是复用8？

如果我们设置节点多于8个转红黑树，少于8个就马上转链表，当节点个数在8徘徊时，就会频繁进行红黑树和链表的转换，造成性能的损耗。

2. 讲一下 HashMap 的重要属性

2.1 HashMap 有哪些重要属性？分别用于做什么的？

除了用来存储我们的节点 table 数组外，HashMap 还有以下几个重要属性：

1. size：HashMap 已经存储的节点个数；
2. threshold：扩容阈值，当 HashMap 的个数达到该值，触发扩容。
3. loadFactor：负载因子，扩容阈值 = 容量 * 负载因子。

2.2 threshold 除了用于存放扩容阈值还有其他作用吗？

在我们新建 HashMap 对象时， threshold 还会被用来存初始化时的容量。HashMap 直到我们第一次插入节点时，才会对 table 进行初始化，避免不必要的空间浪费。

2.3 HashMap 的默认初始容量是多少？HashMap 的容量有什么限制吗？

默认初始容量是16。HashMap 的容量必须是2的N次方，HashMap 会根据我们传入的容量计算一个大于等于该容量的最小的2的N次方，例如传 9，容量为16。

2.4 2的N次方是怎么算的？代码解释一下。

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

先不看第一行“int n = cap - 1”，先看下面的5行计算。

|=（或等于）：这个符号比较少见，但是“+=”应该都见过，看到这你应该明白了。例如：a |= b ，可以转成：a = a | b。

>>>（无符号右移）：例如 a >>> b 指的是将 a 向右移动 b 指定的位数，右移后左边空出的位用零来填充，移出右边的位被丢弃。

假设 n 的值为 0010 0001，则该计算如下图：

这5个公式会通过最高位的1，拿到2个1、4个1、8个1、16个1、32个1。当然，有多少个1，取决于我们的入参有多大，但我们肯定的是经过这5个计算，得到的值是一个低位全是1的值，最后返回的时候 +1，则会得到1个比n 大的 2 的N次方。

这时再看开头的 cap - 1 就很简单了，这是为了处理 cap 本身就是 2 的N次方的情况。

计算机底层是二进制的，移位和或运算是非常快的，所以这个方法的效率很高。

2.5 HashMap 的容量必须是 2 的 N 次方，这是为什么？

计算索引位置的公式为：(n - 1) & hash，当 n 为 2 的 N 次方时，n - 1 为低位全是 1 的值，此时任何值跟 n - 1 进行 & 运算的结果为该值的低 N 位，达到了和取模同样的效果，实现了均匀分布。实际上，这个设计就是基于公式：x mod 2^n = x & (2^n - 1)，因为 & 运算比 mod 具有更高的效率。

如下图，当 n 不为 2 的 N 次方时，hash 冲突的概率明显增大。

2.6 HashMap 的默认初始容量是 16，为什么是16而不是其他的？

16的原因主要是：16是2的N次方，并且是一个较合理的大小。如果用8或32，我觉得也是OK的。实际上，我们在新建 HashMap 时，最好是根据自己使用情况设置初始容量，这才是最合理的方案。

2.7 负载因子默认初始值为什么是0.75而不是其他的？

也是在时间和空间上权衡的结果。如果值较高，例如1，此时会减少空间开销，但是 hash 冲突的概率会增大，增加查找成本；而如果值较低，例如 0.5 ，此时 hash 冲突会降低，但是有一半的空间会被浪费，所以折衷考虑 0.75 似乎是一个合理的值。

3. HashMap 的插入（get）流程是怎么样的？

这里也可以参考：Java基础面试突击：七、说说HashMap原理吧？中对于put插入操作的分析。

3.1 图里刚开始有个计算 key 的 hash 值，是怎么设计的？

拿到 key 的 hashCode，并将 hashCode 的高16位和 hashCode 进行异或（XOR）运算，得到最终的 hash 值。

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

3.2 为什么要将 hashCode 的高16位参与运算？

主要是为了在 table 的长度较小的时候，让高位也参与运算，并且不会有太大的开销。

4. HashMap 的扩容（resize）流程介绍下？

4.1 红黑树和链表都是通过 e.hash & oldCap == 0 来定位在新表的索引位置，这是为什么？

请看对下面的例子。

扩容前 table 的容量为16，a 节点和 b 节点在扩容前处于同一索引位置。

扩容后，table 长度为32，新表的 n - 1 只比老表的 n - 1 在高位多了一个1（图中标红）。

因为 2 个节点在老表是同一个索引位置，因此计算新表的索引位置时，只取决于新表在高位多出来的这一位（图中标红），而这一位的值刚好等于 oldCap。

因为只取决于这一位，所以只会存在两种情况：

1. (e.hash & oldCap) == 0 ，则新表索引位置为“原索引位置” ；
2. (e.hash & oldCap) != 0，则新表索引位置为“原索引 + oldCap 位置”。

5. HashMap 的线程安全

5.1 HashMap 是线程安全的吗？

不是。HashMap 在并发下存在数据覆盖、遍历的同时进行修改会抛出 ConcurrentModificationException 异常等问题，JDK 1.8 之前还存在死循环问题。所以，我们应该使用ConcurrentHashMap。

HashMap的线程不安全体现在会造成死循环、数据丢失、数据覆盖这些问题。其中死循环和数据丢失是在JDK1.7中出现的问题，在JDK1.8中已经得到解决，然而1.8中仍会有数据覆盖这样的问题。

总结：

• JDK 1.7 中 HashMap 的线程不安全主要是发生在扩容函数中，即根源是在transfer函数中，会产生死循环和数据丢失的情况。
• JDK 1.8 中 HashMap 的线程不安全主要是发生在put操作，会发生数据覆盖的情况。

5.2 介绍一下死循环问题？

导致死循环的根本原因是 JDK 1.7 扩容采用的是“头插法”，会导致同一索引位置的节点在扩容后顺序反掉。而 JDK 1.8 之后采用的是“尾插法”，扩容后节点顺序不会反掉，不存在死循环问题。

5.3 介绍一下数据覆盖问题？

看一下下面这段JDK1.8中的put操作代码：

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) // 如果没有hash碰撞则直接插入元素
            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;
    }

（1）第六行代码是判断是否出现hash碰撞

• 假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，
• 当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入
• 然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。

（2）38行处有个++size

• 线程A、B，这两个线程同时进行put操作时，假设当前HashMap的zise大小为10，
• 当线程A执行到第38行代码时，从主内存中获得size的值为10后准备进行+1操作，但是由于时间片耗尽只好让出CPU，线程B快乐的拿到CPU还是从主内存中拿到size的值10进行+1操作，完成了put操作并将size=11写回主内存，
• 然后线程A再次拿到CPU并继续执行(此时size的值仍为10)，当执行完put操作后，还是将size=11写回内存，此时，线程A、B都执行了一次put操作，但是size的值只增加了1，所有说还是由于数据覆盖又导致了线程不安全。

6. 总结下 JDK 1.8 主要进行了哪些优化？

JDK 1.8 的主要优化刚才我们都聊过了，主要有以下几点：

1. 底层数据结构从“数组+链表”改成“数组+链表+红黑树”，主要是优化了 hash 冲突较严重时，链表过长的查找性能：O(n) ->
   O(logn)。
2. 计算 table 初始容量的方式发生了改变，老的方式是从1开始不断向左进行移位运算，直到找到大于等于入参容量的值；新的方式则是通过“5个移位+或等于运算”来计算。
3. 优化了 hash 值的计算方式，老的通过一顿瞎操作，新的只是简单的让高16位参与了运算。
4. 扩容时插入方式从“头插法”改成“尾插法”，避免了并发下的死循环。
5. 扩容时计算节点在新表的索引位置方式从“h & (length-1)”改成“hash & oldCap”，性能可能提升不大，但设计更巧妙、更优雅。

7. 除了 HashMap，还用过哪些 Map，在使用时怎么选择？

参考：

面试阿里，HashMap 这一篇就够了

Java基础面试突击

Java面试手册——高频问题总结（二）

JDK1.7和JDK1.8中HashMap为什么是线程不安全的？