刚刚经历过秋招，看了大量的面经，HashMap是面试的高频问题，这里将HashMap常见面试题总结了一下，并根据被问到的频率大致做了一个标注。问题后面的星数量越多表示，在面试中出现的频率越高，搞懂下面所有的问题，就再也不用担心面试官问你HashMap了。

微信搜索公众号路人zhang，回复面试手册，领取本文档PDF版及更多面试资料。

推荐阅读：一文搞懂所有Java基础知识面试题

Map集合

HashMap在JDK1.7和JDK1.8中有哪些不同？HashMap的底层实现　＊＊＊

• JDK1.7的底层数据结构(数组+链表)

在这里插入图片描述

• JDK1.8的底层数据结构(数组+链表)

在这里插入图片描述

• JDK1.7的Hash函数

  static final int hash(int h){
    h ^= (h >>> 20) ^ (h >>>12);
      return h^(h >>> 7) ^ (h >>> 4);
  }
  

• JDK1.8的Hash函数

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

  JDK1.8的函数经过了一次异或一次位运算一共两次扰动，而JDK1.7经过了四次位运算五次异或一共九次扰动。这里简单解释下JDK1.8的hash函数，面试经常问这个，两次扰动分别是key.hashCode()与key.hashCode()右移16位进行异或。这样做的目的是，高16位不变，低16位与高16位进行异或操作，进而减少碰撞的发生，高低Bit都参与到Hash的计算。如何不进行扰动处理，因为hash值有32位，直接对数组的长度求余，起作用只是hash值的几个低位。

HashMap在JDK1.7和JDK1.8中有哪些不同点：

HashMap 的长度为什么是2的幂次方　＊＊＊

因为HashMap是通过key的hash值来确定存储的位置，但Hash值的范围是-2147483648到2147483647，不可能建立一个这么大的数组来覆盖所有hash值。所以在计算完hash值后会对数组的长度进行取余操作，如果数组的长度是2的幂次方，(length - 1)&hash等同于hash%length，可以用(length - 1)&hash这种位运算来代替%取余的操作进而提高性能。

HashMap的put方法的具体流程？　＊＊

HashMap的主要流程可以看下面这个流程图，逻辑非常清晰。

在这里插入图片描述

HashMap的扩容操作是怎么实现的？　＊＊＊

• 初始值为16，负载因子为0.75，阈值为负载因子*容量

• resize()方法是在hashmap中的键值对大于阀值时或者初始化时，就调用resize()方法进行扩容。

• 每次扩容，容量都是之前的两倍

• 扩容时有个判断e.hash & oldCap是否为零，也就是相当于hash值对数组长度的取余操作，若等于0，则位置不变，若等于1，位置变为原位置加旧容量。

  源码如下：

  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;  //没有超过最大值就变为原来的2倍
      }
      else if (oldThr > 0) 
          newCap = oldThr;
  
      else {               
          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 { 
                      Node<K,V> loHead = null, loTail = null;//loHead,loTail 代表扩容后在原位置
                      Node<K,V> hiHead = null, hiTail = null;//hiHead,hiTail 代表扩容后在原位置+旧容量
                      Node<K,V> next;
                      do {             
                          next = e.next;
                          if ((e.hash & oldCap) == 0) { //判断是否为零，为零赋值到loHead，不为零赋值到hiHead
                              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;   //loHead放在原位置
                      }
                      if (hiTail != null) {
                          hiTail.next = null;
                          newTab[j + oldCap] = hiHead;  //hiHead放在原位置+旧容量
                      }
                  }
              }
          }
      }
      return newTab;
  }
  
  

HashMap默认加载因子为什么选择0.75？

这个主要是考虑空间利用率和查询成本的一个折中。如果加载因子过高，空间利用率提高，但是会使得哈希冲突的概率增加；如果加载因子过低，会频繁扩容，哈希冲突概率降低，但是会使得空间利用率变低。具体为什么是0.75，不是0.74或0.76，这是一个基于数学分析（泊松分布）和行业规定一起得到的一个结论。

为什么要将链表中转红黑树的阈值设为8？为什么不一开始直接使用红黑树？

可能有很多人会问，既然红黑树性能这么好，为什么不一开始直接使用红黑树，而是先用链表，链表长度大于8时，才转换为红红黑树。

• 因为红黑树的节点所占的空间是普通链表节点的两倍，但查找的时间复杂度低，所以只有当节点特别多时，红黑树的优点才能体现出来。至于为什么是8，是通过数据分析统计出来的一个结果，链表长度到达8的概率是很低的，综合链表和红黑树的性能优缺点考虑将大于8的链表转化为红黑树。
• 链表转化为红黑树除了链表长度大于8，还要HashMap中的数组长度大于64。也就是如果HashMap长度小于64，链表长度大于8是不会转化为红黑树的，而是直接扩容。

HashMap是怎么解决哈希冲突的？　＊＊＊

哈希冲突：hashMap在存储元素时会先计算key的hash值来确定存储位置，因为key的hash值计算最后有个对数组长度取余的操作，所以即使不同的key也可能计算出相同的hash值，这样就引起了hash冲突。hashMap的底层结构中的链表/红黑树就是用来解决这个问题的。

HashMap中的哈希冲突解决方式可以主要从三方面考虑（以JDK1.8为背景）

• 拉链法

  HasMap中的数据结构为数组+链表/红黑树，当不同的key计算出的hash值相同时，就用链表的形式将Node结点（冲突的key及key对应的value）挂在数组后面。

• hash函数

  key的hash值经过两次扰动，key的hashCode值与key的hashCode值的右移16位进行异或，然后对数组的长度取余（实际为了提高性能用的是位运算，但目的和取余一样），这样做可以让hashCode取值出的高位也参与运算，进一步降低hash冲突的概率，使得数据分布更平均。

• 红黑树

  在拉链法中，如果hash冲突特别严重，则会导致数组上挂的链表长度过长，性能变差，因此在链表长度大于8时，将链表转化为红黑树，可以提高遍历链表的速度。

HashMap为什么不直接使用hashCode()处理后的哈希值直接作为table的下标？　＊＊＊

hashCode()处理后的哈希值范围太大，不可能在内存建立这么大的数组。

能否使用任何类作为 Map 的 key？　＊＊＊

可以，但要注意以下两点：

• 如果类重写了 equals()方法，也应该重写hashCode()方法。
• 最好定义key类是不可变的，这样key对应的hashCode()值可以被缓存起来，性能更好，这也是为什么String特别适合作为HashMap的key。

为什么HashMap中String、Integer这样的包装类适合作为Key？　＊＊＊

• 这些包装类都是final修饰，是不可变性的， 保证了key的不可更改性，不会出现放入和获取时哈希值不同的情况。
• 它们内部已经重写过hashcode(),equal()等方法。

如果使用Object作为HashMap的Key，应该怎么办呢？　＊＊

• 重写hashCode()方法，因为需要计算hash值确定存储位置
• 重写equals()方法，因为需要保证key的唯一性。

HashMap 多线程导致死循环问题　＊＊＊

由于JDK1.7的hashMap遇到hash冲突采用的是头插法，在多线程情况下会存在死循环问题，但JDK1.8已经改成了尾插法，不存在这个问题了。但需要注意的是JDK1.8中的HashMap仍然是不安全的，在多线程情况下使用仍然会出现线程安全问题。基本上面试时说到这里既可以了，具体流程用口述是很难说清的，感兴趣的可以看这篇文章。HASHMAP的死循环

ConcurrentHashMap 底层具体实现知道吗？　＊＊

• JDK1.7

  在JDK1.7中，ConcurrentHashMap采用Segment数组 + HashEntry数组的方式进行实现。Segment实现了ReentrantLock，所以Segment有锁的性质，HashEntry用于存储键值对。一个ConcurrentHashMap包含着一个Segment数组，一个Segment包含着一个HashEntry数组，HashEntry是一个链表结构，如果要获取HashEntry中的元素，要先获得Segment的锁。

在这里插入图片描述

• JDK1.8

  在JDK1.8中，不在是Segment+HashEntry的结构了，而是和HashMap类似的结构，Node数组+链表/红黑树，采用CAS+synchronized来保证线程安全。当链表长度大于8，链表转化为红黑树。在JDK1.8中synchronized只锁链表或红黑树的头节点，是一种相比于segment更为细粒度的锁，锁的竞争变小，所以效率更高。

在这里插入图片描述

总结一下：

• JDK1.7底层是ReentrantLock+Segment+HashEntry，JDK1.8底层是synchronized+CAS+链表/红黑树
• JDK1.7采用的是分段锁，同时锁住几个HashEntry，JDK1.8锁的是Node节点，只要没有发生哈希冲突，就不会产生锁的竞争。所以JDK1.8相比于JDK1.7提供了一种粒度更小的锁，减少了锁的竞争，提高了ConcurrentHashMap的并发能力。

HashTable的底层实现知道吗？　＊＊

HashTable的底层数据结构是数组+链表，链表主要是为了解决哈希冲突，并且整个数组都是synchronized修饰的，所以HashTable是线程安全的，但锁的粒度太大，锁的竞争非常激烈，效率很低。

在这里插入图片描述

HashMap、ConcurrentHashMap及Hashtable 的区别　＊＊＊

Map的常用方法　＊＊

这些常用方法是需要背下来的，虽然面试用不上，但是笔试或者面试写算法题时会经常用到。