HashSet与HashMap的关联及组合模式应用

HashSet并非 merely“类似”HashMap，而是直接通过组合模式内嵌一个HashMap实例，将元素作为key、固定哑对象PRESENT作为value存储，从而天然获得去重能力；它严格封装了键值对语义，只暴露Set接口，既复用了HashMap全部底层机制（如哈希计算、扩容、红黑树转换），又避免了继承带来的API污染与契约破坏；其行为完全受equals和hashCode实现支配——二者出错不会抛异常，却会导致contains失效、重复添加或查找丢失等静默故障；理解这一关联，不仅能避开线程不安全、可变字段影响哈希定位、误用null等常见陷阱，更能从根本上把握集合设计的职责分离思想与高性能哈希结构的本质。

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的关联及组合模式应用》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！