hashset底层直接使用hashmap实例，通过组合模式将元素作为key、固定哑对象present作为value存储，从而实现去重；其线程不安全，且依赖正确的equals和hashcode实现。
HashSet底层就是HashMap，只是把value固定成一个哑对象
HashSet不是“类似”HashMap，而是**直接持有HashMap实例**，所有add、remove、contains操作最终都委托给内部的map.put()或map.containsKey()。关键就藏在JDK源码里：private transient HashMap<e> map;</e>，而那个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。
立即学习“Java免费学习笔记（深入）”；
- 别为了省一个类，强行用HashMap模拟Set：比如用
map.put(id, null)，既违背直觉，又浪费内存（null也是对象引用） - 别在HashSet里塞大量null——虽然允许，但容易引发NPE，且和HashMap的null-key处理逻辑混在一起，排查困难
- LinkedHashSet是个特例：它用的是
LinkedHashMap，所以能保插入序；但你不能指望普通HashSet有序——那是幻觉
map.put()一路查到你的hashCode()实现里去。 
