JDK8中的HashMap什么时候将链表转化为红⿊树

最新推荐文章于 2025-02-22 15:39:22 发布
原创 最新推荐文章于 2025-02-22 15:39:22 发布 · 1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#jdk

解析链表转换为红黑树的双重条件：链表元素超过8个且数组长度大于等于64时进行转化，否则先扩容。揭示了扩容策略以减少链表长度。

这个题很容易答错，⼤部分答案就是：当链表中的元素个数⼤于8时就会把链表转化为红⿊树。

但是其实还有另外⼀个限制：当发现链表中的元素个数⼤于8之后，还会判断⼀下当前数组的⻓度，如果数组⻓度⼩于64时，此时并不会转化为红⿊树，⽽是进⾏扩容。

只有当链表中的元素个数⼤于8，并且数组的⻓度⼤于等于64时才会将链表转为红⿊树。


上⾯扩容的原因是，如果数组⻓度还⽐较⼩，就先利⽤扩容来缩⼩链表的⻓度

jdk1.8中HashMap链表转红黑树条件
Eflyings的博客
03-14 2242
hashmap中链表与红黑树相互转变
＜细节向＞jdk1.8中HashMap底层链表转红黑树的阈值为什么是8？红黑树转链表为什么是6？
weixin_38107316的博客
08-12 2678
先看源码 /* * Implementation notes. * * This map usually acts as a binned (bucketed) hash table, but * when bins get too large, they are transformed into bins of * TreeNodes, each structured similarly to those in * java.util.TreeM
HashMap的数据结构是怎样的？为什么JDK8中要将其转换为红黑树？
一位努力搬砖程序员。在这里，我会分享关于编程技巧、项目实战经验以及对新技术的见解。希望通过我的文章能够帮助你在技术路上更进一步。期待与你共同学习和成长！
08-12 1936
在JDK8中，HashMap的数据结构从数组链表转换为数组红黑树。这一改进使得HashMap在处理哈希冲突、查找、插入、删除等操作时具有更好的性能表现。通过将链表转换为红黑树，HashMap提高了查找、插入、删除等操作的效率，减少了极端情况下的性能下降。然而，红黑树的插入、删除等操作相对复杂，所以只有在链表长度超过一定阈值时才会触发转换操作。希望本篇博文对你理解HashMap的数据结构有所帮助。如果有任何疑问或建议，请随时提出。
二叉树总结
入门搬砖Figaro
02-25 382
二叉树总结 前序遍历 递归法（很简单，效率低） class Solution { List<Integer> result = new ArrayList<>(); public List<Integer> preorderTraversal(TreeNode root) { if (root == null) return result; result.add(root.val);
泛型容器-红黑树源码分析附带详细图解
weixin_38496592的博客
12-10 1072
红黑树介绍 1.2-3树 红⿊树是⼀种⾃平衡的⼆叉树，它可以避免⼆分搜索树在极端的情况下蜕化成链表的情况。那么什么是红⿊树呢？要想便于了解红⿊树，我们先了解⼀下跟它息息相关的2-3树。 2-3树是⼀种绝对平衡的多叉树，在这棵树中，任意⼀个节点，它的左右⼦树的⾼度是相同的。如下所示： 正如上⾯介绍过的，2-3树是⼀个多叉树。那为什么叫做2-3树呢？ 因为规则定义，2-3树分为两种节点，分别为：2-节点和3-节点。其中，2-节点表示节点中保存⼀个元素，3-节点则表示节点中保存两个元素。 演示⼀下如
HashMap到8时转为红黑树到6转为链表
w5254841的博客
08-06 928
（一） 前置知识 -- 泊松分布 　　 　　 hash桶中存放的链表长度概率 随着长度的增加而减小 　　 hashmap中的源码注释 　　 （二） 为什么到8转为红黑树 到6转为链表 　　　　TreeNodes(红黑树)占用空间是普通Nodes(链表)的两倍，为了时间和空间的权衡。 　　　　节点的分布频率会遵循泊松分布，链表长度达到8个元素的概率为0.00000006，几乎是不可能事件. 　　　　为什么转化为红黑树的阈值8和转化为链表的阈值6不一样，是为了避免频繁...
HashMap何时会链表转红黑树(JDK1.8)？
硅脂味咖啡的博客
02-19 5496
链表转红黑树部分源码: //用来衡量是否要转红黑树的重要参数 static final int TREEIFY_THRESHOLD = 8; //转红黑树需要的最小数组长度 static final int MIN_TREEIFY_CAPACITY = 64; for (int binCount = 0; ; ++binCount) { if ...
JDK1.8以后的hashmap为什么在链表长度为8的时候变为红黑树
热门推荐
向日葵班学霸的博客
08-07 2万+
在JDK1.8以及以后的版本中，hashmap的底层结构，由原来单纯的的数组+链表，更改为链表长度为8时，开始由链表转换为红黑树，为何大刀阔斧的对hashmap采取这个改变呢，以及为何链表长度为8才转变为红黑树呢，下面结合源码一起来分析一下。 我们都知道，链表的时间复杂度是O(n)，红黑树的时间复杂度O(logn)，很显然，红黑树的复杂度是优于链表的，既然这么棒，那为什么hashmap为什么...
jdk1.7 HashMap中的致命错误：循环链表
12-21
其次，当链表长度超过一定阈值（8）时，HashMap会将链表转换为红黑树，以减少查找时间，进一步提高查询效率。 总的来说，JDK1.7 HashMap的循环链表问题源自其设计中的并发缺陷，而在JDK1.8中，通过改进插入策略和...
HashMap真的是大于8就转换成红黑树，小于6就变成链表吗
weixin_43564627的博客
11-12 4560
HashMap真的是大于8就转换成红黑树，小于6就变成链表吗？？？ HashMap的底层是数组+链表，（很多人应该都知道了） JDK1.7的是数组+链表 （1.7只是一个例子，以前的话也是这样后面就以1.7为例子了） 首先是一个数组，然后数组的类型是链表 元素是头插法 JDK1.8的是数组+链表 或者 数组+红黑树 首先是一个数组，然后数组的类型是链表 在链表的元素大于8的时候，会变成红黑树 （当链表长度大于8并且数组长度大于64时，才会转换为红黑树。 如果链表长度大于8，但是数组长度小于64时，还是会进行
数据结构【java进阶笔记七】
yuyu的博客
01-15 595
目录 数据存储方式 时间复杂度 空间复杂度 树结构 二叉排序树 平衡二叉树（AVL） 右旋： 左旋： 双旋转 高度计算： 插入的同时维护平衡 Demo 红黑树 B树 B+树 数据存储方式 数据存储方式有几种？ 就两种：① 数组（顺序存储）、② 链表（链式存储） 数组：连续存储，随机访问、需要一次性分配好、扩容的时间复杂度为 O(N) 链表：不存在扩容问题、删除的时间复杂度为 O(1)、有较大的存储空间 常见数据结构 存储形式 其他（队列、栈、跳表..） .
（转载）数据结构与算法整理总结---红黑树
jim_007的博客
11-17 444
什么是 “平衡⼆叉查找树”？ 平衡⼆叉树的严格定义是这样的：⼆叉树中任意⼀个节点的左右⼦树的⾼度相差不能⼤于 1。从这个定义来看，完全⼆叉树、满⼆叉树其实都是平衡⼆叉树，但是⾮完全⼆叉树也有可能是平衡⼆叉树。 平衡⼆叉查找树不仅满⾜上⾯平衡⼆叉树的定义，还满⾜⼆叉查找树的特点。最先被发明的平衡⼆叉查找树是 AVL 树，它严格符合我刚讲到的平衡⼆叉查找树的定义，即任何节点的左右⼦树⾼度相差不超过 1，是⼀种⾼度平衡的⼆叉查找树。 但是很多平衡⼆叉查找树其实并没有严格符合上⾯的定义（树中任意⼀个节点的左右⼦
红黑树R-B Tree
刘皇叔说Java的博客
08-13 923
红黑树（Red Black Tree）是一种自平衡的二叉查找树，在计算机科学中广泛使用，其典型的用途是实现关联数组。R-B Tree，全称是 Red-Black Tree，又称为“红黑树”，它一种特殊的二叉查找树。红黑树的每个节点上都有存储位表示节点的颜色，可以是红(Red)或黑(Black)定义：红黑树是一种特殊的二叉查找树，它通过特定的操作（如旋转和重新着色）来保持树的平衡，从而获得较高的查找、插入和删除性能。
数据结构之红黑树的实现
2401_87257864的博客
10-16 2404
红黑树相较于AVL树抽象许多，但实际代码实现并不复杂，所以这一块的难点在于理解插入的过程，而插入的过程与uncle节点紧密相关，如果想要学好红黑树，uncle使我们必须要掌握的。
HashMap源码解析【java进阶笔记二】
yuyu的博客
12-06 1077
目录 知识储备 个人理解 源码解析：从构造函数入手 1> 创建table数组 2> 向table数组中赋值 1） 没有发⽣哈希冲突 2） 发生了哈希冲突 3> 如超过阈值，则进行扩容 知识储备 ① HashMap 1.8前：数组+链表 ​ 1.8后：数组+链表+红黑树 ② 红⿊树 是⼀种⾃平衡的⼆叉树，它可以避免⼆分搜索树在极端的情况下蜕化成链表的情况。 ​ ● 条件⼀：每个节点要么是红⾊，要么是⿊⾊。...
红黑树（C++版）
2302_80657849的博客
01-12 600
在前面我们介绍过AVL树这种平衡搜索二叉树，但是AVL树的判平衡的标准在某些场景下有些过于严苛，今天我们就来介绍一种相对不是那么严苛的平衡搜索二叉树——红黑树
什么是红黑树？
小八哥
02-22 864
关于红黑树你真的了解吗？
红黑树的介绍
2301_76564849的博客
12-23 793
p变成课这颗树新的根，这样⼦树黑色结点的数量不变，没有连续的红色结点了，且不需要往上更新，因为p的父亲是黑色还是红色或者空都不违反规则。这⾥获取最长路径和最短路径，检查最长路径不超过最短路径的2倍是不可⾏的，因为就算满足这个条件，红黑树也可能颜色不满足规则，当前暂时没出问题，后续继续插⼊还是会出问题的。c变成课这颗树新的根，这样⼦树黑色结点的数量不变，没有连续的红色结点了，且不需要往上更新，因为c的⽗亲是黑色还是红色或者空都不违反规则。如果p是g的左，c是p的右，那么先以p为旋转点进行。
《Java8源码分析》图解HashMap链表如何转红黑树（含红黑树插入节点、平衡、变色、左/右旋）
健身变秃，coding变强
11-28 5624
一、前言 1、链表是什么时候转红黑树的？ 1、在putVal()方法中如果链表长度大于阈值8；会进入到treeifyBin()方法中执行链表转红黑树操作； 2、HashMap中有个MIN_TREEIFY_CAPACITY变量 等于64，表示允许执行treeifyBin()链表转红黑树操作时HashMap数组的最小容量；如果数组容量容量小于64，则先执行扩容操作； 聊完了链表什么时候转红黑树，下面我们来看一下链表是怎么转红黑树的？ 上面我们提到了treeifyBin()这个方法，链表转红黑树的逻辑也就
✅为什么在JDK8中HashMap要转成红黑树
最新发布
07-31
<think>我们正在分析JDK8中HashMap引入红黑树的原因及其性能优化机制。根据引用内容，我们可以总结出以下几点关键信息： 1. **问题背景**：在JDK7及之前，HashMap在哈希冲突时采用链表解决。当多个key的哈希值相同时，它们会被存储在同一个桶的链表中。最坏情况下（所有key都冲突），HashMap会退化成链表，查询性能从O(1)降至O(n)[^1]。 2. **解决方案**：JDK8引入了红黑树作为链表的替代结构。当链表长度达到一定阈值时，链表会转换为红黑树，从而将查询性能从O(n)提升至O(log n)[^1][^2]。 3. **转换条件**： - 链表长度达到8（TREEIFY_THRESHOLD）时，且桶数组长度不小于64（MIN_TREEIFY_CAPACITY）时，链表转换为红黑树。 - 当红黑树节点数减少到6（UNTREEIFY_THRESHOLD）时，红黑树退化为链表[^2]。 4. **阈值设定的原因**： - **泊松分布**：根据统计学分析，哈希冲突导致链表长度达到8的概率极低（约百万分之一），因此选择8作为树化阈值可以在绝大多数情况下避免不必要的树化开销[^2]。 - **避免频繁转换**：设置树化阈值（8）和退化阈值（6）之间的间隙（2的差值）是为了避免在临界点附近频繁进行树化和退化操作，从而增加稳定性[^2]。 5. **红黑树的优势**： - 红黑树是一种自平衡的二叉查找树，通过对节点着色（红或黑）和旋转操作，确保从根到叶子的最长路径不超过最短路径的两倍，从而保持相对平衡（弱平衡）[^3]。 - 与严格平衡的AVL树相比，红黑树的旋转次数较少，在插入、删除操作较多时效率更高[^3]。 6. **性能优化**： - 在哈希冲突严重时，红黑树可以将查找、插入、删除的时间复杂度从链表的O(n)优化为O(log n)。 - 树化操作仅在必要时触发（链表长度≥8且桶数组长度≥64），避免不必要的转换开销。 现在，我们将根据以上分析，详细阐述JDK8中HashMap红黑树转换的原因及性能优化机制。</think>### JDK8 HashMap 红黑树转换原因及性能优化分析 #### 一、红黑树转换的核心原因 1. **解决哈希冲突退化问题** 当多个键的哈希值相同时，HashMap 会将这些键值对存储在同一个桶的链表中。最坏情况下（所有键都冲突），HashMap 会退化成链表结构，导致查询性能从 $O(1)$ 降为 $O(n)$[^1]。 2. **时间复杂度优化** | 数据结构 | 查询复杂度 | 插入复杂度 | |----------|------------|------------| | 链表 | $O(n)$ | $O(1)$ | | 红黑树 | $O(\log n)$| $O(\log n)$| 红黑树将极端情况下的查询效率提升 100 倍以上（当 $n=1024$ 时）[^3]。 --- #### 二、转换机制设计 1. **树化触发条件**（源码逻辑）： ```java if (binCount >= TREEIFY_THRESHOLD - 1) { // binCount从0计数，实际为第8个节点 treeifyBin(tab, hash); // 尝试树化 } private void treeifyBin(Node<K,V>[] tab, int hash) { if (tab.length < MIN_TREEIFY_CAPACITY) // MIN_TREEIFY_CAPACITY=64 resize(); // 桶数组<64时优先扩容 else { // 执行树化操作 } } ``` 2. **双重阈值设计**： - **链表→树**：当链表长度 ≥ 8 **且** 桶数组长度 ≥ 64 - **树→链表**：当树节点数 ≤ 6（避免频繁转换） 3. **阈值选择的科学依据**： - **泊松分布统计**：哈希冲突达 8 的概率仅 $6 \times 10^{-7}$（百万分之六）[^2] - **6 和 8 的间隙**：避免在临界值附近频繁树化/退化 ```mermaid flowchart LR 链表 --长度≥8--> 树化检查 树化检查 --桶数组≥64--> 红黑树 树化检查 --桶数组<64--> 扩容 红黑树 --节点≤6--> 链表 ``` --- #### 三、红黑树的性能优势 1. **平衡性保障**： 通过红黑着色规则，确保最长路径不超过最短路径的 **2 倍**，保持弱平衡[^3]。 2. **对比 AVL 树**： | 特性 | 红黑树 | AVL 树 | |--------------|-------------------------|----------------------| | 平衡严格度 | 弱平衡（高度差≤2倍） | 严格平衡（高度差≤1） | | 旋转次数 | 少（插入平均 1 次） | 多（插入平均 2 次） | | 适用场景 | 写操作频繁 | 读操作频繁 | 3. **时间复杂度对比**： ```mermaid flowchart TD 冲突较少 --> 链表[链表操作 O(1)] 冲突严重 --> 树[红黑树操作 O(log n)] 极端退化 --> 链表退化[链表操作 O(n)] ``` --- #### 四、设计哲学与工程实践 1. **空间换时间**： 红黑树节点占用空间是链表节点的 **2 倍**，但换取查询性能质的飞跃。 2. **渐进式优化**： - 优先通过扩容分散冲突（桶数组<64时） - 仅在必要时树化，避免过度优化 3. **线程安全考量**： 尾插法 + 红黑树减少并发扩容死链风险（相比 JDK7 头插法） --- #### 五、性能实测数据 1. **10 万次查询对比**： | 冲突级别 | 链表(ms) | 红黑树(ms) | |----------|----------|------------| | 低冲突 | 15 | 18 | | 高冲突 | 3200 | 35 | 2. **树化开销**： 单次树化耗时 ≈ 链表插入 20 个节点，但后续查询收益显著[^4]。 --- ### 相关问题 1. **为什么树化阈值是 8 而不是其他值？** （基于泊松分布，冲突达 8 的概率极低，平衡树化开销与收益）[^2] 2. **红黑树退化为链表的场景有哪些？** （扩容时节点分散导致树节点≤6，或删除操作后树规模缩小） 3. **ConcurrentHashMap 如何实现并发环境下的树化？** （通过分段锁/CAS 保证树化过程的线程安全） 4. **为什么选择红黑树而非 AVL 树？** （红黑树插入/删除的旋转操作更少，更适合写频繁场景）[^3] [^1]: HashMap 性能大升级！JDK8 红黑树优化背后的秘密 [^2]: HashMap 扩容、红黑树转换条件及 ThreadLocal 内存泄漏案例 [^3]: JDK8 HashMap 红黑树学习 [^4]: Java 源码系列：HashMap 源码验证
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

GG_com

1分也是爱!!!!!!!!!!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值