HashMap在桶中链表长度≥8且数组容量≥64时树化为红黑树；扩容时红黑树节点数≤6则退化为链表；阈值8基于泊松分布设计，用以探测哈希异常，不可安全修改。
HashMap 什么时候会把链表转成红黑树？
当某个桶（bucket）里的链表长度达到 8，且整个 HashMap 的容量（table.length）不小于 64 时，才会触发树化。不是链表一变长就转，也不是所有情况都转。
- 链表长度 ≥
8是必要条件，但只是“候选”：如果数组太小（比如刚初始化的16），即使某链表到了8，也先扩容，不树化 - 真正树化的前提是
table.length >= 64，这是为了减少小容量下树结构的额外开销 - 树化动作发生在
putVal()过程中，插入新节点后检查该桶链表长度，满足条件则调用treeifyBin() - 注意：树化只影响单个桶，其他桶仍是链表或红黑树，互不影响
红黑树什么时候会退化回链表？
只有在 resize()（扩容或缩容）过程中，某个红黑树节点数 ≤ 6 时，才会退化为链表；日常 remove() 或 put() 不会主动退化。
- 退化判断发生在
split()阶段（即 rehash 时拆分原树），不是每次删除都检查 - 阈值是
6，和树化阈值8形成“缓冲区间”，避免频繁树化/退化震荡 - 若树中只剩
1个节点，退化后就是单节点链表；若为0，桶直接置为null - 没有“手动退化”API，也不支持配置该阈值——它是硬编码在
TreeNode.treeifyBin()和split()里的
为什么树化阈值设为 8？和泊松分布有关吗？
是的，但别被论文吓住：这个 8 是基于均匀哈希下链表长度服从泊松分布的数学推导，核心结论是——当负载因子为 0.75 时，链表长度 ≥ 8 的概率已低于千万分之一。
- 这意味着：正常情况下几乎不会触发树化；一旦触发，大概率说明哈希函数写得不好，或数据存在严重哈希冲突
- 所以
8不是性能最优解，而是“异常信号探测阈值”：它优先保常见 case 的链表轻量性，再兜底抗坏数据 - 如果你的 key 类型重写了烂
hashCode()（比如永远返回1），那哪怕容量很大，也会一路树化——这时该修的是hashCode()，不是调阈值
能改树化/退化阈值吗？有什么风险？
不能安全地改。JDK 没提供任何配置项或钩子，硬改源码会导致与未来版本不兼容，且破坏扩容逻辑的假设前提。
立即学习“Java免费学习笔记（深入）”；
-
TREEIFY_THRESHOLD和UNTREEIFY_THRESHOLD是static final，反射修改会失败（JDK 9+ 模块系统限制） - 强行 patch 字节码或用 agent 注入，可能让
resize()中的split()计算错节点归属，导致数据丢失或死循环 - 退化阈值
6和树化阈值8是配对设计的，单独动一个会扩大震荡窗口，实测容易引发 CPU 尖刺 - 真有极端场景（比如确定 key 全部哈希冲突），应换
ConcurrentHashMap或自定义 Map 实现，而不是碰 HashMap 底层阈值
真正要盯的不是阈值数字，而是你 key 的 hashCode() 是否合理、是否复用了同一个 HashMap 存大量相似 key、以及初始容量有没有预估——这些才是实际影响树化频率的开关。
