HashSet.add()实际调用HashMap.put(key, PRESENT)，PRESENT为静态占位对象；去重依赖HashMap的key哈希与equals判断；不保证顺序因索引由扰动hash计算；扩容依赖HashMap.resize()，需注意线程安全与自定义类的hashCode/equals配套重写。
HashSet.add() 调用的是 HashMap.put()，但 value 固定为 PRESENT
你往 HashSet 里加一个元素，比如 set.add("hello")，表面看是集合操作，实际执行的是底层 HashMap 的 put("hello", PRESENT)。这个 PRESENT 是个静态空对象（private static final Object PRESENT = new Object()），不存业务数据，纯粹占位——它让 HashMap 的 key 成了唯一载体，value 变成“有没有”的信号灯。
- 所有
add()、contains()、remove()都在跟HashMap的 key 打交道，value 永远是同一个PRESENT - 所以
HashSet的去重逻辑完全复用HashMap的 key 冲突判断：先比hashCode()，再调equals() - 如果你自定义类放进
HashSet却没重写hashCode()和equals()，两个逻辑相等的对象可能被当成不同元素——这是最常踩的坑
为什么 HashSet 不允许重复，但不保证顺序？
因为它的底层数组（table）索引由 (n - 1) & hash 计算得出，而 hash 是经过扰动处理的 hashCode() 值，不是原始值。这个运算结果只服务于快速定位，和插入顺序、字典序、大小关系全无关联。
- JDK 8 中，当某个桶（bucket）链表长度 ≥ 8 且数组容量 ≥ 64 时，会转成红黑树——但这只是为了查得快，不影响遍历顺序
-
HashSet.iterator()遍历的是HashMap的keySet()迭代器，本质是按table数组下标从左到右、再按每个桶内节点顺序（链表或树序）走，不是插入顺序 - 如果需要有序，别硬改
HashSet，直接换LinkedHashSet（保持插入序）或TreeSet（自然序/定制序）
扩容时 HashMap 重建 table，HashSet 里的元素会“搬家”
HashSet 没有自己的扩容逻辑，它完全依赖 HashMap 的 resize()。默认初始容量 16，负载因子 0.75，意味着第 13 个元素插入时就会触发扩容——数组长度翻倍（变成 32），所有已有元素重新计算索引、搬进新数组。
- 每次扩容都要遍历全部已有元素、重新哈希、重新链表/树化，是 O(n) 开销；高频增删场景要注意控制初始容量，比如
new HashSet(expectedSize / 0.75f) - 扩容不是线程安全的，多线程往同一个
HashSet写，可能死循环（JDK 7）或数据丢失（JDK 8+），必须外加同步，或改用Collections.synchronizedSet()/ConcurrentHashMap.newKeySet() - 注意：
HashSet的size()是O(1)，但toArray()是O(n)，且返回数组不反映后续修改
自定义类做 HashSet 元素时，hashCode() 和 equals() 必须配套重写
只重写 hashCode() 或只重写 equals() 都不行。JVM 要求：如果两个对象 equals() 返回 true，它们的 hashCode() 必须相等；反之不成立。
- 反例：
Student类只重写了equals()比较 name+age，但hashCode()没重写 → 每个实例哈希值都不同 → 同样内容的两个Student在HashSet里被当成不同元素 - IDE（如 IntelliJ）能一键生成合规的
hashCode()和equals()，字段选全、别漏掉 null 判断就行 - 使用 Lombok 的
@EqualsAndHashCode也行，但要确认它覆盖的字段和你业务语义一致；若含可变字段（如 status），放进HashSet后再改，会导致无法remove()或contains()——这是隐性陷阱
HashSet 的关键不在“集”，而在“哈希”；它的简洁是借来的，它的性能是压在 HashMap 肩上的。真正难的从来不是怎么用，而是当你发现元素没去重、遍历顺序诡异、并发出错时，能不能立刻想到——该去看 HashMap 的 hash 计算、桶分布、扩容阈值，或者检查那个被忽略的 hashCode() 实现。
