linkedhashset 能记住插入顺序是因为其底层使用 linkedhashmap，新节点同时挂入哈希桶和双向链表尾部；hashset 无此链表结构，迭代顺序不可控且与 hashcode() 无关。
为什么 LinkedHashSet 能记住插入顺序，而 HashSet 不能
根本区别不在“链表”或“哈希表”这些词本身，而在内部如何组织节点。LinkedHashSet 底层用的是 LinkedHashMap，每个元素作为 key 存入，value 固定为 PRESENT（一个静态哨兵对象）；而 LinkedHashMap 在插入时会把新节点同时挂到哈希桶里、也追加到双向链表尾部——顺序就靠这条链表维持。
常见错误现象：HashSet 迭代输出看似有序，其实是巧合（小容量+哈希分布均匀），扩容后立刻乱序；有人误以为重写 hashCode() 就能控制 HashSet 遍历顺序，其实完全无效。
-
LinkedHashSet的迭代顺序 = 第一次add()的顺序，与hashCode()或equals()实现无关 - 不支持按访问顺序排列（那是
LinkedHashMap设置accessOrder=true的事，LinkedHashSet没这开关） - 构造时传入
initialCapacity和loadFactor会影响哈希部分性能，但不影响顺序逻辑
LinkedHashSet 的构造和初始化陷阱
最常踩的坑是误用带 Collection 参数的构造方法：它按集合的 iterator() 顺序插入，不是按原始容器“物理存储顺序”。比如传入 TreeSet，得到的是排序后的顺序；传入另一个 LinkedHashSet，才是原样复刻。
使用场景：从数据库查出 List 后去重并保序，别先转成 HashSet 再塞进 LinkedHashSet——那顺序早丢了。
- 安全做法：
new LinkedHashSet(list)，list是原始有序集合 - 危险写法：
new LinkedHashSet(new HashSet(list))—— 顺序彻底不可控 - 注意空集合：传
null直接抛NullPointerException，要判空
和 ArrayList 去重比，LinkedHashSet 真的更优吗
只看“保序+去重”，LinkedHashSet 是标准解，但代价是额外哈希表开销（每个元素至少 32 字节对象头 + 引用 + 链表指针）。如果数据量小（ArrayList 手动遍历检查反而更快且省内存。
性能影响点：插入耗时 O(1) 均摊，但首次扩容触发 rehash 时会有明显停顿；迭代是 O(n)，比 ArrayList 稍慢（要跳链表指针，缓存局部性差）。
- 重复率高 + 数据量大（>1k）→ 无条件选
LinkedHashSet - 重复率低 + 总数 ArrayList +
contains()可能更轻量 - 别为了“看起来高级”在日志收集等短生命周期场景硬套
LinkedHashSet
序列化时 LinkedHashSet 的顺序还能保住吗
能，但仅限于用 Java 原生 ObjectOutputStream。它的 writeObject() 方法明确按链表顺序逐个写出元素，反序列化时重建链表结构，顺序不变。
容易被忽略的地方：用 JSON 库（如 Jackson、Gson）序列化时，默认把 LinkedHashSet 当作普通 Set 处理，输出是无序数组；除非显式配置保留顺序（如 Jackson 的 SerializationFeature.ORDER_MAP_ENTRIES_BY_KEYS 对 Map 有效，但对 Set 无效——它根本不保证 Set 序列化顺序）。
- 跨语言/跨格式传输时，别依赖
LinkedHashSet的顺序自动延续 - 需要 JSON 保序？先转成
ArrayList再序列化，或者自定义序列化器 - 注意
readObject()中的put()调用仍是按写入顺序执行，顺序逻辑没断
