是的，hashset底层完全基于hashmap实现，元素作为key、present对象作为value存储，所有哈希逻辑、扩容、null处理及遍历顺序均由hashmap决定。
HashSet底层真用HashMap存元素？
是的，HashSet 内部几乎完全依赖 HashMap 实现——它不自己管理哈希表、不重写扩容逻辑、连 hash() 和 resize() 都直接复用 HashMap 的。唯一“伪装”是把每个元素当 key，统一塞进一个固定值 PRESSENT（即 static final Object PRESENT = new Object()）作为 value。
所以你调 set.add("a")，实际执行的是 map.put("a", PRESENT)；set.contains("a") 就是 map.containsKey("a")。
- 所有
HashSet的行为（比如 null 允许、线程不安全、初始容量 16、负载因子 0.75）都来自它持有的那个HashMap - 构造时传的
initialCapacity或loadFactor，最终全交给HashMap构造器，HashSet自己没任何存储结构 - 别指望
HashSet有独立的哈希算法——它的hashCode()计算、冲突处理、红黑树转换阈值（8），全是HashMap的规则
为什么add(null)能成功，但遍历时不会报NPE？
因为 HashMap 明确允许 null 作为 key（只允许一个），HashSet 继承了这个特性。它把 null 当作一个合法的 key 存进底层 HashMap 的第一个桶里，不触发任何异常。
但要注意：只要集合里加过 null，后续调 contains(null) 或 remove(null) 都走的是 HashMap 的特殊 putForNullKey() / getForNullKey() 分支，不是通用哈希路径。
立即学习“Java免费学习笔记（深入）”；
-
null的 hash 值被硬编码为 0，不调用对象的hashCode()方法 - 如果元素类的
hashCode()本身返回 0，和null不会冲突——HashMap用 == 判断 key 是否为 null，再用 equals 判断非 null key，机制隔离得很清楚 - 别在
HashSet上做 null 安全假设：它不阻止你加 null，但也不帮你做 null 检查，遍历中遇到 null 仍需自己判空
HashSet遍历顺序真的“完全随机”？
不是随机，是“由 HashMap 底层桶数组索引顺序 + 链表/红黑树节点插入顺序共同决定”，且 JDK 8 后因引入红黑树和扰动函数，同一组数据在不同 JVM 启动下表现可能不一致。
关键点在于：HashSet 迭代器本质是遍历 HashMap 的 keySet()，而 keySet() 迭代器返回的是桶数组从 index 0 开始逐个扫描，对每个非空桶再按链表或树的自然顺序访问节点。
- 插入顺序不影响遍历顺序（区别于
LinkedHashSet） - 哪怕只插 3 个元素，如果它们的 hash 值恰好落在桶数组末尾三个位置，遍历就从那开始，看起来像“倒序”
- JDK 7 和 JDK 8 的扰动函数不同，相同字符串在不同版本里算出的 hash 可能不同，导致落桶位置变化 → 遍历顺序变
想保持插入顺序，该换什么？别改HashSet参数
HashSet 的构造参数对顺序毫无影响——无论你设 initialCapacity=100 还是 loadFactor=0.1f，都不改变它无序的本质。要顺序，必须换实现。
最直接的选择是 LinkedHashSet：它继承 HashSet，但底层用的是 LinkedHashMap，额外维护一个双向链表记录插入顺序。开销极小（仅多两个引用字段），API 完全兼容。
-
LinkedHashSet的add()时间复杂度仍是 O(1) 均摊，只是常数略大 - 它同样允许 null，同样线程不安全，同样用
HashMap那套哈希逻辑，只是迭代时绕链表走而不是扫桶数组 - 别试图用
TreeSet替代——它按自然序或比较器排序，不是插入序；而且要求元素可比较，hashCode()和equals()也得配合，约束更强
真正容易被忽略的是：很多人以为“初始化容量大就能让顺序稳定”，其实只要底层还是 HashMap，顺序就永远不可控——它取决于 hash 值与当前容量取模的结果，而容量会动态扩容，模运算结果必然漂移。
