LinkedHashSet 严格保持插入顺序，HashSet 顺序不可预测，这是由底层结构决定的：前者维护双向链表，后者仅依赖哈希表；序列化后顺序仅在反序列化为 LinkedHashSet 时保留。
遍历顺序不一致，不是“偶然”，而是设计使然
HashSet 遍历时顺序完全不可预测；LinkedHashSet 则严格按 add() 的调用顺序返回元素。这不是 bug，也不是 JVM 版本差异，而是底层结构决定的：HashSet 仅依赖哈希桶数组 + 冲突链表/红黑树，遍历得扫描整个哈希表；LinkedHashSet 在 HashMap 基础上额外维护一条双向链表，iterator() 直接沿链表走。
- 写测试时别用
System.out.println(new HashSet(list))验证顺序——它可能某次“碰巧”对了，下次就错 - 若逻辑依赖“先添加的先处理”，比如日志去重后保持原始时间序、缓存淘汰中的 LRU 基础结构，必须选
LinkedHashSet -
TreeSet是另一条路：它按大小排序，不是插入序，别混淆
构造函数参数只管哈希表，不管链表
new HashSet(int initialCapacity, float loadFactor) 和 new LinkedHashSet(int initialCapacity, float loadFactor) 中的参数，都只影响内部哈希表的初始桶数组大小和扩容阈值，对链表部分无任何作用——链表始终存在，且随每次 add() 动态延伸。
- 给
LinkedHashSet设超大initialCapacity不会加快遍历，因为遍历走的是链表，不是哈希桶 - 但设太小会导致频繁 rehash，间接引发链表节点迁移（LinkedHashMap 的 rehash 会重建链表），带来额外开销
- 若已知最终容量，建议预估后设合理
initialCapacity（例如 100 个元素，按默认加载因子 0.75，可设为 128）
序列化后顺序是否保留？看反序列化类型
两者都实现 Serializable，但“顺序保留”只在反序列化目标类型仍是 LinkedHashSet 时生效。一旦中间经过 JSON（如 Jackson 默认转成 ArrayList）、或反序列化成 HashSet 或裸 Set 接口，插入顺序就永久丢失。
- RPC 场景中，服务端用
LinkedHashSet返回数据，客户端若用ObjectMapper.readValue(json, Set.class)，得到的是LinkedHashSet吗？不一定——Jackson 默认映射为HashSet，需显式指定TypeReference<linkedhashset>>()</linkedhashset> - 分布式缓存（如 Redis）存的是序列化字节，取回后必须确保 new 出来的是
LinkedHashSet，否则顺序不复存在 -
HashSet反序列化后依然无序，这点倒是一致且“诚实”
性能差在哪？不在查找，而在迭代与内存
插入、查找、删除平均都是 O(1)，差别几乎只体现在迭代和内存占用上：LinkedHashSet 每个节点多两个引用（before / after），典型增加 8–16 字节；迭代时链表线性访问更缓存友好，而 HashSet 要跳着读哈希桶，容易 cache miss。
立即学习“Java免费学习笔记（深入）”；
- 高频写入 + 低频遍历 → 优先
HashSet - 写入不多但遍历密集（如模板引擎中反复渲染去重后的标签列表）→
LinkedHashSet实际更稳 - 千万别为了“看起来有序”而滥用
LinkedHashSet存几万个元素却不遍历——纯属白占内存
LinkedHashSet，也序列化了，但只要下游任意一环没保持类型，顺序就断了。它不像字符串那样“内容即全部”，而是一种带结构承诺的类型——承诺了，就得从头到尾守到底。 
