随缘惜情1. 为什么Java集合需要去重？
在日常开发中，我们经常遇到这样的场景：从数据库查询返回了重复记录、日志分析时出现大量重复条目、用户提交的表单包含重复数据。这些重复元素不仅浪费内存空间，更会导致统计结果失真、业务逻辑出错。比如电商系统中，如果购物车集合包含重复商品ID，结算时就会错误计算总价。
Java集合框架提供了多种数据结构来处理这类需求，但选择不当会导致性能问题。我曾维护过一个订单处理系统，最初使用ArrayList存储订单号，当数据量达到10万级别时，去重操作竟耗时超过2秒。后来改用HashSet重构，同样数据量处理时间降至毫秒级。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 基础去重方法对比
2.1 使用HashSet暴力去重
这是最直接的方法，利用Set接口不允许重复元素的特性：
java复制List<String> listWithDuplicates = Arrays.asList("a", "b", "c", "a");
Set<String> set = new HashSet<>(listWithDuplicates);
List<String> listWithoutDuplicates = new ArrayList<>(set);
底层原理：HashSet基于HashMap实现，添加元素时先计算hashCode定位桶位置，再用equals方法比较。当两个对象hashCode相同且equals返回true时，视为相同元素。
注意：自定义对象需要正确重写hashCode和equals方法，否则去重会失效。我曾踩过坑，一个Employee类没重写hashCode，导致相同ID的员工对象被误判为不同元素。
2.2 利用LinkedHashSet保持顺序
如果需要保留原始顺序：
java复制Set<String> linkedHashSet = new LinkedHashSet<>(listWithDuplicates);
List<String> orderedList = new ArrayList<>(linkedHashSet);
性能对比：
| 方法 | 时间复杂度 | 空间复杂度 | 是否保序 |
|---|---|---|---|
| HashSet | O(n) | O(n) | 否 |
| LinkedHashSet | O(n) | O(n) | 是 |
| TreeSet | O(n log n) | O(n) | 是 |
2.3 Java8 Stream API方案
在Lambda表达式支持下更简洁：
java复制List<String> distinctList = listWithDuplicates.stream()
.distinct()
.collect(Collectors.toList());
实现原理：distinct()内部维护一个HashSet来记录已出现元素。有趣的是，在并行流中，它会使用ConcurrentHashMap保证线程安全。
3. 高级去重技巧
3.1 自定义对象去重策略
当需要根据对象特定字段去重时：
java复制List<Employee> employees = // 获取员工列表
List<Employee> distinctEmployees = employees.stream()
.collect(Collectors.collectingAndThen(
Collectors.toMap(
Employee::getId,
Function.identity(),
(oldValue, newValue) -> oldValue
),
map -> new ArrayList<>(map.values())
));
实战经验：对于大型集合，可以先使用parallelStream()并行处理。但在我的压力测试中，数据量小于1万时串行流反而更快，因为线程切换有开销。
3.2 使用TreeSet自定义排序
需要排序去重时：
java复制Set<String> treeSet = new TreeSet<>(String.CASE_INSENSITIVE_ORDER);
treeSet.addAll(listWithDuplicates);
陷阱警示：TreeSet使用compareTo而非equals判断相等性。如果Comparator认为两个元素相等（compareTo返回0），即使equals返回false也会去重。
3.3 Guava库的优雅方案
Google Guava提供了更多选择：
java复制// 保持首次出现顺序
ImmutableSet<String> immutableSet = ImmutableSet.copyOf(listWithDuplicates);
// 多字段去重
ImmutableList<Employee> uniqueEmployees = ImmutableList.copyOf(
Multimaps.index(employees, Employee::getDepartment).asMap().values()
.stream()
.flatMap(Collection::stream)
.collect(Collectors.toList())
);
4. 性能优化与特殊场景
4.1 大数据量分块处理
当处理百万级数据时，可以分批处理避免OOM：
java复制List<String> hugeList = // 超大数据集
Set<String> distinctSet = new HashSet<>(1000000); // 预分配容量
int batchSize = 100000;
for (int i = 0; i < hugeList.size(); i += batchSize) {
distinctSet.addAll(hugeList.subList(i, Math.min(i + batchSize, hugeList.size())));
}
调优经验：HashSet初始容量应设为(元素数量/负载因子)+1。默认负载因子0.75意味着当容量达到75%时会扩容，提前设置合理值可减少rehash开销。
4.2 内存敏感场景优化
对于内存紧张的环境，可以考虑：
- 使用
BitSet去重整数集合 - 布隆过滤器(Bloom Filter)快速判断可能存在
- 外部排序+遍历去重（适合超大数据）
java复制// BitSet示例
BitSet bitSet = new BitSet();
listOfIntegers.forEach(bitSet::set);
4.3 并发环境下的选择
线程安全方案对比：
| 方案 | 特点 | 适用场景 |
|---|---|---|
| Collections.synchronizedSet | 简单同步 | 低并发 |
| ConcurrentHashMap.newKeySet | 分段锁 | 高并发 |
| CopyOnWriteArraySet | 读多写少 | 监听器列表 |
踩坑记录：曾用CopyOnWriteArraySet处理高频更新的会话集合，导致频繁数组拷贝。改用ConcurrentHashMap后性能提升10倍。
5. 常见问题排查
5.1 去重失效问题排查
当发现去重不生效时，检查：
- 自定义类是否正确实现了hashCode/equals
- TreeSet使用的Comparator逻辑是否正确
- 并行流处理时是否有线程安全问题
诊断案例：某次JSON数据去重失败，发现是字段顺序不同导致相同数据的hashCode不同。解决方案是先用Jackson统一序列化格式。
5.2 内存溢出处理
处理海量数据时可能遇到OOM，解决方案：
- 增加JVM堆内存：
-Xmx4g - 使用WeakReference存储元素
- 改用数据库临时表去重
5.3 性能瓶颈分析
使用JMH进行基准测试样例：
java复制@Benchmark
@BenchmarkMode(Mode.AverageTime)
public void testHashSet(Blackhole bh) {
Set<Integer> set = new HashSet<>(list);
bh.consume(set);
}
测试结果可能显示：当元素数量超过100万时，LinkedHashSet的插入时间比HashSet多30%，这是维护链表带来的开销。
6. 最佳实践总结
经过多个项目实践，我的去重方案选择策略是：
- 小数据集（<1万）：Stream distinct()最简洁
- 需要保序：LinkedHashSet
- 自定义对象：重写hashCode/equals + HashSet
- 超大数据：分批处理 + 合理初始化容量
- 高并发：ConcurrentHashMap.newKeySet()
最后分享一个实用技巧：对于可能包含null的集合，使用Collections.newSetFromMap(new ConcurrentHashMap<>())比HashSet更安全，因为ConcurrentHashMap允许null值而HashSet不允许。