hashmap扩容与红黑树转换协同工作：扩容优先缓解冲突，红黑树在扩容无效时优化查询；触发条件为size＞threshold或链表长≥8且capacity＜64时强制扩容；扩容采用容量翻倍与高低位链表拆分，利用2的幂次特性高效迁移。
HashMap 的扩容和红黑树转换不是两个孤立机制，而是协同工作的动态平衡策略：扩容优先缓解哈希冲突压力，红黑树则在扩容无法根本改善局部聚集时介入优化查询效率。
扩容机制：容量翻倍 + 高低位链表拆分
扩容由 resize() 方法触发，核心目标是降低桶（bucket）平均负载。触发条件有两个：
- 当前元素总数
size超过阈值threshold = capacity × loadFactor（默认 16×0.75=12） - 某链表长度达到 8，但数组长度
capacity小于 64 —— 此时不转红黑树，而是强制扩容
扩容过程不是简单重建哈希，而是利用数组长度始终为 2 的幂次这一特性进行高效迁移：
- 新容量 = 原容量
- 每个旧桶中的节点，根据其 hash 值的高位 bit 决定去向：若
(e.hash & oldCap) == 0，留在原下标；否则迁移到原下标 + oldCap - 这样链表被自然拆分为“低位链表”和“高位链表”，无需重新计算 hash，也不需遍历比较
红黑树转换：双阈值共同约束
链表不会一满就转树，必须同时满足两个硬性条件：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 链表长度 ≥ 8（
TREEIFY_THRESHOLD = 8） - 数组总长度 ≥ 64（
MIN_TREEIFY_CAPACITY = 64）
这是为避免小容量下过早树化带来的额外开销。转换发生在 treeifyBin() 中，实际是将链表节点包装为 TreeNode，并按红黑树规则重排结构。而当树中节点数 ≤ 6 时（UNTREEIFY_THRESHOLD = 6），会退化回链表——退化不依赖扩容，只看当前树节点数量。
为什么先扩容再考虑树化？
本质是成本权衡：
- 扩容是全局操作，摊销后单次迁移成本低，且能从根源上分散哈希冲突
- 树化是局部操作，涉及节点重构、着色、旋转，开销显著高于链表操作
- 所以 JDK 设计为：小数组优先扩容（廉价）；大数组+长链表才树化（必要时才付出高成本）
实际影响与编码建议
理解这套机制对写代码有直接帮助：
- 预估数据量较大时，显式指定初始容量（如
new HashMap(1024)），避免多次扩容 - 自定义 key 类型时，务必重写
hashCode()和equals()，否则哈希分布差，极易触发频繁扩容或过早树化 - 不要误以为“链表变树就一定更快”——红黑树常数因子大，短链表（≤8）用链表反而更轻量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
