HashSet与HashMap关系及代码复用方法

HashSet并非 merely 类似 HashMap，而是直接通过组合模式复用 HashMap 实例——将元素作为 key、固定哑对象 PRESENT 作为 value 存储，从而零成本获得哈希表的高效去重能力；这种设计既严格遵循 Set 接口契约、避免继承带来的接口污染，又无缝复用了 HashMap 的扩容、红黑树优化等全部底层机制，但同时也意味着：一旦自定义类的 equals 和 hashCode 实现有误（如未同步重写、使用可变字段），HashSet 的“不重复”将静默失效，且问题根源必须追溯到 HashMap 的 key 比较逻辑中——理解这一深层关联，是写出健壮集合代码的关键。

HashSet底层就是HashMap，只是把value固定成一个哑对象

HashSet不是“类似”HashMap，而是**直接持有HashMap实例**，所有add、remove、contains操作最终都委托给内部的map.put()或map.containsKey()。关键就藏在JDK源码里：private transient HashMap map;，而那个Object值是静态常量PRESENT = new Object()。

• 每次调用hashSet.add("abc")，实际执行的是map.put("abc", PRESENT)
• 因为HashMap的key天然不可重复，所以HashSet自动获得去重能力
• 你无法从HashSet里拿到“value”，因为它根本没暴露——那层语义被彻底屏蔽了

为什么不用继承HashMap，而要用组合（Adapter模式）

如果HashSet继承HashMap，就会被迫暴露get()、put(K,V)等键值对接口，破坏Set的契约（只管元素，不管键值）。组合则严格隔离职责：HashSet只实现Set接口，HashMap只负责哈希存储逻辑。

• 复用不等于暴露：HashMap的扩容、红黑树转换、哈希扰动等全部机制都被无缝继承，但使用者完全无感
• 修改成本低：未来若换成ConcurrentHashMap做底层，只需换构造器里的map实例，HashSet API完全不变
• 注意陷阱：别误以为HashSet线程安全——它用的仍是普通HashMap，多线程写入会出错

你改equals和hashCode时，其实同时影响HashSet和HashMap的key行为

无论你是在HashSet里存对象，还是在HashMap里当key，判断“是否相等”的逻辑完全一致：先比hashCode()，再调equals()。这两个方法没写对，contains()就可能返回false，哪怕对象内容一模一样。

• 常见错误：只重写了equals()，忘了同步改hashCode() → HashSet里add两次同一对象，结果出现两个
• 另一个坑：用可变字段（比如name）参与hashCode()计算，之后又改了name → 对象再也找不到了（哈希桶位置已变）
• 验证技巧：往HashSet加对象后，立刻用set.contains(obj)测试；再把它放进HashMap当key，用map.get(obj)再试一次——结果必须一致

性能上它们共享同一套哈希机制，但使用意图决定API选择

插入/查找都是O(1)均摊复杂度，背后都是数组+链表/红黑树的哈希桶结构。区别只在语义层：你要存“唯一值集合”，就用HashSet；要存“ID→用户信息映射”，就用HashMap。

• 别为了省一个类，强行用HashMap模拟Set：比如用map.put(id, null)，既违背直觉，又浪费内存（null也是对象引用）
• 别在HashSet里塞大量null——虽然允许，但容易引发NPE，且和HashMap的null-key处理逻辑混在一起，排查困难
• LinkedHashSet是个特例：它用的是LinkedHashMap，所以能保插入序；但你不能指望普通HashSet有序——那是幻觉

实际编码时，最易被忽略的是：**HashSet的“不重复”完全依赖HashMap的key规则，而这个规则一旦被自定义类破坏，问题不会报错，只会静默失效**。调试时别只盯HashSet代码，得顺着map.put()一路查到你的hashCode()实现里去。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~