链表树化阈值为8、退化阈值为6，是jdk 8 hashmap在性能、空间与稳定性间的最优权衡：8基于泊松分布概率极低，触发树化降为o(log n)；6设缓冲带避免结构震荡；且仅当数组容量≥64时生效，小表优先扩容。
链表树化阈值设为 8、退化阈值设为 6，是 JDK 8 中 HashMap 在时间效率、空间开销与结构稳定性之间权衡后的工程最优解。
树化阈值 8：性能拐点与概率依据
在理想哈希分布（负载因子 0.75）下，桶中节点数量服从泊松分布，链表长度达到 8 的概率仅为约 0.00000006。这意味着：出现长度 ≥8 的链表，极大概率说明哈希质量差或数据异常，线性查找已明显拖累性能。此时引入红黑树，能将单桶操作从 O(n) 降为 O(log n)，收益显著。
- 低于 8（如设为 6 或 7）会过早树化：TreeNode 占用内存约为普通 Node 的 2 倍，频繁创建树节点浪费空间，且树的插入/旋转本身有额外开销
- 高于 8（如设为 9 或 10）则风险滞后：极端冲突下链表可能长达十几甚至几十，查询延迟陡增，失去兜底意义
退化阈值 6：避免结构震荡的缓冲设计
树化后若节点数小幅波动（比如删一个变 7、再删一个变 6），不能立刻退化；否则会在 7–8 附近反复树化与退化，引发大量节点重建、颜色重染、旋转调整等高成本操作。
- 设为 6 而非 7 或 8，留出 2 个节点的“缓冲带”，使结构切换具备迟滞特性
- 当节点 ≤6 时退化回链表，不仅节省内存（去掉 color、parent、left、right 等字段），也简化了 get/put/remove 的执行路径
- 这个不对称设计（8 树化、6 退化）本质是“高低水位”机制，类似操作系统中的缓存换入换出策略，目标是减少抖动
两个阈值必须配合数组容量条件（≥64）才生效
仅链表长 ≥8 不足以触发树化——如果数组总长度还不到 64（例如刚初始化的默认容量 16），说明冲突主因是桶太少，而非哈希问题。此时优先扩容（翻倍），让原有节点重新散列，自然缓解链表压力，比建树更轻量高效。
- 扩容是空间换时间，树化是结构换时间；小表用扩容，大表用树化，分工明确
- MIN_TREEIFY_CAPACITY = 64 是经验值：小于该值时，扩容性价比更高；达到或超过时，说明散列能力已接近瓶颈，需升级数据结构
源码注释直接印证这一逻辑
HashMap 源码中明确写着：
/* Because TreeNodes are about twice the size of regular nodes, we* use them only when bins contain enough nodes to warrant use
* (see TREEIFY_THRESHOLD). And when they become too small (due to
* removal or resizing) they are converted back to plain bins. */
这段话强调两点：TreeNode 成本高，所以只在“足够多”（即 ≥8）时启用；而一旦“太小”（即 ≤6），就还原为普通 bin，不恋战、不冗余。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
