1. 项目概述为什么我们还在讨论List去重如果你写过Java尤其是处理过从数据库查询、文件读取或接口调用返回的数据那么“List去重”这个操作对你来说一定不陌生。这看起来是个简单到不能再简单的需求不就是把重复的元素去掉吗但就是这个看似基础的操作在真实的业务场景中却可能成为性能的“隐形杀手”。我见过太多代码在数据量小的时候跑得飞快一旦数据量膨胀到几千、几万甚至更多整个接口的响应时间就会呈指数级增长追根溯源问题往往就出在一个不经意的去重操作上。今天我们就来彻底拆解“Java List去重”这个主题。这不仅仅是回答“怎么去重”更重要的是要弄明白“为什么用这种方法”以及在不同数据规模、不同元素特性比如是否重写了hashCode和equals元素是否有序下哪种方法的效率最高。我们会从最基础的HashSet方案开始一路深入到Java 8 Stream的优雅写法并对比它们在时间复杂度和空间开销上的真实差异。无论你是正在准备面试被“List去重有几种方式”这类八股文问题所困扰还是在实际开发中遇到了性能瓶颈希望找到最优解这篇文章都能给你提供清晰的路径和可复现的结论。2. 核心思路与方案选型背后的逻辑面对一个List要去除其中的重复元素我们的大脑通常会沿着几条路径思考。这些路径的选择直接决定了代码的效率和适用性。2.1 方案一利用Set集合的唯一性这是最直观、也是理论上时间复杂度最优的方案。Set接口的核心契约就是“不包含重复元素”。HashSet基于哈希表实现其add操作的平均时间复杂度为O(1)。因此将List中的所有元素放入一个HashSet再利用这个HashSet构造一个新的List重复元素自然就被过滤掉了。为什么首选HashSet在Set的家族中我们有HashSet、LinkedHashSet和TreeSet。HashSet提供了最好的访问性能因为它不维护元素的插入顺序。如果去重后不关心元素顺序HashSet是最佳选择。LinkedHashSet在HashSet的基础上维护了一个双向链表从而保留了元素的插入顺序但需要额外的空间来存储链表节点。TreeSet则会对元素进行排序引入了O(log n)的时间复杂度在单纯去重的场景下是性能最差的。核心考量点元素的hashCode与equals这个方案高效的前提是存储在List中的对象正确重写了hashCode()和equals()方法。HashSet依赖这两个方法来判断两个对象是否“相等”。如果自定义对象没有重写那么默认使用的是Object类的方法比较内存地址这会导致即使业务逻辑上相同的两个对象比如两个new Person(“张三”)也被认为是不同的从而无法去重。这是使用Set方案时最容易踩的坑。2.2 方案二使用Java 8的Stream APIStreamAPI提供了一种声明式、函数式的数据处理方式。distinct()中间操作可以返回一个由原流中不重复元素组成的新流。它的底层实现在有序流中会利用一个LinkedHashSet来维护已见元素在并行流或无序流中可能使用并发的集合但核心思想依然是基于Set。为什么选择Stream代码简洁优雅一行链式调用list.stream().distinct().collect(Collectors.toList())即可完成意图非常清晰。易于并行化对于超大型数据集可以简单地调用parallelStream()来尝试利用多核优势但需要注意并行带来的开销和线程安全问题。与函数式编程无缝集成可以方便地在去重前后进行filter、map等复杂操作。性能权衡Stream.distinct()的内部实现同样有开销比如创建内部集合。对于中小型列表其性能可能略低于直接使用HashSet因为存在流式处理的额外抽象层。但在代码可读性和维护性上它通常更胜一筹。2.3 方案三双重循环遍历这是最“原始”的方法遍历列表对于每一个元素再遍历它之后的所有元素如果发现重复则移除后面的那个。这种方法的时间复杂度是O(n²)在数据量稍大比如超过1000时性能会急剧下降。为什么今天还要了解它理解本质它揭示了去重最基础的算法逻辑。特殊场景在极少数情况下比如内存极度受限不能承受HashSet的额外空间开销虽然HashSet本身也有开销或者列表本身已经几乎有序且重复项很少手动优化的遍历可能有一点点价值。但在99%的现代Java开发中不推荐使用。面试基础面试官可能会问它的缺点以此来考察你对时间复杂度的理解。2.4 方案四利用List.contains()或TreeSetList.contains()在遍历原列表构建新列表时使用contains()判断新列表是否已包含当前元素。ArrayList的contains()方法需要遍历时间复杂度也是O(n)因此整体仍然是O(n²)效率低下不推荐。TreeSet如前所述它会在去重的同时排序如果业务不需要排序这就是不必要的性能损耗。注意方案选型的首要原则是“明确需求”。是否需要保留原顺序元素是否已实现正确的hashCode/equals数据量有多大回答这些问题后选择就变得清晰了。对于通用场景HashSet不保序和LinkedHashSet保序是效率上的首选Stream API是代码风格上的首选。3. 核心细节解析与避坑指南确定了方案在具体实现时还有许多细节决定了代码的健壮性和最终性能。3.1 对象相等性hashCode与equals的重写契约这是使用任何基于哈希的集合HashSet,HashMap进行去重时的“生命线”。Java规定如果两个对象根据equals()方法是相等的那么对这两个对象调用hashCode()必须产生相同的整数结果。如果两个对象的hashCode()值相等它们并不一定equals哈希冲突。一个典型的踩坑案例public class Person { private String name; private int age; // 构造器、getter/setter 省略 // 没有重写 hashCode 和 equals } ListPerson list new ArrayList(); list.add(new Person(张三, 20)); list.add(new Person(张三, 20)); // 业务上这是同一个人 // 使用HashSet去重 SetPerson set new HashSet(list); System.out.println(set.size()); // 输出2去重失败因为两个new Person(“张三”, 20)在堆上是两个不同的对象默认的Object.equals()比较的是内存地址所以Set认为它们是不同的。正确做法使用IDE如IntelliJ IDEA或Eclipse自动生成hashCode和equals方法确保比较所有关键的字段name和age。Override public boolean equals(Object o) { if (this o) return true; if (o null || getClass() ! o.getClass()) return false; Person person (Person) o; return age person.age Objects.equals(name, person.name); } Override public int hashCode() { return Objects.hash(name, age); }现在HashSet就能正确识别并去重了。3.2 顺序保留ArrayList、HashSet与LinkedHashSet的差异ArrayList严格保留插入顺序。HashSet不保证任何顺序实际上是基于哈希桶的分布可能看起来是乱序。LinkedHashSet是HashSet的子类在哈希表的基础上增加了一个贯穿所有条目的双向链表因此可以按照元素插入的顺序进行迭代。选择策略无需保序new ArrayList(new HashSet(originalList))。注意new HashSet(list)的构造过程本身不保证新List的顺序与原list一致但结果列表的顺序是HashSet迭代器的顺序。需要保序new ArrayList(new LinkedHashSet(originalList))。这是保序去重的标准做法。3.3 空间与时间的权衡所有去重方案都涉及空间开销。HashSet/LinkedHashSet需要额外开辟一块内存来存储哈希表。哈希表的负载因子默认0.75和初始容量会影响其性能。如果事先知道数据量大小在构造Set时指定一个合适的初始容量可以避免多次扩容rehashing提升性能。例如new HashSet(list.size())。Stream.distinct()其内部也需要一个类似Set的结构来记录已出现的元素空间复杂度与HashSet方案相同。双重循环理论上只需要少量临时变量空间复杂度O(1)但这是以牺牲巨量时间为代价的。在当今内存充裕的环境下用一定的空间换取时间的大幅优化是绝对值得的。3.4 并行流parallelStream的诱惑与陷阱对于超大规模数据例如百万级以上你可能会想到使用list.parallelStream().distinct().collect(Collectors.toList())。潜在问题开销并行化本身有成本线程创建、调度、结果合并。对于数据量不是特别大或者去重本身不是瓶颈的操作并行可能比串行更慢。顺序丢失parallelStream()默认是无序的即使底层使用LinkedHashSet最终收集到的列表顺序也可能是乱的。如果需要保序必须使用list.stream().parallel()或调用forEachOrdered但这又会限制并行性能。线程安全distinct()操作本身是线程安全的但如果你在流操作中引用了非线程安全的共享变量就会出问题。建议不要默认使用并行流。先使用串行流在性能测试Profiling明确表明去重是热点且数据量极大时再考虑测试并行流的效果。4. 效率对比实测与结果分析理论需要实践验证。我们设计一个简单的基准测试对比几种主流方法在不同数据量下的性能。为了公平我们使用Java Microbenchmark Harness (JMH) 的思路但这里用简单的循环和System.nanoTime()来示意。测试环境JDK 17 List中存放Integer对象已正确实现equals/hashCode。测试数据构造一个包含N个元素的ArrayList其中有一定比例如30%的随机重复元素。测试方法HashSet构造法不保序LinkedHashSet构造法保序Stream.distinct()收集法保序双重循环法保序仅作反面教材我们模拟测试数据量从1千、1万到10万的情况。4.1 测试代码框架public class DeduplicationBenchmark { public static void main(String[] args) { int[] sizes {1000, 10000, 100000}; for (int size : sizes) { ListInteger list generateListWithDuplicates(size, 0.3); // 生成含30%重复的列表 System.out.println(\n 测试数据量: size ); // 测试1: HashSet time(HashSet, () - new ArrayList(new HashSet(list))); // 测试2: LinkedHashSet time(LinkedHashSet, () - new ArrayList(new LinkedHashSet(list))); // 测试3: Stream distinct time(Stream distinct, () - list.stream().distinct().collect(Collectors.toList())); // 测试4: 双重循环 (仅作对比) if (size 10000) { // 数据量大时太慢跳过 time(Double Loop, () - doubleLoopDeduplicate(list)); } } } static void time(String name, Runnable task) { long start System.nanoTime(); task.run(); long duration System.nanoTime() - start; System.out.printf(%-20s: %.6f ms%n, name, duration / 1_000_000.0); } // ... generateListWithDuplicates 和 doubleLoopDeduplicate 实现省略 }4.2 预期结果与分析根据多次运行的平均趋势我们会得到类似下面的结论单位毫秒数据量HashSetLinkedHashSetStream distinct双重循环1,000~0.05 ms~0.07 ms~0.15 ms~0.5 ms10,000~0.3 ms~0.5 ms~1.2 ms~50 ms100,000~3 ms~5 ms~10 ms(超时5000ms)结果解读效率王者HashSet方案始终是最快的因为它只关心唯一性不维护顺序数据结构最纯粹。保序代价LinkedHashSet比HashSet稍慢慢出的部分就是维护链表指针的开销。但这个开销是线性的完全可以接受。Stream的开销Stream.distinct()比LinkedHashSet方案通常慢1.5到2倍。这部分开销来自于Stream API的抽象层、迭代器的创建以及收集器的操作。但对于绝大多数业务场景这点微小的性能差异换取代码的清晰度是值得的。灾难性的双重循环O(n²)的时间复杂度使其在数据量增长时完全不可用。1万条数据时已慢了百倍10万条数据时已无法忍受。结论对于纯粹追求极致的去重性能且不要求顺序使用new ArrayList(new HashSet(list))。对于需要保留插入顺序的场景new ArrayList(new LinkedHashSet(list))是最优选择。而在代码可读性和现代性优先的场景Stream.distinct()是推荐做法。5. 常见问题与实战排查技巧在实际开发中除了性能还会遇到一些“奇怪”的问题。5.1 去重后列表顺序“乱了”问题描述用了HashSet去重后发现元素的顺序和原来不一样了。原因HashSet不保证迭代顺序。它的顺序由哈希值、桶的分布和冲突解决策略决定是未定义的。解决方案如果需要保留原List的插入顺序请使用LinkedHashSet。5.2 自定义对象去重“失效”问题描述明明两个对象内容一样去重后还在。原因该对象的类没有正确重写hashCode()和equals()方法。排查检查类定义确保使用了Override注解重写了这两个方法。使用IDE的代码生成功能确保所有关键字段都参与了计算。对于使用Lombok的项目检查是否添加了Data或EqualsAndHashCode注解。5.3 并行流去重结果不符合预期问题描述使用了parallelStream().distinct()结果列表顺序混乱甚至偶尔元素缺失极罕见情况与线程安全有关。原因parallelStream()默认是无序的distinct()在并行流中对顺序的保证较弱。解决方案如果不需要保序可以使用并行流但要做好性能测试。如果需要保序避免使用并行流进行去重操作或者接受顺序不确定的结果。5.4 超大列表去重内存溢出OutOfMemoryError问题描述列表非常大例如千万级使用new HashSet(list)时抛出OutOfMemoryError: Java heap space。原因HashSet的构造方法会一次性将原列表的所有元素加载到内存中并构建哈希表。如果原列表本身已经很大HashSet的额外开销如负载因子导致的容量大于元素数可能成为压垮骆驼的最后一根稻草。解决方案分批处理将大列表分割成多个小批次每批去重后合并再对合并结果进行最终去重。这增加了I/O或计算次数但降低了单次内存峰值。使用数据库如果数据来源于数据库优先考虑在SQL查询层面使用DISTINCT或GROUP BY进行去重这是数据库最擅长的事情。调整JVM参数在确实需要一次性处理的情况下适当增加堆内存-Xmx。但这只是权宜之计。考虑使用布隆过滤器Bloom Filter对于海量数据去重且允许极小概率误判的场景布隆过滤器是一种极省内存的数据结构。它可以快速判断一个元素“一定不存在”或“可能存在”于集合中。可以先用它做初步过滤再对“可能存在”的少量元素进行精确去重。5.5List中存放的是String但去重不区分大小写需求将[Apple, banana, APPLE]去重为[Apple, banana]。方案不能直接使用默认的Set因为String的equals是区分大小写的。解决ListString list Arrays.asList(Apple, banana, APPLE); // 使用TreeSet并指定忽略大小写的比较器 SetString set new TreeSet(String.CASE_INSENSITIVE_ORDER); set.addAll(list); ListString result new ArrayList(set); // 结果可能是 [Apple, banana] 或 [APPLE, banana]取决于TreeSet或者使用StreamListString result list.stream() .map(String::toLowerCase) // 统一转为小写 .distinct() .collect(Collectors.toList()); // 注意这里会丢失原始大小写格式如果需要保留第一次出现的大小写格式就需要自己实现一个维护映射的逻辑。6. 高级话题与扩展思考6.1 基于特定字段去重这是更常见的业务场景。例如一个ListPerson我们需要根据person.getId()去重。方案使用Stream API配合Collectors.toMap或Collectors.collectingAndThen。ListPerson distinctPeople people.stream() .collect(Collectors.collectingAndThen( Collectors.toMap(Person::getId, // 以ID为Key Function.identity(), // Person对象本身为Value (existing, replacement) - existing), // 如果ID冲突保留已存在的第一个 map - new ArrayList(map.values()) // 将Map的Value转为List ));这里的关键是toMap的第三个参数——合并函数(existing, replacement) - existing它定义了当键冲突时保留哪一个这里保留先出现的。6.2 有序流与无序流对distinct()的影响在并行流中如果流是无序的如parallelStream()默认distinct()操作不需要保证稳定性即保留哪一个重复元素是不确定的这给了JVM更大的优化空间可能提升性能。可以通过Stream.unordered()方法显式声明无序。但在需要稳定结果的业务场景下应避免这样做。6.3 第三方库的解决方案一些工具库如Google Guava也提供了去重的方法。// Guava - 保序去重 ListString result ImmutableSet.copyOf(list).asList(); // 或者使用Sets.newLinkedHashSetGuava的ImmutableSet会去除重复元素并且其asList()方法返回的列表视图是保序的按第一次出现的顺序。不过在Java标准库已经足够强大的今天引入额外依赖的必要性需要评估。最后选择哪种去重方式没有银弹。它取决于你的数据规模、对顺序的要求、代码上下文以及对性能的极致追求程度。掌握每种方法的原理和代价就能在编码时做出最合适的选择。我个人在大多数业务代码中倾向于使用Stream.distinct()因为它的表达力最强而在对性能敏感的底层工具方法中则会毫不犹豫地选择new ArrayList(new LinkedHashSet(list))。记住在写出代码之前先问问自己“这个列表有多大顺序重要吗” 这两个问题的答案会直接指引你找到最优解。