链表转红黑树的阈值设为8是综合泊松分布极低概率（≥8概率仅千万分之六）、性能拐点（log₂8=3优于链表均值4次）及空间成本权衡后的最优平衡点，且需满足数组长度≥64才触发。
链表转红黑树的阈值设为 8，是综合统计规律、性能拐点和工程成本后确定的平衡点，不是随意拍定的数字。
基于泊松分布的极低概率事件
在哈希函数理想、负载因子为 0.75 的前提下，单个桶中元素数量近似服从 λ ≈ 0.5 的泊松分布。此时：
- 链表长度为 0 的概率约 60.65%
- 长度为 1 的概率约 30.33%
- 长度为 6 的概率约 0.0013%
- 长度 ≥ 8 的概率仅约 0.00000006（千万分之六）
这意味着：正常情况下几乎不会自然出现 8 个冲突。一旦真达到或超过 8，大概率说明哈希分布异常（如 key 的 hashCode 实现不合理、数据高度集中），必须用红黑树兜底保障性能。
性能拐点：log₂8 = 3 开始显优势
链表查找平均需遍历一半节点，长度为 8 时平均比较 4 次；红黑树最坏查找仅需 log₂8 = 3 次。这个量级上，O(log n) 的优势开始稳定显现：
- 长度为 4：链表均值 2 次 vs 红黑树约 2 次 → 差异不明显
- 长度为 8：链表均值 4 次 vs 红黑树最多 3 次 → 红黑树更稳
- 长度为 16：链表均值 8 次 vs 红黑树最多 4 次 → 优势拉开
空间与实现成本的权衡
TreeNode 节点大小约为普通 Node 的两倍，树化本身也有旋转、着色、重构等开销。因此不能过早树化：
- 设得太小（如 3 或 5）：频繁触发，内存浪费 + CPU 开销上升
- 设得太大（如 16 或 32）：链表已严重拖慢查询，优化滞后
- 8 是实测中“性能收益 > 空间/计算成本”的合理临界值
还需满足数组长度 ≥ 64 才真正树化
仅链表长度 ≥ 8 不够，还要求 table.length ≥ 64。这是为了：
- 排除小容量下的偶然长链（比如刚初始化、数据倾斜但总容量才 16）
- 确保哈希表已具备一定规模，树化的性价比更高
- 避免在扩容频繁的早期阶段引入不必要的树结构复杂度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
