HashSet遍历顺序不固定，因其底层基于HashMap的哈希桶分布受hashCode、容量、JDK版本等影响；需插入顺序用LinkedHashSet，需排序用TreeSet。
HashSet 的遍历顺序为什么每次都不一样？
因为 HashSet 底层用的是 HashMap，而哈希表的桶（bucket）位置由元素的 hashCode() 决定，再结合当前容量取模。JDK 不同版本、扩容时机、甚至 JVM 启动参数都可能影响哈希桶的分布——所以你看到的迭代顺序是“实现细节”，不是设计承诺。
- 哪怕插入顺序完全相同，
HashSet两次运行输出顺序也可能不同 - Java 8 开始引入树化阈值（链表长度 ≥8 且 table size ≥64 时转红黑树），这进一步让顺序更不可预测
- 不要在日志、测试断言或 UI 渲染中依赖
HashSet.iterator()的顺序——它随时可能变
想保留插入顺序？别硬刚 HashSet，换 LinkedHashSet
如果你需要“去重 + 按插入顺序遍历”，LinkedHashSet 就是专为此设计的：它在哈希表基础上加了双向链表维护插入序，时间复杂度仍是平均 O(1)，空间略增但几乎可忽略。
-
LinkedHashSet是HashSet的子类，API 完全兼容，替换成本极低 - 注意：它只保证「插入顺序」，不保证「访问顺序」（那是
LinkedHashMap的accessOrder=true模式） - 如果后续还要支持排序（比如按字母、数值大小），那就该考虑
TreeSet，而不是在LinkedHashSet上额外排序
强行给 HashSet 排序的三种常见写法和坑
真要排序，本质是放弃 HashSet 的原生能力，转为其他结构处理。最常踩的坑是以为 Collections.sort() 能直接作用于 HashSet——它不能，必须先转成 List。
- 方式一（推荐）：
new ArrayList(set)→Collections.sort(list)→ 遍历list；适合一次性排序、后续只读 - 方式二：用
TreeSet构造器接收HashSet：new TreeSet(set)；自动按自然序排，但要求元素实现Comparable或传入Comparator - 方式三（危险）：反复
set.stream().sorted().collect(Collectors.toCollection(HashSet::new))——结果又变回无序！HashSet会丢掉排序信息
HashSetset = new HashSet<>(); set.add("banana"); set.add("apple"); set.add("cherry"); // ✅ 正确：转 List 后排序 List
sorted = new ArrayList<>(set); Collections.sort(sorted); // ❌ 错误：看似排序了，但 collect 到 HashSet 后顺序丢失 Set
broken = set.stream().sorted().collect(Collectors.toCollection(HashSet::new));
为什么不能靠重写 hashCode() 让 HashSet “看起来有序”？
有人试图让自定义对象的 hashCode() 返回递增整数来“控制顺序”，这是典型误解。HashSet 不按哈希值大小排列元素，而是按 hash & (table.length - 1) 算出桶索引，桶内再用链表或树组织——哈希值本身不参与排序逻辑。
立即学习“Java免费学习笔记（深入）”；
- 即使所有
hashCode()是 1、2、3…，只要桶数量是 16，它们大概率被散列到不同桶里，遍历顺序仍由桶数组索引 + 链表/树内部结构决定 - 更严重的是：修改对象状态导致
hashCode()变化后，该对象在HashSet中将无法被contains()或remove()正确定位，等于“逻辑丢失” - 真正需要可控顺序，请从集合选型入手，而不是在哈希算法上做手脚
实际项目里，90% 的“HashSet 顺序问题”其实源于一开始没分清需求：是要「唯一性」，还是要「唯一性+顺序」，还是「唯一性+排序」。选错集合类型，后面所有 workaround 都是在给技术债计息。
