HashSet添加元素触发树化的条件是：桶中链表长度≥8且数组长度≥64，否则仅扩容；树化发生在putVal()末尾的treeifyBin()调用处，且需满足table.length>=64。
HashSet添加元素时哈希冲突怎么触发树化
Java 8+ 的 HashSet 底层是 HashMap，真正处理碰撞的是其桶（bucket）里的 Node 结构。当同一个桶里链表长度 ≥ 8 且 当前数组长度 ≥ 64，才会转成红黑树；否则只扩容。
常见错误现象：手动往小容量 HashSet（比如 new HashSet(4)）里塞 8 个同 hash 值对象，发现还是链表——不是不树化，是没满足数组长度 ≥ 64 这个硬条件。
- 树化前提是
table.length >= 64，这个值在构造时不会预设，而是随 put 触发 resize 才增长 - 同 hash 值的元素必须落到同一个桶，取决于
hash & (table.length - 1)计算结果，不是单纯看hashCode()是否相等 - 如果 key 类型没重写
equals()和hashCode()，默认用 Object 实现，那几乎不可能出现哈希碰撞（除非是同一个对象）
为什么链表长度阈值是 8 而不是 7 或 9
这个数字来自泊松分布的概率推导：当哈希函数均匀、负载因子为 0.75 时，单个桶内元素数 ≥ 8 的概率已低于百万分之一。选 8 是在“避免过早树化开销”和“防止链表过长拖慢查找”之间权衡的结果。
实际影响很直接：如果你的自定义 key 的 hashCode() 写得差（比如永远返回 1），哪怕只放 10 个元素，也会让某个桶迅速堆积，此时查找时间从 O(1) 退化到 O(n)，而树化能拉回 O(log n)。
立即学习“Java免费学习笔记（深入）”；
- 树化后节点类型从
Node变成TreeNode，内存占用翻倍以上 - 小数据量下树化反而更慢，所以 JDK 宁可先扩容两次（16→32→64）再考虑树化
- 只要数组没扩容到 64，就算链表到了 100，也不会树化——这点容易被忽略
Treeify 的具体触发点在 putVal() 里的哪一行
关键逻辑在 HashMap.putVal() 方法末尾的 treeifyBin() 调用处。它不直接树化，而是先检查 tab.length （即 64），满足则触发 resize()；不满足才调用 <code>treeify() 真正转树。
你可以用反射或调试器断点在 HashMap.java:789（JDK 8u291 行号）附近观察——但别在线上环境这么干。
-
treeifyBin()是 package-private 方法，外部不可调用 - 即使你手动调用
resize()把数组撑到 64，也得再触发一次 put 才可能走树化路径 - 如果当前桶里有
null或非Node类型节点（比如正在扩容中的ForwardingNode），树化会跳过
自定义类做 HashSet 元素时怎么避免意外碰撞
根本问题不在 HashSet，而在你的 hashCode() 实现是否合理。例如用 String 拼接字段但忘了 null 安全，或者用浮点数做 hash 源，都会导致本不该相等的对象被判定为相同桶位。
一个典型翻车场景：把 BigDecimal 当 key，却用 doubleValue() 生成 hash——精度丢失后多个不同值映射到同一 hash，链表就起来了。
- 优先用
Objects.hash(field1, field2)，它自动处理 null - 避免在
hashCode()里调用可能抛异常或耗时的方法（如 DB 查询、IO） - 如果字段含浮点数，用
Double.doubleToLongBits()而不是直接 (int)value - 重写
hashCode()后必须同步重写equals()，否则HashSet查找失效
树化不是兜底方案，是补救措施。真正要盯住的，是你自己写的 hashCode() 有没有让本该分散的数据挤进同一个桶。
