链表树化需同时满足桶内节点数≥8且数组容量≥64，且key需可比较；数组扩容触发于size＞capacity×loadfactor、链表长度≥8且capacity＜min_treeify_capacity，或null桶首次插入。
HashMap链表触发树化和数组扩容，各自有明确的硬性指标，不是凭长度或数量“感觉差不多”就执行，而是由源码中两个关键常量严格控制：TREEIFY_THRESHOLD = 8 和 MIN_TREEIFY_CAPACITY = 64，同时受负载因子 0.75 约束。
链表转红黑树的两个硬性条件
必须**同时满足**以下两点，才会调用 treeify() 将链表升级为红黑树：
- 单个桶（bucket）内链表节点数 ≥ 8：注意是“已有8个节点”，不是插入第8个时立刻触发；实际在插入第9个元素、使 binCount 达到 7（源码中从0开始计数）后检查并启动树化
- 底层数组容量 table.length ≥ 64：若当前容量是16、32，哪怕某桶已满8个，也不会树化，而是优先扩容
此外，树化还隐含前提：key 类型必须可比较——即实现 Comparable 接口，或 HashMap 构造时传入了 Comparator；否则 treeifyBin() 会静默跳过，维持链表结构。
数组扩容的三大触发场景
扩容（resize）不只看元素总数，而是由以下任一条件满足即发生：
- size > capacity × loadFactor：最常见情况。例如默认容量16、负载因子0.75 → 阈值为12，插入第13个元素时扩容
- 链表长度 ≥ 8 且 capacity ：此时不树化，转而强制扩容（哪怕 size 还远低于阈值），目的是用空间换结构稳定
- 首次 put 操作：HashMap 采用懒加载，table 初始化为空，第一次 put 才真正创建长度为16的数组
扩容后新容量恒为原容量的2倍（如16→32→64→128），且始终维持2的幂次，以支持位运算快速寻址（hash & (newCap - 1)）。
树化与扩容的协作逻辑
二者不是互斥，而是存在优先级和递进关系：
- 当某桶链表达到7个节点，再插入第8个时：先检查容量是否≥64 → 否，则触发扩容；是，则进入树化流程
- 扩容过程中，原红黑树会按 hash 高位拆分，节点数≤6的子树直接退化为链表；这是唯一退化场景，日常增删不会主动退化
- 阈值8和64本质是“异常探测机制”：泊松分布显示，理想哈希下链表≥8的概率低于千万分之一；一旦触发，大概率说明 hashCode 实现有缺陷或数据分布极端倾斜
不复杂但容易忽略。
