Java后端面试高频问题：HashMap的底层原理

④如果该位置不为null,则判断key是否一样(hashCode和equals)，如果一样则直接覆盖value

⑤如果key不一样，则判断该元素是否为红黑树的节点，如果是，则直接在红黑树中插入键值对

⑥如果不是红黑树的节点，则就是链表，遍历这个链表执行插入操作，如果遍历过程中若发现key已存在，直接覆盖value即可。

如果链表的长度大于等于8且数组中元素数量大于等于阈值64，则将链表转化为红黑树，（先在链表中插入再进行判断）

如果链表的长度大于等于8且数组中元素数量小于阈值64，则先对数组进行扩容，不转化为红黑树。

⑦插入成功后，判断数组中元素的个数是否大于阈值64（threshold），超过了就对数组进行扩容操作。

get操作：

①计算key的hashCode的值，找到key在数组中的位置

②如果该位置为null，就直接返回null

③否则，根据equals()判断key与当前位置的值是否相等，如果相等就直接返回。

④如果不等，再判断当前元素是否为树节

必看视频！获取2024年最新Java开发全套学习资料 备注Java

点，如果是树节点就按红黑树进行查找。

⑤否则，按照链表的方式进行查找。

2.HashMap的扩容机制

3.HashMap的初始容量为什么是16？

1.减少hash碰撞 (2n ,16=24)

2.需要在效率和内存使用上做一个权衡。这个值既不能太小，也不能太大。

3.防止分配过小频繁扩容

4.防止分配过大浪费资源

4.HashMap为什么每次扩容都以2的整数次幂进行扩容？

因为Hashmap计算存储位置时，使用了(n - 1) & hash。只有当容量n为2的幂次方，n-1的二进制会全为1，位运算时可以充分散列，避免不必要的哈希冲突，所以扩容必须2倍就是为了维持容量始终为2的幂次方。

5.HashMap的扩容因子为什么是0.75？

当负载因子为1.0时，意味着只有当hashMap装满之后才会进行扩容，虽然空间利用率有大的提升，但是这就会导致大量的hash冲突，使得查询效率变低。

当负载因子为0.5或者更低的时候，hash冲突降低，查询效率提高，但是由于负载因子太低，导致原来只需要1M的空间存储信息，现在用了2M的空间。最终结果就是空间利用率太低。

负载因子是0.75的时候，这是时间和空间的权衡，空间利用率比较高，而且避免了相当多的Hash冲突，使得底层的链表或者是红黑树的高度也比较低，提升了空间效率。

6.HashMap扩容后会重新计算Hash值吗？

①JDK1.7

JDK1.7中，HashMap扩容后，所有的key需要重新计算hash值，然后再放入到新数组中相应的位置。

②JDK1.8

在JDK1.8中，HashMap在扩容时，需要先创建一个新数组，然后再将旧数组中的数据转移到新数组上来。

此时，旧数组中的数据就会根据（e.hash & oldCap），数据的hash值与扩容前数组的长度进行与操作，根据结果是否等于0，分为2类。

1.等于0时，该节点放在新数组时的位置等于其在旧数组中的位置。

2.不等于0时，该节点在新数组中的位置等于其在旧数组中的位置+旧数组的长度。

7.HashMap中当链表长度大于等于8时，会将链表转化为红黑树，为什么是8？

如果 hashCode 分布良好，也就是 hash 计算的结果离散好的话，那么红黑树这种形式是很少会被用到的，因为各个值都均匀分布，很少出现链表很长的情况。在理想情况下，链表长度符合泊松分布，各个长度的命中概率依次递减，当长度为 8 的时候，概率仅为 0.00000006。这是一个小于千万分之一的概率，通常我们的 Map 里面是不会存储这么多的数据的，所以通常情况下，并不会发生从链表向红黑树的转换。

通俗点讲就是put进去的key进行计算hashCode时 只要选择计算hash值的算法足够好(hash碰撞率极低)，从而遵循泊松分布，使得桶中挂载的bin的数量等于8的概率非常小，从而转换为红黑树的概率也小，反之则概率大。

8.HashMap为什么线程不安全？

1.在JDK1.7中，当并发执行扩容操作时会造成死循环和数据丢失的情况。

在JDK1.7中，在多线程情况下同时对数组进行扩容，需要将原来数据转移到新数组中，在转移元素的过程中使用的是头插法，会造成死循环。

2.在JDK1.8中，在并发执行put操作时会发生数据覆盖的情况。

如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，所以这线程A、B都会通过判断，将执行插入操作。

假设一种情况，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，问题出现：线程A会把线程B插入的数据给覆盖，发生线程不安全。

9.为什么HashMapJDK1.7中扩容时要采用头插法，JDK1.8又改为尾插法？

JDK1.7的HashMap在实现resize()时，新table[ ]的列表队头插入。

这样做的目的是：避免尾部遍历。

避免尾部遍历是为了避免在新列表插入数据时，遍历到队尾的位置。因为，直接插入的效率更高。

对resize()的设计来说，本来就是要创建一个新的table，列表的顺序不是很重要。但如果要确保插入队尾，还得遍历出链表的队尾位置，然后插入，是一种多余的损耗。

直接采用队头插入，会使得链表数据倒序。

JDK1.8采用尾插法是避免在多线程环境下扩容时采用头插法出现死循环的问题。

10.HashMap是如何解决哈希冲突的？

拉链法（链地址法）

为了解决碰撞，数组中的元素是单向链表类型。当链表长度大于等于8时，会将链表转换成红黑树提高性能。

而当链表长度小于等于6时，又会将红黑树转换回单向链表提高性能。

11.HashMap为什么使用红黑树而不是B树或平衡二叉树AVL或二叉查找树？

1.不使用二叉查找树

二叉排序树在极端情况下会出现线性结构。例如：二叉排序树左子树所有节点的值均小于根节点，如果我们添加的元素都比根节点小，会导致左子树线性增长，这样就失去了用树型结构替换链表的初衷，导致查询时间增长。所以这是不用二叉查找树的原因。

2.不使用平衡二叉树

平衡二叉树是严格的平衡树，红黑树是不严格平衡的树，平衡二叉树在插入或删除后维持平衡的开销要大于红黑树。

红黑树的虽然查询性能略低于平衡二叉树，但在插入和删除上性能要优于平衡二叉树。

选择红黑树是从功能、性能和开销上综合选择的结果。

3.不使用B树/B+树

HashMap本来是数组+链表的形式，链表由于其查找慢的特点，所以需要被查找效率更高的树结构来替换。

如果用B/B+树的话，在数据量不是很多的情况下，数据都会“挤在”一个结点里面，这个时候遍历效率就退化成了链表。

12.HashMap和Hashtable的异同？

①HashMap是⾮线程安全的，Hashtable是线程安全的。

Hashtable 内部的⽅法基本都经过 synchronized 修饰。

②因为线程安全的问题，HashMap要⽐Hashtable效率⾼⼀点。

③HashMap允许键和值是null，而Hashtable不允许键或值是null。

HashMap中，null 可以作为键，这样的键只有⼀个，可以有⼀个或多个键所对应的值为 null。

HashTable 中 put 进的键值只要有⼀个 null，直接抛出 NullPointerException。

④ Hashtable默认的初始⼤⼩为11，之后每次扩充，容量变为原来的2n+1。

HashMap默认的初始⼤⼩为16，之后每次扩充，容量变为原来的2倍。

⑤创建时如果给定了容量初始值，那么 Hashtable 会直接使⽤你给定的⼤⼩，⽽ HashMap 会将其扩充为2的幂次⽅⼤⼩。

⑥JDK1.8 以后的 HashMap 在解决哈希冲突时当链表⻓度⼤于等于8时，将链表转化为红⿊树，以减少搜索时间。Hashtable没有这样的机制。

Hashtable的底层，是以数组+链表的形式来存储。

⑦HashMap的父类是AbstractMap，Hashtable的父类是Dictionary

相同点：都实现了Map接口，都存储k-v键值对。

13.HashMap和HashSet的区别？

HashSet 底层就是基于 HashMap 实现的。（HashSet 的源码⾮常⾮常少，因为除了 clone() 、 writeObject() 、 readObject() 是 HashSet ⾃⼰不得不实现之外，其他⽅法都是直接调⽤ HashMap 中的⽅法）

1.HashMap实现了Map接口，HashSet实现了Set接口

2.HashMap存储键值对，HashSet存储对象

3.HashMap调用put()向map中添加元素，HashSet调用add()方法向Set中添加元素。

4.HashMap使用键key计算hashCode的值，HashSet使用对象来计算hashCode的值，在hashCode相等的情况下，使用equals()方法来判断对象的相等性。

最后

既已说到spring cloud alibaba，那对于整个微服务架构，如果想要进一步地向上提升自己，到底应该掌握哪些核心技能呢？

就个人而言，对于整个微服务架构，像RPC、Dubbo、Spring Boot、Spring Cloud Alibaba、Docker、kubernetes、Spring Cloud Netflix、Service Mesh等这些都是最最核心的知识，架构师必经之路！下图，是自绘的微服务架构路线体系大纲，如果有还不知道自己该掌握些啥技术的朋友，可根据小编手绘的大纲进行一个参考。

如果觉得图片不够清晰，也可来找小编分享原件的xmind文档！

且除此份微服务体系大纲外，我也有整理与其每个专题核心知识点对应的最强学习笔记：

• 出神入化——SpringCloudAlibaba.pdf

• SpringCloud微服务架构笔记（一）.pdf

• SpringCloud微服务架构笔记（二）.pdf

• SpringCloud微服务架构笔记（三）.pdf

• SpringCloud微服务架构笔记（四）.pdf

• Dubbo框架RPC实现原理.pdf

• Dubbo最新全面深度解读.pdf

• Spring Boot学习教程.pdf

• SpringBoo核心宝典.pdf

• 第一本Docker书-完整版.pdf

• 使用SpringCloud和Docker实战微服务.pdf

• K8S(kubernetes)学习指南.pdf

另外，如果不知道从何下手开始学习呢，小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！

ud微服务架构笔记（四）.pdf

• Dubbo框架RPC实现原理.pdf

• Dubbo最新全面深度解读.pdf

• Spring Boot学习教程.pdf

• SpringBoo核心宝典.pdf

• 第一本Docker书-完整版.pdf

• 使用SpringCloud和Docker实战微服务.pdf

• K8S(kubernetes)学习指南.pdf

[外链图片转存中…(img-ih9DVfB3-1716455469854)]

另外，如果不知道从何下手开始学习呢，小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！

[外链图片转存中…(img-mM9ZJCi0-1716455469855)]