阈值8是综合泊松分布概率（长度≥8概率仅六百万分之一）、性能实测（链表≤7时更快，≥8时红黑树占优）及工程稳定性（配合容量≥64才树化、退化阈值设为6防抖动）确定的。

HashMap 在 JDK 8 中把链表转为红黑树的阈值设为 8，不是拍脑袋定的，而是结合概率模型、性能实测和工程稳定性综合决定的。

泊松分布推导出 8 是小概率事件的临界点

HashMap 的哈希桶（bucket）中元素个数服从泊松分布——这是在哈希函数均匀、key 随机的前提下成立的统计模型。源码注释明确提到：当负载因子为 0.75 时，桶中元素个数为 k 的概率约为 e⁻⁰·⁷⁵ × 0.75ᵏ / k!。算下来：

• 长度为 0～7 的概率总和超过 99.9999%
• 长度为 8 的概率约是 0.000006（六百万分之一）
• 长度 ≥ 9 就更罕见了

这意味着：正常情况下几乎不会出现长度 ≥ 8 的链表；一旦出现，大概率说明发生了异常哈希碰撞（比如恶意构造 key），或数据分布严重倾斜。此时链表 O(n) 查找已成瓶颈，必须升级结构。

8 是性能拐点，低于它树化反而更慢

红黑树节点比链表节点多存 3 个引用（left/right/parent）和颜色位，插入、删除逻辑复杂，常数项开销大。而链表在长度 ≤ 7 时，遍历成本仍可控：

• 链表查平均 4 次比较就能命中（假设均匀）
• 红黑树查 log₂8 = 3 层，但每次比较+指针跳转+平衡调整，实际耗时更高
• JDK 团队做过大量基准测试，确认 8 是“链表开始拖后腿、红黑树开始占优”的实测分水岭

配合容量阈值 64，避免过早树化

仅长度 ≥ 8 不够，还要求 table.length ≥ 64 才触发树化。原因很实在：

• 小表（如 length=16 或 32）更容易通过扩容分散冲突，扩容成本远低于树化
• 扩容后数组拉长，哈希值重散列，原长链表往往自动拆散
• 强制要求 ≥ 64，相当于默认“这表已经不小了，再扩容性价比低”，此时才值得上树

退化阈值设为 6，留出缓冲防震荡

红黑树变回链表的阈值是 6（UNTREEIFY_THRESHOLD），不是 8。这个 2 的差值很关键：

• 如果删到 7 就退化，刚删一个又插一个，可能反复树化/退化，徒增开销
• 设成 6，就形成「8→树，≤6→链表」的滞后区间，类似操作系统里的高低水位机制
• 既保证性能敏感点及时响应，又避免抖动，属于典型的稳态设计