深入解析HashSet底层原理_HashMap如何支撑HashSet的存储逻辑

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