Java 8引入红黑树的核心目标是将哈希冲突严重时的O(n)线性查找优化为O(log n)对数级查找，避免性能断崖式下跌；通过链表长度≥8且数组容量≥64触发树化、节点数≤6触发退化，并采用泊松分布验证的阈值8实现统计合理与工程安全的平衡。
HashMap 在 Java 8 中引入红黑树，核心目标很明确：当哈希冲突严重、链表变长时，把原本 O(n) 的线性查找，优化为 O(log n) 的对数级查找，避免性能断崖式下跌。
为什么链表会拖慢性能？
哈希表理想状态是每个 key 映射到独立桶（数组位置），但现实中不同 key 可能算出相同 hash 值，只能挤进同一个桶——这时用链表串起来。一旦大量 key 落到同一桶（比如恶意构造或数据分布极不均），链表可能长达几十甚至上百节点。此时 get、put、remove 都得逐个比对 key，时间开销直线上升。
红黑树不是“替代链表”，而是“按需升级”
Java 8 并没有抛弃链表，而是设计了一套动态切换机制：
- 链表长度 ≥ 8 且 数组总容量 ≥ 64 → 触发树化，链表转为红黑树
- 红黑树节点数 ≤ 6 → 触发退化，树还原为链表
- 数组容量 < 64 时即使链表超长，也优先扩容而不是树化（因为扩容后冲突自然分散）
这个“8 和 6”的差值（gap）很关键：防止在临界点反复树化/退化，减少旋转、着色等维护开销。
立即学习“Java免费学习笔记（深入）”；
为什么选红黑树，而不是 AVL 或跳表？
红黑树在平衡性与操作成本之间做了务实取舍：
- 它不要求像 AVL 那样严格平衡，插入/删除时调整次数更少，适合频繁增删的 Map 场景
- 它支持有序遍历（基于 key 的比较），方便实现 keySet()、entrySet() 等视图
- TreeNode 复用了部分 LinkedHashMap 的双向链表结构，便于迭代和扩容迁移
实际效果不只是“更快”，更是“更稳”
在正常业务中，链表很少到 8；但面对哈希碰撞攻击（如大量 key 的 hashCode() 返回相同值），红黑树让最坏情况仍可控。泊松分布分析表明：负载因子 0.75 下，单桶节点数达到 8 的概率低于千万分之一——所以阈值设为 8，既是统计合理性，也是工程上的安全冗余。
