HashMap链表转红黑树需同时满足：桶中节点数≥8且数组长度≥64；阈值8源于泊松分布推导（λ=0.5时P(≥8)≈6e-8），兼顾性能拐点（log₂8=3优于链表遍历）；长度≥64为排除假冲突、确认哈希异常；实际在插入第9个元素时触发（binCount≥7）；退化阈值设为6，防止7–8间频繁震荡。

HashMap链表转红黑树，不是“一到8就转”，而是两个条件必须**同时满足**：单个桶中链表节点数≥ 8，且整个哈希表的数组长度≥ 64。缺一个，都不会触发树化。

为什么链表长度阈值是8？

这个数字不是拍脑袋定的，而是基于泊松分布的概率推导：

• 在哈希函数理想、负载因子为0.75的前提下，单个桶内元素个数近似服从λ≈0.5的泊松分布
• 此时P(链表长度 ≥ 8) ≈ 0.00000006 —— 意味着正常情况下几乎不可能自然出现8个冲突
• 一旦真达到或超过8，大概率说明哈希分布异常（比如key重写hashCode不合理、数据高度集中），需要更稳定的结构兜底
• 另外，8也是性能拐点：链表查第8个元素平均要遍历4~5次，而红黑树log₂8=3，优势开始显现

为什么数组长度必须≥64？

这是为了区分“假冲突”和“真冲突”：

• 容量小（如16、32）时，哈希冲突往往是因为“空间太挤”，不是哈希函数问题；扩容就能缓解
• 等扩容到64，意味着已经历至少两次翻倍（16→32→64），若此时还有桶堆积到8个节点，说明冲突是结构性的，扩容已难改善
• 64也是工程权衡：太小（如16）会导致小表频繁树化，徒增旋转、着色开销；太大（如512）又让长链表长期存在，拖慢查找

树化实际怎么发生的？

它发生在put操作末尾的检查环节，关键逻辑在treeifyBin()方法里：

• 先判断table是否为空或长度＜64 → 是，则直接resize()，不树化
• 只有tab.length ≥ 64 且当前桶链表节点数 ≥ 8，才调用treeify()真正构建红黑树
• 注意：源码中判断的是binCount >= TREEIFY_THRESHOLD - 1（即≥7），因为计数从0开始，插入第8个节点后binCount=7，触发树化
• 所以严格来说，是链表长度达到8之后，再插入第9个元素时才会触发树化（即链表已有8个节点，新元素是第9个）

树化不是终点，退化也讲策略

红黑树也会“变回链表”，但退化阈值设为6，而非8：

• 当resize后某个树桶中节点数 ≤ 6，会untreeify()退化为链表
• 用6而不是8，是为了避免在7–8之间反复横跳：比如删一个变7→不退化，再删一个变6→退化；加一个变7→不树化，再加一个变8→也不立即树化（要等到第9个）
• 这叫“高低水位防震荡”，减少结构切换带来的额外开销