【面试题】HashMap常见面试题-追魂16问

‍博主主页：爪哇贡尘拾Miraitow
传作时间：2022年2月8日
内容介绍： HashMap常见面试题
参考资料：VX公众号：路人zhang
⏳简言以励：列位看官，且将新火试新茶，诗酒趁年华
创作不易，内容较多有问题希望能够不吝赐教
 欢迎点赞  收藏 ⭐留言 

HashMap常见面试题

1.HashMap在JDK1.7和JDK1.8中有哪些不同？HashMap的底层实现 2、HashMap怎么设置初始值大小的 ？ 3、为什么使用扰动函数？4、扰动函数是怎么实现的？ 5、为什么要将key.hashCode()右移16位？6、HashMap 的长度为什么是2的幂次方 7、HashMap的put方法的具体流程？8、HashMap的扩容操作是怎么实现的？9、HashMap默认加载因子为什么选择0.75？10、 为什么要将链表中转红黑树的阈值设为8？为什么不一开始直接使用红黑树？ 11、HashMap是怎么解决哈希冲突的？ 12、HashMap为什么不直接使用hashCode()处理后的哈希值直接作为table的下标？13、能否使用任何类作为 Map 的 key？14、HashMap 多线程导致死循环问题15、树化阈值是8，红黑树转链表阈值为6为什么不是别的？ 16、 为什么使用红黑树，不是平衡二叉树？

我们经常会使用HashMap，在问到有关它的信息的时候，大家多多少少都能说一些内容，但是说的可能是会模棱两可，还是没能理解透彻，所以大家可以先看之前的源码分析Java-集合框架-哈希表-HashMap-源码分析，再来看这写面试题，一定会有收获

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

JDK1.7的Hash函数

JDK1.8的Hash函数

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

2、HashMap怎么设置初始值大小的 ？

一般如果new HashMap() 不传值，默认大小是16，负载因子是0.75（当我们去添加元素的时候才会初始化）， 如果自己传入初始大小为k，初始化大小为大于等于k的2的整数次方，例如如果传10，大小为16。

cap=10
n=10 -1=9;
0b1001 | 0b0100=>0b1101
0b1101 | 0b0011=>0b1111
0b1111 | 0b0000=>0b1111
0b1111 | 0b0000=>0b1111
0b1111 | 0b0000=>0b1111
ob1111=>转为十进制是15
return 16

3、为什么使用扰动函数？

以初始长度16为例，16-1=15。2进制表示是00000000 00000000 00001111。和某散列值做“与”操作如下，结果就是截取了最低的四位值。

这样就算散列值分布再松散，要是只取最后几位的话，碰撞也会很严重。如果散列本身做得不好，分布上成等差数列的漏洞，恰好使最后几个低位呈现规律性重复，则碰撞会更严重。

4、扰动函数是怎么实现的？

答：由扰动函数源码可知，会有以下步骤：

①使用key.hashCode()计算hash值并赋值给变量h；②将h向右移动16位；③将变量h和向右移16位的h做异或运算（二进制位相同为0，不同为1）。此时得到经过扰动函数后的hansh值。

图解如下：

5、为什么要将key.hashCode()右移16位？

右移16位正好为32bit的一半，自己的高半区和低半区做异或，是为了混合原始哈希吗的高位和低位，来加大低位的随机性。而且混合后的低位掺杂了高位的部分特征，使高位的信息也被保留下来

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

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

7、HashMap的put方法的具体流程？

对以上流程不熟悉的可以看看上一篇的源码分析：
HashMap的源码分析

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

初始值为16，负载因子为0.75，阈值为负载因子*容量resize() 方法是在 hashmap 中的键值对大于阀值时或者初始化时，就调用 resize() 方法进行扩容。每次扩容，容量都是之前的两倍扩容时有个判断e.hash & oldCap是否为零，HashMap 是成倍扩容，这样原来位置的链表的节点们，会被分散到新的 table 的两个位置中去
通过 e.hash & oldCap 计算，根据结果分到高位、和低位的位置中。
如果结果为 0 时，则放置到低位
如果结果非 1 时，则放置到高位

我们看上述个人所作图片：

在未扩容前，我们的hash&(length-1)=1111=>15都放在15的位置因为15的二进制为1111，哈希相与的结果为15,说明我们的hash的后五位可能为01111也可能为11111,当我们扩容以后，我们的length-1也就是31为11111,所以之前的两种情况和扩容后的length-1相与结果有两种，一种还是在15的位置，另一种是在31的位置，所以当我们的如果结果为0 时，则放置到低位链如果结果非 1 时，则放置到高位链

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

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

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

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

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

11、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时，将链表转化为红黑树，可以提高遍历链表的速度。

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

这里其实之前已经提过了

hashCode() 处理后的哈希值范围太大(-2147483648到2147483647大约40亿的映射空间)，不可能在内存建立这么大的数组

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

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

如果类重写了equals()方法，也应该重写hashCode() 方法。最好定义 key 类是不可变的，这样 key 对应的 hashCode() 值可以被缓存起来，性能更好，这也是为什么 String 特别适合作为 HashMap 的 keyString、Integer 这些包装类都是final修饰，是不可变性的， 保证了 key 的不可更改性，不会出现放入和获取时哈希值不同的情况。
它们内部已经重写过 hashcode() , equal() 等方法。 14、HashMap 多线程导致死循环问题

由于JDK1.7的 hashMap 遇到hash冲突采用的是头插法，在多线程情况下会存在死循环问题，但 JDK1.8已经改成了尾插法(七上八下)，不存在这个问题了。但需要注意的是JDK1.8中的 HashMap 仍然是不安全的，在多线程情况下使用仍然会出现线程安全问题。所以在并发的情况，发生扩容时，可能会产生循环链表，在执行get的时候，会触发死循环，引起CPU的100%问题，所以一定要避免在并发环境下使用HashMap。

曾经有人把这个问题报·给了Sun，不过Sun不认为这是一个bug，因为在HashMap本来就不支持多线程使用，要并发就ConcurrentHashmap。
老生常谈，HashMap的死循环

15、树化阈值是8，红黑树转链表阈值为6为什么不是别的？

面试官: 为什么是8，不是16，32甚至是7 ？又为什么红黑树转链表的阈值是6，不是8了呢？

因为经过计算，在hash函数设计合理的情况下，发生hash碰撞8次的几率为百万分之6，因为8够用了，至于为什么转回来是6，因为如果hash碰撞次数在8附近徘徊，会一直发生链表和红黑树的互相转化，为了预防这种情况的发生。
为什么不用二叉树/平衡树呢？
红黑树本质上是一种二叉查找树，为了保持平衡，它又在二叉查找树的基础上增加了一些规则：

16、 为什么使用红黑树，不是平衡二叉树？

红黑树：

每个节点要么是红色，要么是黑色；
根节点永远是黑色的； 所有的叶子节点都是是黑色的
每个红色节点的两个子节点一定都是黑色； 从任一节点到其子树中每个叶子节点的路径都包含相同数量的黑色节点；

为什么不用二叉树？

红黑树 是一种平衡的二叉树，插入、删除、查找的最坏时间复杂度都为 O(logn)，避免了二叉树最坏情况下的O(n)时间复杂度。

为什么不用平衡二叉树?

平衡二叉树 是比红黑树更严格的平衡树，为了保持平衡，需要旋转的次数更多，也就是说平衡二叉树保持平衡的效率更低，所以平衡二叉树插入和删除的效率比红黑树要低。

对于红黑树的了解
以下图片来源于processon