Java HashMap链表转红黑树需同时满足：桶内链表长度≥8且数组容量≥64；长度从首个节点计，插入第8个时触发检查；容量不足64时优先扩容而非树化；key须可比较，否则静默失败；节点≤6时退化回链表。
Java HashMap 中链表转红黑树，不是“链表一变长就转”，而是两个硬性条件必须**同时成立**：单个桶内链表长度 ≥ 8，且整个哈希表的底层数组容量（table.length）≥ 64。
链表长度 ≥ 8 是指“同一桶里实际存了 8 个节点”
这个计数从第一个键值对开始算起，不包含虚拟头结点。每次 put 插入新元素后，HashMap 会检查该桶当前链表长度；如果插入前已有 7 个节点，插入第 8 个时才满足长度条件。但仅这一步不会立刻树化——它只是触发检查的起点。
数组容量 ≥ 64 是为了防止过早引入红黑树
当容量是 16、32 或更小时，哪怕某个桶链表已经到 8，HashMap 也不会树化，而是优先扩容（resize()），把数组长度翻倍。只有扩容后容量达到 64，且那个桶的链表长度依然 ≥ 8，才会真正调用 treeifyBin() 构建红黑树。
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 容量小的时候链表长，大概率是扩容没跟上，不是真有严重哈希冲突
- 红黑树结构更复杂，内存开销大，在小表中得不偿失
- 64 是经验平衡值，兼顾哈希分布合理性与结构维护成本
转换还依赖 key 的可比较性
树化过程要求 key 类型能排序：要么实现了 Comparable 接口，要么构造 HashMap 时传入了 Comparator。否则 treeifyBin() 会静默失败，继续维持链表结构。
-
TreeNode是Node的子类，保留next引用，方便后续退化回链表 - 阈值 8 来自泊松分布推导（λ = 0.5 时 P(X ≥ 8) ≈ 10⁻⁶），代表极小概率的异常哈希聚集
红黑树也会退化回链表
当树中节点数因删除操作减少到 ≤ 6（UNTREEIFY_THRESHOLD）时，HashMap 会在下一次 resize 或树结构操作中将其转回链表。
- 节点少时，链表的遍历开销接近常数，比维护树平衡更轻量
- 退化不是实时发生，而是在 resize 或 remove 后的树结构调整阶段统一处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
