17370845950

LinkedHashSet兼顾去重与插入顺序：基于哈希表判重、双向链表维护添加顺序，遍历时严格按插入先后返回；支持null，不支持排序或访问顺序，线程不安全。

解决去重与顺序兼顾的刚需

HashSet能高效去重，但遍历顺序不可控；TreeSet能排序，却强制按自然序或比较器重排。LinkedHashSet正好填补这个空缺：它既像HashSet一样靠哈希表保证唯一性，又用双向链表把每次添加的元素按顺序串起来。结果就是——插入时自动去重，遍历时严格按添加先后返回。

底层怎么做到“插得进、排得准、找得快”

它其实复用了LinkedHashMap的底层结构：哈希表负责快速定位和判重（基于hashCode()和equals()），双向链表（带before和after引用）则在每次add()成功后，把新节点追加到链表尾部。这样，哪怕哈希桶位置是散乱的，迭代器只需顺着链表从头走到尾，就能还原出原始插入序列。

• 添加重复元素时，哈希表判定已存在 → 不插入链表，也不报错
• 允许一个null值，其hashCode()为0，同样参与链表维护
• 不支持访问顺序（如LRU），只认插入顺序 —— 这点和LinkedHashMap的构造参数不同

哪些场景下它是最优解

只要需求同时满足“不能有重复”和“谁先来就谁在前”，LinkedHashSet基本就是开箱即用的选择：

• 解析配置文件行，去重后仍要保持原始配置项顺序
• 记录用户操作流水，过滤掉连续重复点击，但时间先后必须清晰
• 构建轻量级事件缓冲区，接收消息并去重，同时按到达顺序分发
• 替代手动用ArrayList逐个检查再添加的低效去重逻辑

使用时需留意的关键细节

它不是万能银弹，几个实际开发中容易踩的点得提前知道：

• 线程不安全：多线程写入需包装成Collections.synchronizedSet()或加锁
• 性能略低于HashSet：多维护链表节点，内存稍高、插入稍慢，但日常业务几乎无感
• 对象状态别乱改：如果往集合里放的是自定义对象，后续修改了影响hashCode()或equals()的字段，可能导致查不到、删不掉甚至破坏链表结构
• 不支持排序：它不会对字符串按字典序排，也不会对数字从小到大排，只忠于你调用add()的那一瞬间的顺序