linkedhashset 迭代顺序与插入顺序一致，因其底层用双向链表维护插入顺序，add() 时同步更新哈希表和链表尾部，迭代按链表而非哈希桶进行，且仅保证插入顺序，不支持访问顺序。
LinkedHashSet 的迭代顺序为什么和插入顺序一致
因为底层用双向链表维护插入顺序，每次 add() 时不仅把元素加进哈希表，还把它追加到链表尾部。迭代时按链表顺序走，不是按哈希桶顺序。
注意：这个“顺序”仅指插入顺序，不是访问顺序（LinkedHashSet 不支持像 LinkedHashMap 那样开启 access-order 模式）。
- 链表节点同时持有
next和prev引用，删除中间元素时能 O(1) 调整前后连接 - 哈希表负责 O(1) 查重，链表负责保序，两者通过同一个 Entry 对象耦合（
LinkedHashMap.Entry子类） - 构造时传
initialCapacity和loadFactor只影响哈希表部分，不影响链表行为
为什么 contains() 快但迭代慢于 ArrayList
contains() 是哈希查找，平均 O(1)；但迭代要顺着链表指针一个个跳，缓存局部性差——每个节点在内存中不连续，CPU 预取效率低。
对比：ArrayList 迭代是连续内存读，现代 CPU 能提前加载后续数据块；LinkedHashSet 迭代则频繁触发随机内存访问。
立即学习“Java免费学习笔记（深入）”；
- 如果只做去重 + 后续大量遍历，且元素数量大（>10k），考虑先转成
ArrayList再遍历 -
size()是 O(1)，因为内部维护了size计数器，不是遍历链表算的 - 不要在循环里反复调用
iterator().hasNext()—— 虽然开销小，但链表节点引用跳转本身就有成本
clear() 后内存是否立即释放
不会。调用 clear() 只是断开链表首尾、清空哈希桶数组，并把所有节点的 key/next/prev 置为 null，但节点对象仍留在堆上，等 GC 回收。
容易被忽略的是：如果节点里存的是大对象（比如 byte[] 或自定义大 POJO），而你又在 long-lived 的 LinkedHashSet 实例里反复 add/clear，可能引发老年代碎片或 GC 压力。
- 频繁增删场景下，优先用新实例替代复用 +
clear()，避免残留引用干扰 GC -
clear()不会重置内部链表头尾指针为新对象，只是把它们设为null，下次add()会重建链表 - 没有类似
System.gc()的强制回收机制，别指望clear()立刻腾出堆空间
和 TreeSet、HashSet 在顺序上的关键区别
HashSet 完全无序（取决于 hashcode 分布和扩容时机）；TreeSet 是按自然序或比较器排序，和插入无关；只有 LinkedHashSet 死守插入顺序。
但要注意：这个“插入顺序”是针对成功插入的元素。重复元素被 add() 拒绝时，不改变已有顺序，也不触发链表操作。
-
add()返回false时，链表和哈希表都完全不变 - 如果用
addAll()批量添加，顺序由集合参数的迭代顺序决定，不是代码书写顺序 - 多线程环境下不加同步，顺序保障失效——
LinkedHashSet不是线程安全的，竞态可能导致链表断裂或哈希表状态错乱
