Java常见问题之HashMap扩容、树化、死链

最新推荐文章于 2025-03-26 11:14:05 发布
最新推荐文章于 2025-03-26 11:14:05 发布
阅读量732 收藏 1
点赞数
文章标签： 程序人生 后端 java hash
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Java_LingFeng/article/details/127883288
版权
本文详细探讨了Java HashMap中的关键问题，包括如何解决Hash冲突，何时进行扩容和树化，以及为什么选择特定的阈值。文章还分析了1.7和1.8版本的区别，如头插法导致的并发扩容死链问题，以及1.8版本引入的红黑树优化。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

写在前边

  • HashMap属于比较常用的数据结构了，面试过程中也经常会被问到，本篇就知识点，展开问答式分析，重点聊聊hash冲突、扩容死链、容量为2的n次方、1.7和1.8之间的区别等问题~

如何解决Hash冲突问题

扩容

条件

  1. 链表长度超过8

  2. 元素个数超过数组个数的75%

树化规则

条件

  1. 链表长度超过8

  2. 此时看看数组长度是否超过64，超过就进行树化，否则只是单纯扩容

为什么需要树化

其实一般正常的元素，都是不会超过阈值的，只有插入一堆重复的元素，hash值一样，才可能达到阈值，这个简称Dos攻击 而元素一旦多起来，链表查找的效率就远不及红黑树了

树化一定更好吗？

不是的，维护红黑树需要占用比链表更多的空间，而且当链表长度足够短的时候，链表查找的效率反而比红黑树更高？？

为什么选择0.75和8

  • hash 值如果足够随机，则在 hash 表内按泊松分布，在负载因子 0.75 的情况下，长度超过 8 的链表出现概率是 0.00000006，树化阈值选择 8 就是为了让树化几率足够小

退化规则

扩容的时候链表长度<=6

remove节点的时候

root、root.left、root.right、root.left.left 有一个为 null ，也会退化为链表

最低0.47元/天 解锁文章
Java_LingFeng
关注
【聊聊Java】Java中HashMap常见问题 -- 扩容、树化、死链问题
BASK2312的博客
11-04 717
其实一般正常的元素，都是不会超过阈值的，只有插入一堆重复的元素，hash值一样，才可能达到阈值，这个简称Dos攻击 而元素一旦多起来，链表查找的效率就远不及红黑树了。因为HashMap的初始容量是2的次幂，扩容之后的长度是原来的二倍，新的容量也是2的次幂，所以，元素，要么在原位置，要么在原位置。不是的，维护红黑树需要占用比链表更多的空间，而且当链表长度足够短的时候，链表查找的效率反而比红黑树更高？可以的，因为2的n次方也会有缺陷，比如给定的值全是偶数，无论如何hash之后取模，都是偶数，分布就不均匀。
HashMap 为什么线程不安全？
weixin_44950062的博客
09-22 761
我们都知道HashMap是线程不安全的，在多线程环境中不建议使用，但是其线程不安全主要体现在什么地方呢，本文将对该问题进行解密。 在jdk1.8中对HashMap做了很多优化，这里先分析在jdk1.7中的问题，相信大家都知道在jdk1.7多线程环境下HashMap容易出现死循环，这里我们先用代码来模拟出现死循环的情况： public class HashMapTest { public static void main(String[] args) { HashMapThread
HashMap在并发下可能出现的问题分析
weixin_34019929的博客
04-05 1017
我们都知道，HashMap在并发环境下使用可能出现问题，但是具体表现，以及为什么出现并发问题，可能并不是所有人都了解，这篇文章记录一下HashMap在多线程环境下可能出现的问题以及如何避免。 在分析HashMap的并发问题前，先简单了解HashMap的put和get基本操作是如何实现的。 1.HashMap的put和get操作 大家知道HashMap内部实现是通过拉链法解决哈希冲突的，也就是...
如何解决哈希冲突
最新发布
m0_69529796的博客
03-26 445
Hash 冲突（Hash Collision）： 当不同的键（Key）经过哈希函数计算后，得到相同的哈希值（桶索引），称为发生冲突。👉 两个 key 都映射到索引 3，产生冲突。拉链法和开放地址法。实际应用中，Java HashMap 采用拉链法，并在链表过长时转为红黑树，避免性能退化。Redis 字典则采用开放地址法，结合 rehash 动态扩容。设计时还需要优化哈希函数、控制负载因子，避免冲突集中，提升性能。
一文就够！HashMap扩容死循环问题
Java架构师之路的博客
06-26 821
JDK 1.7 HashMap 扩容核心算法 下面这是JDK 1.7中HashMap扩容时调用的核心代码，作用是将原hash桶中的节点转移到新的hash桶中： void transfer(Entry[] newTable) { Entry[] src = table; int newCapacity = newTable.length; for (int j = 0; j < src.length; j++) { Entry e = src[j]; if (e != null) {
hashmap 的扩容和树形化
程序员世杰
01-10 2201
一、树形化 //链表转红黑树的阈值 static final int TREEIFY_THRESHOLD = 8; //红黑树转链表的阈值 static final int UNTREEIFY_THRESHOLD = 6; /** *最小树形化容量阈值：即 当哈希表中的容量 > 该值时，才允许树形化链表 （即 将链表 转换成红黑树） *否则，若桶内元素太多时，则直接扩容，而不是树形化 *为了...
Java中HashMap常见问题 -- 扩容、树化、死链问题
m0_71777195的博客
11-04 574
其实一般正常的元素，都是不会超过阈值的，只有插入一堆重复的元素，hash值一样，才可能达到阈值，这个简称Dos攻击 而元素一旦多起来，链表查找的效率就远不及红黑树了。因为HashMap的初始容量是2的次幂，扩容之后的长度是原来的二倍，新的容量也是2的次幂，所以，元素，要么在原位置，要么在原位置。不是的，维护红黑树需要占用比链表更多的空间，而且当链表长度足够短的时候，链表查找的效率反而比红黑树更高？可以的，因为2的n次方也会有缺陷，比如给定的值全是偶数，无论如何hash之后取模，都是偶数，分布就不均匀。
HashMap(1.7)在多线程并发扩容时导致的链表死循环问题
扎瓦菜鸟
02-20 605
图文说明1.7的HashMap在多线程并发扩容时导致的链表死循环问题
jdk1.7HashMap并发扩容发生死循环源码详解
MrArgus的博客
03-25 439
jdk1.7HashMap并发扩容发生死循环源码详解
Java HashMap的扩容
superxlcr的博客
05-30 6132
关于Java HashMap的扩容总结
HashMap的扩容及树化过程
热门推荐
程序员
04-07 1万+
上一篇博文 HashMap中capacity、loadFactor、threshold、size等概念的解释 讨论了HashMap中的一些基本概念，这篇博文结合具体示例，讨论下HashMap的扩容、树化过程。 注意 ， 本文基于JDK1.8 结论如果在创建HashMap实例时没有给定capacity、loadFactor则默认值分别是16和0.75。 当好多bin被映射到同一个桶时，如果这个桶
hashmap问题
sunnvig
01-22 196
先来些简单的问题 “你用过HashMap吗？” “什么是HashMap？你为什么用到它？” 几乎每个人都会回答“是的”，然后回答HashMap的一些特性，譬如HashMap可以接受null键值和值，而Hashtable则不能；HashMap是非synchronized;HashMap很快；以及HashMap储存的是键值对等等。这显示出你已经用过HashMap，而且对它相当的熟悉。但是面
hashmap 问题
yangsen159的博客
04-24 256
HashMap为什么是线程不安全的 我们知道hashmap的扩容因子是0.75如果hashmap的数组长度已经使用了75%就会引起扩容，会新申请一个长度为原来两倍的桶数组，然后将原数组的元素重新映射到新的数组中，原有数据的引用会逐个被置为null。就是在resize()扩容的时候会造成线程不安全。另外当一个新节点想要插入hashmap的链表时，在jdk1.8之前的版本是插在头部，在1.8后是插在尾...
特殊场景下的HashMap扩容、树化机制
做最亮的星星
09-09 333
Guava
关于HashMap扩容造成死循环的介绍
AlohaHeja的博客
05-26 4512
一、造成死循环的原因 HashMap扩容导致死循环的主要原因在于扩容后链表中的节点在新的hash桶使用头插法插入。新的hash桶会倒置原hash桶中的单链表，那么在多个线程同时扩容的情况下就可能导致产生一个存在闭环的单链表，从而导致死循环。 在JDK1.8中，HashMap是不会造成死循环的，因为在JDK1.8中，采用的是尾插法，保证了链表的顺序与之前一致。而且在1.8中链表过长时会转换为红黑树，...
HashMap扩容、树化分析
骑个小蜗牛的博客
07-04 8557
HashMap扩容、树化、单向链表、红黑树
深入解析Java HashMap的高性能扩容机制与树化优化
微笑听雨
05-21 8748
通过treeifyBin方法和resize方法的源码分析，可以看出Java 8中HashMap在处理哈希冲突和扩容方面的优化手段：树化：当桶中链表长度超过阈值时，将链表转换为红黑树，以提高查询效率。●扩容优先：如果哈希表容量不足，则优先进行扩容，而不是树化，以避免在小容量时引入树结构。扩容处理树节点：在扩容过程中，保留红黑树结构，并根据新链表长度决定是否退化为链表。这些机制共同保证了HashMap在处理大量数据时的高效性。理解这些实现细节有助于在实际使用中优化HashMap的性能。
Java集合之HashMap面试题
天天新知
02-11 436
1.介绍下 HashMap 的底层数据结构 我们现在用的都是 JDK 1.8，底层是由“数组+链表+红黑树”组成，如下图，而在 JDK 1.8 之前是由“数组+链表”组成。 2.为什么要改成“数组+链表+红黑树”？ 主要是为了提升在 hash 冲突严重时（链表过长）的查找性能，使用链表的查找性能是 O(n)，而使用红黑树是 O(logn)。 3.那在什么时候用链表？什么时候用红黑树？ 对于插入，默认情况下是使用链表节点。当同一个索引位置的节点在新增后达到9个（阈值8）：如果此时数组长度大...
HashMap常见面试题
weixin_38166905的博客
08-09 108
常见问题： 1、“你知道HashMap的工作原理吗？” “你知道HashMap的get()方法的工作原理吗？” 　　HashMap是基于hashing的原理，我们使用put(key, value)存储对象到HashMap中，使用get(key)从HashMap中获取对象。当我们给put()方法传递键和值时，我们先对键调用hashCode()方法，返回的hashCode用于找到bucket...
hshmap的扩容机制
03-02
<think>好的，我现在需要回答用户关于“hshmap的扩容机制”的问题。首先，用户可能指的是“HashMap”，因为在编程中常见的数据结构是HashMap，而“hshmap”可能是一个拼写错误。我需要先确认这一点。 接下来，用户想了解HashMap的扩容机制。我需要回忆Java中HashMap的实现，因为不同语言的实现可能不同，但用户之前的问题是关于Python的，但HashMap通常是Java中的数据结构。不过，用户现在可能指的是其他语言中的实现，比如Python的字典，但Python的字典扩容机制可能与Java不同。需要明确用户的问题范围。 假设用户指的是Java的HashMap，那么我需要详细解释其扩容机制。首先，HashMap在Java中的默认初始容量是16，负载因子是0.75。当元素数量超过容量乘以负载因子时，会触发扩容。扩容时，容量会翻倍，然后重新计算所有元素的位置，将它们分配到新的桶中。 但用户可能对具体的触发条件、扩容过程、重新哈希的细节感兴趣。需要分步骤解释，包括初始容量、负载因子、触发条件、扩容步骤、性能影响等。同时，可能需要提到Java 8之后的优化，比如当链表长度超过8时转换为红黑树，以减少查询时间，但这可能不属于扩容机制的核心部分，但可以简要提及。 另外，用户可能想知道为什么选择这样的机制，比如负载因子为什么是0.75，或者扩容为什么是翻倍。这时候需要解释负载因子的权衡，空间和时间效率的平衡。翻倍的原因是为了保持容量为2的幂，这样可以使用位运算代替取模运算，提高效率。 还需要注意是否存在其他情况触发扩容，比如当链表过长时是否会影响扩容，但通常链表过长会触发树化而不是直接扩容，所以扩容主要基于负载因子和当前容量。 另外，用户可能对并发环境下的问题感兴趣，比如多线程扩容可能导致死循环，但这是Java HashMap在并发下的问题，可能属于扩展内容，可以简要提及。 最后，可能需要对比其他语言或实现的HashMap扩容机制，比如Python的字典或C++的unordered_map，但用户的问题可能集中在Java上，所以需要先确认，但如果没有明确说明，可以以最常见的Java实现为例进行解释。 总结回答结构：首先明确讨论的是Java的HashMap，然后分点说明扩容机制的关键点，包括触发条件、扩容过程、负载因子的作用、容量翻倍的原因，以及可能的优化和并发问题。</think>HashMap的扩容机制是保证高效查询性能的核心设计，以下以Java实现为例详细说明其工作原理： 1. **基础参数** - 初始容量：默认16（$2^4$） - 负载因子：默认0.75（空间与时间的平衡值） - 阈值计算公式：$threshold = capacity * loadFactor$ 2. **触发条件** 当插入新元素后，容器内元素数量满足： $$ size > threshold $$ 即触发扩容（例如默认情况下：16*0.75=12，第13个元素插入时触发） 3. **扩容过程** ① **容量倍增**：新容量=旧容量<<1（保证保持2的幂） ② **重建桶数组**：创建新数组`newTab = new Node[newCap]` ③ **数据迁移**： ```java for (Node<K,V> e : oldTab) { while (null != e) { // 重新计算哈希分布 if ((e.hash & oldCap) == 0) { // 保持原索引位置 } else { // 迁移到原索引+旧容量的位置 } e = e.next; } } ``` 4. **优化策略** - **哈希扰动**：通过`(h = key.hashCode()) ^ (h >>> 16)`降低哈希冲突 - **树化转换**：当链表长度≥8且桶数量≥64时，转换为红黑树（时间复杂度从$O(n)$降为$O(log\ n)$） 5. **设计精妙点** - 容量保持2的幂：位运算`(n-1) & hash`替代取模运算，效率提升约20% - 扩容时节点迁移通过`e.hash & oldCap`快速判断新位置，无需重新计算哈希 6. **对比实验数据** | 负载因子 | 空间利用率 | 查询时间增长斜率 | |---------|-----------|------------------| | 0.5 | 50% | 1.5x | | 0.75 | 75% | 1.0x（基准） | | 0.9 | 90% | 2.0x | 7. **并发问题** 多线程环境下执行`put`操作可能引发： - **死链现象**：JDK1.7头插法导致循环链表 - **数据丢失**：JDK1.8尾插法仍存在更新覆盖问题 **最佳实践**：预估数据量时可通过`new HashMap<>(expectedSize / 0.75 + 1)`预扩容，避免多次重建带来的性能损耗。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值