当需元素唯一且按插入顺序遍历时应选linkedhashset；它用哈希表+双向链表实现，遍历稳定o(n)，顺序可预测，而hashset无序、treeset按自然序排序。
什么时候该用 LinkedHashSet 而不是 HashSet
当你既要元素唯一（去重），又必须按插入顺序遍历，LinkedHashSet 就是标准解法。它底层用哈希表 + 双向链表实现，比 HashSet 多一点内存开销，但遍历性能稳定（O(n)），且顺序可预测。
常见错误现象：HashSet 遍历时顺序“乱跳”，尤其在 JDK 8+ 后，哪怕你反复插入相同元素，顺序也可能变——这不是 bug，是设计使然；想靠它保序纯属误用。
- 适用场景：日志事件去重后按发生时间展示、配置项加载后保持声明顺序、API 返回结果需确定性排序
- 不适用场景：只查不遍历、对内存极度敏感（比如嵌入式）、顺序完全无关（此时
HashSet更轻） - 注意：
LinkedHashSet的迭代顺序 = 插入顺序，不是访问顺序；想按最近访问排序得用LinkedHashMap+ 自定义逻辑
LinkedHashSet 和 TreeSet 都能保序，怎么选
TreeSet 是按自然序或比较器排序，LinkedHashSet 是按插入序——这是根本区别。别因为“都能遍历出固定顺序”就混用。
典型踩坑：TreeSet 插入 new Integer(2)、new Integer(1)、new Integer(3)，遍历出来是 1,2,3；而 LinkedHashSet 会严格输出 2,1,3。
- 插入/查找性能：
LinkedHashSet平均 O(1)，TreeSet是 O(log n)，数据量大时差距明显 - 内存占用：
LinkedHashSet每个节点存两个指针（前驱/后继），TreeSet存三个（左/右/父），但差异通常可忽略 - 兼容性：
LinkedHashSet不要求元素实现Comparable或传Comparator，TreeSet强制需要
构造 LinkedHashSet 时传初始容量和负载因子要注意什么
和 HashSet 一样，LinkedHashSet 构造函数支持指定初始容量和负载因子，但链表部分的开销是额外叠加的——扩容不仅重建哈希桶，还要重建整条链表。
错误用法：new LinkedHashSet(1) 看似省空间，实际触发频繁扩容（默认负载因子 0.75，插第 1 个元素就可能触发第一次扩容）。
- 建议初始容量设为预估元素数 ÷ 0.75 向上取整，比如预计存 100 个，用
new LinkedHashSet(136) - 负载因子别乱调：设太高（如 0.9）会增加哈希冲突，拖慢查找；设太低（如 0.5）浪费内存且扩容更勤
- 注意：构造时传
Collection（如new LinkedHashSet(list)）会按集合大小预分配，但不会自动优化链表结构，仍可能触发一次扩容
序列化 LinkedHashSet 时顺序还能保证吗
能。它的 writeObject 方法明确按链表顺序写入元素，反序列化时也按此顺序重建，所以跨 JVM 或存文件后读回，插入顺序依然可靠。
但容易被忽略的一点：如果元素自身不可序列化，或用了自定义 readObject 却没维护链表逻辑，顺序就可能丢失——这不是 LinkedHashSet 的问题，而是整个序列化链路的责任。
- 验证方法：序列化后用
ObjectInputStream读出，检查iterator()返回的顺序是否与原始一致 - 注意：
serialVersionUID变更不影响顺序，但类结构大改（比如删了链表字段）会导致反序列化失败 - 替代方案：若对序列化格式有强控需求（比如要 JSON），别依赖 Java 原生序列化，手动转成
List再序列化更稳妥
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
