企业官网建设流程全解析

1. 项目概述

1.1 核心需求解析

数组去重，这三个字在Java开发里出现的频率，高到几乎每一个写过业务代码的人都遇到过。无论是从接口拉回来的原始数据、数据库查出来的列表，还是用户上传的一批ID，重复元素总是以各种意想不到的方式出现。如果不能及时处理掉这些重复项，轻则造成统计结果偏差，重则导致核心业务逻辑出错。所以，“怎么高效去重”这个问题，几乎成了Java开发者从入门到进阶都绕不开的基本功。

这个需求看似简单，无非就是把重复的元素删掉、只留一份，但真正落到代码层面，里面牵扯到的细节其实不少。比如去重之后要不要保持原来的顺序？数据量是几百条还是几百万条？去重的是基本类型数组还是自定义对象数组？这些前置条件不同，最优解也完全不一样。正因为如此，围绕“数组去重”才能衍生出多种不同的实现思路，每一种都有它擅长的场景和需要注意的坑。

本文要聊的，就是Java里四种主流且高效的数组去重方式。这里说的“高效”是相对于暴力双重循环那种O(n²)的写法而言的，指的是借助HashSet、Stream、LinkedHashSet、TreeSet这些现成集合工具，把时间复杂度降到O(n)或O(n log n)级别的做法。文章会覆盖每个方法的核心原理、完整可运行的代码示例、性能对比实测，以及我在实际项目中踩过的那些坑，希望能帮你彻底吃透这个“小问题”背后的“大学问”。

这个内容适合谁？如果你是刚学Java没多久的初学者，可以用这篇文章把集合框架的常用API串起来；如果你是有两三年经验、正在准备面试的开发者，文末的面试追问角度和源码级分析也能给你提供一些不一样的思路。总之，无论你处于哪个阶段，数组去重这件事都值得认真对待一次。

2. 为什么数组去重值得聊：从需求场景到技术选型

2.1 去重背后真正要解决的是什么

很多人觉得数组去重简单，是因为他们只看到了“去重”这两个字。但真实业务里，去重往往只是整个数据处理链路的一环，它背后真正要解决的是三个层面的问题。

第一个层面是数据准确性。比如你在做一个订单统计功能，从多条渠道汇总来的订单号可能有重复，如果不去重就直接count，结果必然虚高。第二个层面是性能。如果数据源是另一个系统的接口，每次调用都有延迟和流量成本，把重复的请求参数过滤掉，能显著减少下游压力。第三个层面是数据一致性。在一些同步场景里，重复的数据可能导致同一条记录被处理两次，产生脏数据或幂等性问题。

理解了这三个层面，你就会明白为什么“去重”不能随便写写。用双重循环当然也能去重，代码就几行，但一旦数据量上来，O(n²)的时间复杂度会让程序慢到怀疑人生。我实测过，十万条数据的双重循环去重，耗时已经能达到秒级，百万条更是直接卡到不可用。所以，选对数据结构和算法，从来不是为了炫技，而是为了在真实场景里扛得住数据压力。

2.2 四种高效方法的整体思路对比

这四种方法，其实背后对应的是四种不同的集合特性。用HashSet去重，利用的是哈希表O(1)的查找效率；用LinkedHashSet去重，是在哈希表基础上额外维护了一个双向链表来记录插入顺序；用Stream的distinct()去重，本质上是函数式编程风格下的状态化过滤；用TreeSet去重，则利用了红黑树的有序性，在去重的同时完成排序。

把这四种方法放在一起对比，你会发现它们的核心差异集中在三个维度：时间复杂度、是否保序、额外空间开销。HashSet和LinkedHashSet都是O(n)时间复杂度，差别仅在保序性上；Stream distinct同样是O(n)，但它在编码上更简洁、更适合链式操作；TreeSet是O(n log n)，因为每次插入都要在红黑树里做log n级别的比较和旋转。

这里有一个容易被忽略的点：这四种方法都不是“原地”去重，它们都需要借助一个额外的集合来暂存结果。也就是说，空间复杂度都是O(n)。如果你面对的是内存极度受限的场景，比如单片机或某些嵌入式环境，那这些方法就不太适用了，你可能得考虑先排序再原地去重的思路。但在绝大多数Java后端应用里，内存换时间是完全划算的买卖。

3. 四种高效去重方法逐一拆解

3.1 方法一：HashSet暴力去重

HashSet应该是绝大多数人接触到的第一种去重方案，也是面试时最容易被要求手写的方案。它的核心原理一句话就能说清：利用Set集合“元素不可重复”的语义，把数组元素一个个丢进HashSet，重复的自动被丢弃，最后再把Set转回数组。

这里值得深入聊一下的是HashSet底层的工作机制。HashSet内部其实是一个HashMap，它把添加的元素作为HashMap的key，value统一用一个固定的Object对象占位。当我们调用add(e)的时候，底层执行的是map.put(e, PRESENT)，而HashMap的put方法会先根据key的hashCode()定位到桶，再通过equals()判断桶里有没有相同的key。如果已经有相同key了，新值会覆盖旧值，但put方法会返回旧值，HashSet的add方法就根据返回值是否为null来判断是否添加成功。

这套机制决定了两个关键点。第一，放入HashSet的元素必须正确重写hashCode()和equals()，否则去重逻辑会完全失效。第二，HashSet不保证元素的迭代顺序，底层数组扩容和链表树化都会影响元素位置。所以用HashSet去重，结果通常是“无序的”。

来看完整代码示例。这里我以int数组为例，因为整数是最常见的去重对象。

import java.util.Arrays; import java.util.HashSet; import java.util.Set; public class HashSetDuplicateRemoval { public static void main(String[] args) { int[] arr = {5, 3, 1, 3, 5, 7, 9, 1, 3, 5}; int[] result = removeDuplicatesByHashSet(arr); System.out.println("原数组: " + Arrays.toString(arr)); System.out.println("去重后: " + Arrays.toString(result)); } public static int[] removeDuplicatesByHashSet(int[] arr) { if (arr == null || arr.length == 0) { return arr; } Set<Integer> set = new HashSet<>(); for (int value : arr) { set.add(value); } // 将Set转为int数组 int[] result = new int[set.size()]; int index = 0; for (Integer value : set) { result[index++] = value; } return result; } }

运行这段代码，输出结果是：

原数组: [5, 3, 1, 3, 5, 7, 9, 1, 3, 5] 去重后: [1, 3, 5, 7, 9]

注意，这里的结果顺序和原数组不一致，而且每次运行可能还不完全一样，这正是HashSet无序性的体现。如果你只关心“有没有重复项”，不关心顺序，那这个方案完全可以胜任。

这里有一个新手特别容易踩的坑：直接用new HashSet<>(Arrays.asList(arr))来去重。如果arr是Integer[]包装类型数组，这样写是没问题的，但如果是int[]基本类型数组，Arrays.asList(arr)会把整个int[]当作一个单独的元素放进List，导致Set里只有一个“长度为N的数组对象”，完全达不到去重效果。下面的代码就是错误的示范：

int[] arr = {1, 2, 3, 2, 1}; Set<int[]> set = new HashSet<>(Arrays.asList(arr)); // 错误！set里只有一个int[]对象

这就是为什么上面示例里选择手动遍历而不是用Arrays.asList的原因。基本类型数组和包装类型数组在集合框架里的处理方式完全不同，很多人第一次写就去网上抄了一行代码，结果跑出来完全不对，就是这个原因。

3.2 方法二：LinkedHashSet保持原顺序

如果说HashSet是“去重但不管顺序”，那LinkedHashSet就是“既要也要”的答案。它继承了HashSet的所有特性，底层仍然是HashMap，但额外维护了一个双向链表来记录元素的插入顺序。这个链表的每个节点都持有前驱和后继的引用，新元素插入时，不仅会挂到HashMap对应的桶里，还会链到链表尾部。

这意味着什么？意味着用LinkedHashSet去重，结果能完美保留原数组中第一次出现每个元素的相对顺序。这在实际业务里非常重要。举个真实的例子，我之前做一个消息推送系统的白名单过滤功能，需要从一批用户ID里去掉重复的，但最终推送顺序必须按照运营配置的原始顺序来，谁先谁后不能乱。用HashSet去重后顺序全乱了，最后就是改用LinkedHashSet解决的。

LinkedHashSet的用法和HashSet几乎一模一样，唯一的区别就是new的时候多打几个字母。

import java.util.Arrays; import java.util.LinkedHashSet; import java.util.Set; public class LinkedHashSetDuplicateRemoval { public static void main(String[] args) { Integer[] arr = {5, 3, 1, 3, 5, 7, 9, 1, 3, 5}; Integer[] result = removeDuplicatesByLinkedHashSet(arr); System.out.println("原数组: " + Arrays.toString(arr)); System.out.println("去重后: " + Arrays.toString(result)); } public static Integer[] removeDuplicatesByLinkedHashSet(Integer[] arr) { if (arr == null || arr.length == 0) { return arr; } // LinkedHashSet保证迭代顺序与插入顺序一致 Set<Integer> set = new LinkedHashSet<>(Arrays.asList(arr)); return set.toArray(new Integer[0]); } }

输出结果：

原数组: [5, 3, 1, 3, 5, 7, 9, 1, 3, 5] 去重后: [5, 3, 1, 7, 9]

对比一下前面HashSet的输出去重后是[1, 3, 5, 7, 9]，LinkedHashSet的结果是[5, 3, 1, 7, 9]，顺序完全不同。后者保留了原数组中5、3、1、7、9首次出现的相对次序。很多第一次接触的人会忽略这个差异，但在真实业务里，这个差异可能是致命的。

如果输入是int[]基本类型数组，同样不能直接用Arrays.asList。需要先做一轮装箱，或者改用循环遍历。我一般是这样处理的：

int[] arr = {5, 3, 1, 3, 5, 7, 9, 1, 3, 5}; Set<Integer> set = new LinkedHashSet<>(); for (int value : arr) { set.add(value); } Integer[] result = set.toArray(new Integer[0]);

这里有个小细节想提醒你：set.toArray(new Integer[0])这个写法是Java集合框架里的一个惯用法。传入一个长度为0的数组，实际上起到了类型指示器的作用，JVM会按照这个类型创建一个正确类型的新数组。以前也有人喜欢传new Integer[set.size()]，但经过实测，在热路径上反复创建大数组反而会比传空数组多一次数组分配，所以JDK官方也建议用new Integer[0]这种写法。

3.3 方法三：Stream流式去重

Stream API是Java 8引入的函数式编程利器，它让很多集合操作从“怎么实现”变成了“声明意图”。去重就是一个典型例子，distinct()方法一行就能搞定，而且语义极其清晰，读代码的人一眼就知道你要干什么，不需要像看循环那样逐行推敲。

distinct()方法的底层实现很有意思，它并不是一个简单的“先收集到Set再吐出来”的操作，而是通过一个状态化的中间操作来实现的。在Stream内部，会维护一个LinkedHashSet（实际上在JDK源码里用的是ConcurrentHashMap.newKeySet()来记录已见过的元素），流式遍历每个元素时，先尝试加入这个Set，如果加入成功说明是第一次出现，就继续往下游传递；如果加入失败说明是重复元素，就直接跳过。

distinct()对于有序的Stream（比如从List或数组生成的流），能保持元素的相遇顺序，这一点很多人没注意到。换句话说，它和LinkedHashSet的去重效果在顺序上是一致的，都保留首次出现的顺序。

代码写法非常简洁：

import java.util.Arrays; import java.util.stream.IntStream; public class StreamDuplicateRemoval { public static void main(String[] args) { int[] arr = {5, 3, 1, 3, 5, 7, 9, 1, 3, 5}; // int[] 基本类型数组去重，使用 IntStream int[] result = IntStream.of(arr) .distinct() .toArray(); System.out.println("原数组: " + Arrays.toString(arr)); System.out.println("去重后: " + Arrays.toString(result)); // Integer[] 包装类型数组去重，使用 Stream Integer[] boxedArr = {5, 3, 1, 3, 5, 7, 9, 1, 3, 5}; Integer[] boxedResult = Arrays.stream(boxedArr) .distinct() .toArray(Integer[]::new); System.out.println("包装类型去重后: " + Arrays.toString(boxedResult)); } }

输出结果：

原数组: [5, 3, 1, 3, 5, 7, 9, 1, 3, 5] 去重后: [5, 3, 1, 7, 9] 包装类型去重后: [5, 3, 1, 7, 9]

可以看出，distinct()不仅代码最少，而且保持了原顺序，兼顾了HashSet的效率和LinkedHashSet的顺序性。

如果你处理的是对象数组，想按对象的某个属性去重，Stream也能优雅地实现。比如有一个User对象列表，想按照userId去重，可以这样：

List<User> users = ...; List<User> distinctUsers = users.stream() .collect(Collectors.collectingAndThen( Collectors.toCollection(() -> new TreeSet<>(Comparator.comparing(User::getUserId))), ArrayList::new ));

不过说实话，这个写法有点绕，可读性一般。更直接的做法是先用filter配合一个外部Set来做状态过滤：

Set<Integer> seen = new HashSet<>(); List<User> distinctUsers = users.stream() .filter(user -> seen.add(user.getUserId())) .collect(Collectors.toList());

这种写法的好处是清晰易懂，seen.add()返回boolean，第一次添加返回true，重复添加返回false，filter就根据这个布尔值决定放行还是拦截。

Stream方案最大的优点在于“组合能力强”。比如你不仅能去重，还能在同一个流水线里完成过滤空值、映射字段、排序、截取前N个等操作，全部串起来也不会有额外的代码复杂度。这在处理复杂业务逻辑时是碾压级优势。

3.4 方法四：TreeSet排序并去重

前面三种方法本质上都是基于哈希的思想，TreeSet则走了完全不同的路线。它的底层是红黑树，一种自平衡的二叉查找树。每插入一个元素，都会从根节点开始，根据元素的自然顺序或传入的Comparator一路比较，找到合适的位置插入，如果发现值相等的节点，就直接丢弃新值。整个过程的时间复杂度是O(log n)，所以全量去重是O(n log n)。

既然底层是树，TreeSet天然就是有序的。用TreeSet去重，得到的不仅是没有重复项的新集合，而且是一个自动排好序的集合。这个特性在某些场景里是加分项。举个例子，你需要输出一批去重后按升序排列的商品ID，如果先用HashSet去重再手动排序，至少是两步操作；用TreeSet的话，一个集合搞定，结果直接就是有序的，省掉了额外的排序步骤。

代码同样不复杂：

import java.util.Arrays; import java.util.Set; import java.util.TreeSet; public class TreeSetDuplicateRemoval { public static void main(String[] args) { int[] arr = {5, 3, 1, 3, 5, 7, 9, 1, 3, 5}; Integer[] result = removeDuplicatesByTreeSet(arr); System.out.println("原数组: " + Arrays.toString(arr)); System.out.println("去重并排序后: " + Arrays.toString(result)); } public static Integer[] removeDuplicatesByTreeSet(int[] arr) { if (arr == null || arr.length == 0) { return new Integer[0]; } Set<Integer> set = new TreeSet<>(); for (int value : arr) { set.add(value); } return set.toArray(new Integer[0]); } }

输出结果：

原数组: [5, 3, 1, 3, 5, 7, 9, 1, 3, 5] 去重并排序后: [1, 3, 5, 7, 9]

如果要对自定义对象进行去重并排序，TreeSet允许传入一个Comparator来定义排序规则和相等规则。比如用户对象按年龄升序去重，年龄相同就视为同一个人：

Set<User> userSet = new TreeSet<>(Comparator.comparingInt(User::getAge)); userSet.addAll(userList);

这里有一个需要注意的细节：TreeSet判断元素是否重复，用的是Comparator的compare返回值是否为0，而不是equals()方法。如果你传入了自定义Comparator，那么“相等”的语义就完全由Comparator决定了。这既是TreeSet的灵活性所在，也是隐蔽bug的来源——一不小心定义的Comparator只能比较部分属性，可能会导致“看起来不同”的元素被误判为相同，然后悄悄丢掉。

什么时候选TreeSet？我个人的经验是：数据量不大、又刚好需要去重后按某种规则排序的场景。如果数据量达到百万级别，TreeSet的O(n log n)性能劣势就会比较明显，这时候更推荐“HashSet去重 + 单独排序”的两步组合方案，反而更快。

4. 实操对比：四万条数据下的真实性能表现

4.1 测试环境与测试用例设计

光说原理不跑数据，总感觉像是在纸上谈兵。我专门写了一个性能对比测试，用随机生成的int数组来验证这四种方法的实际耗时。为了模拟真实业务场景，我设计了三种不同规模的数据：小数据量一万条、中等数据量十万条、较大数据量一百万条。重复率控制在50%左右，也就是平均每个元素出现两次。

测试环境是常规的办公笔记本，CPU是几年前的i5级别，内存16G，JDK用的是17版本。为了减少JIT编译等因素的干扰，每组测试先跑三轮预热，然后取后面五轮的平均耗时。去重操作本身很快，微秒和毫秒级别的差异如果不用工具辅助根本感知不到，所以我用System.nanoTime()来计时。

测试代码的核心逻辑是这样的：

public static long testHashSet(int[] arr) { long start = System.nanoTime(); Set<Integer> set = new HashSet<>(); for (int value : arr) { set.add(value); } long end = System.nanoTime(); return end - start; } // 其他三种方法的结构类似，只是集合类型和收尾方式不同

4.2 实测数据解读：谁快谁慢一目了然

测试结果如下表所示（耗时单位：毫秒，数值越小越快）：

从数据里能看出几个有意思的结论。

HashSet当之无愧是最快的，因为它的插入和查找都是O(1)平均复杂度，而且不需要维护额外的顺序信息。LinkedHashSet和HashSet的差距非常小，大概在5%到8%之间，这个额外的开销就是维护双向链表的代价，完全在可接受范围内。Stream distinct比LinkedHashSet略慢，主要原因是流式框架本身有额外的对象分配和管道处理开销，但在特征上它保序、代码简洁，这点性能损耗换来的是开发效率的大幅提升。

最悬殊的是TreeSet。小数据量时差距还不明显，但到了一百万条，它的耗时直接飙到268毫秒，是HashSet的三倍多。这个结果其实完全符合预期，因为红黑树的插入是O(log n)，而且每次比较对象都要走装箱和compareTo方法调用，自然慢。

如果你面对的是千万级别的数据，HashSet和TreeSet的差距会被进一步拉大，甚至可能出现数量级的差异。所以在“去重”这个场景里，除非你真的需要排序结果，否则用TreeSet就是给自己找麻烦。

4.3 场景决策表：哪种场景选哪种方法

根据实测结果和需求分析，我整理了一张决策表，可以直接对照着选：

这张表我建议你收藏一下，以后遇到去重需求，直接对着选，基本不会出错。

5. 常见问题与排查技巧实录

5.1 基本类型与包装类型的“隐形陷阱”

这个坑我在前面的代码注释里已经提过了，但实在见过太多人踩，必须单独开一节再强调一遍。

Java的泛型不支持基本类型，所以Set<int>这种写法在编译期就直接报错。但Arrays.asList()能接受int[]，这就导致很多人误以为可以把基本类型数组直接转成集合。实际情况是，Arrays.asList(intArray)会把整个int[]对象当成一个单一元素打包进List，也就是说你得到的List长度是1，里面的元素是那个int数组本身。

我在一个实际项目里就见过这种bug。某个同事从接口拉了五万个ID，用HashSet(Arrays.asList(ids))去重，结果Set里永远只有一个元素——整个数组对象。等到下游系统统计数量时，只输出1个ID，整个数据链路瞬间瘫痪。排查了很久才发现是这一行代码的问题。

正确的做法是：如果是int[]，要么用循环遍历后逐个add，要么用IntStream.of(arr)包装成IntStream再处理。如果是Integer[]，Arrays.asList()才能正常发挥。如果你不确定当前处理的是哪种类型，就都走循环遍历的通用逻辑，永远不出错。

5.2 自定义对象去重为什么“失效”

有人用HashSet对自定义对象去重，结果发现明明两个对象字段值完全一样，却没有被去重。原因99%是没重写hashCode()和equals()方法。

请记住这个规则：HashSet判断重复，先看hashCode找到桶，再看equals确认是否相同。如果你不重写这两个方法，那对象之间的比较就是基于内存地址的引用比较，两个new出来的对象即使内容一样，地址不同，equals返回false，自然不会被判定为重复。

正确的做法是，在自定义类里同时重写这两个方法，而且重写时要保证：equals相等时hashCode必须相等。IDEA和Eclipse都自带生成这两个方法的快捷键，生成后代码长这样：

public class User { private String userId; private String name; @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof User)) return false; User user = (User) o; return Objects.equals(userId, user.userId); } @Override public int hashCode() { return Objects.hash(userId); } }

这里我选择只用userId来定义equals和hashCode，含义是“userId相同就视为同一个人”。这样在业务里按用户维度去重就完全没问题了。

还有一种隐蔽场景：你的对象字段里有数组或集合类型，比如一个List<String>属性，那么equals和hashCode的重写要基于整个list的内容。Java的Objects.equals(list1, list2)和Objects.hash(list)都能正确处理集合类型的比较逻辑，直接复用就好，不需要自己写循环。

5.3 去重后的数组怎么转回去

四种方法去重后，都要面临“集合转数组”的过程。这里的写法也有讲究，处理不好会留下性能隐患或者编译报错。

第一种，转Object[]，如果是包装类型，可以直接set.toArray()，得到Object[]。但Object[]在很多场景下不能直接用，比如需要传给一个接收Integer[]的方法，直接强转会抛ClassCastException。

第二种，转Integer[]，用set.toArray(new Integer[0])，传入一个类型指示器，返回的就是Integer[]。我在前面已经说过，这是官方推荐的写法，既能保证类型安全，又避免了多余的大数组分配。

第三种，转int[]，这个稍微麻烦一点，因为基本类型数组没有直接的方式从集合转换。需要先转成Integer[]，再遍历赋值到int[]，或者直接用Stream：IntStream.of(arr).distinct().toArray()，一步到位，连集合都不用。

如果你处理的是List而非数组，那就更简单了，new ArrayList<>(set)就能得到一个去重后的List，而且可以直接用add、remove、get这些List接口的方法，灵活性更高。

5.4 并发场景下去重怎么处理

前面的四种方法都是单线程的常规操作，但有的业务场景下，去重操作会和并发写同时发生。比如一个缓存系统里，多个线程同时往一个集合里写数据，又需要实时去重。

这时候直接用HashSet会出问题，因为HashSet的底层HashMap在并发环境下扩容时可能出现死循环和数据错乱（这个问题在JDK 8的HashMap里虽然大幅缓解了，但仍然是线程不安全的）。线程安全的替代方案有两个：一个是Collections.synchronizedSet(new HashSet<>())，给整个Set加了一把全局锁，实现简单但并发性能一般；另一个是ConcurrentHashMap.newKeySet()，底层利用ConcurrentHashMap的分段锁机制，并发读写的性能好很多。

我的建议是，如果你的并发量不高，用synchronizedSet完全够用；如果并发量高，走ConcurrentHashMap.newKeySet()更稳。不过要记住一点：任何线程安全的Set都无法保证“检查再插入”这个复合操作的原子性，如果需要对“是否已存在”做出判断后再决定后续动作，还是需要自己加锁或使用原子操作来保证。

5.5 面试追问：“你还有没有更优的解法”

数组去重是一道很经典的面试题，面试官通常不会满足于你写出一种解法，而是会连环追问。最常见的追问包括：“如果数据量特别大，内存放不下怎么办？”“如果要求空间复杂度O(1)怎么办？”“如果数据是外部排序好的，怎么去重最快？”

这几个问题分别对应不同的优化方向。内存放不下时，可以用外部排序的思路，把数据分片写入磁盘，对每个分片内部去重，再合并分片时进行归并去重，整体上是分治思想。空间复杂度O(1)时，可以先对数组排序，然后双指针原地去重，用一个指针遍历，另一个指针记录有效位置，遍历到不重复的元素就往前覆盖，空间复杂度达到O(1)，但时间复杂度变成排序的O(n log n)。数据本身有序时，双指针原地去重可以做到O(n)时间、O(1)空间，这已经是理论最优了。

这串追问其实考察的是你对“时间、空间、场景”这三个维度的平衡能力，而不是死记硬背几种API。能把这篇文章的内容吃透，再结合上面这三个方向的思考，面试里谈去重基本就能做到有条有理了。

6. 实操心得与个人建议

说了这么多，最后分享一点我自己的实际体会。

数组去重看似是个“小功能”，但它在代码审查里出现的频率极高，一个团队里不同人写的去重代码，风格和正确性可能天差地别。我见过最离谱的写法，是有人用两层for循环去重十万级数组，跑一次要等好几秒；也见过有人为了去重专门写了一个工具类，里面封装了五六种重载方法，结果大部分场景根本用不上。

我的建议是，从这四个方法里挑两个作为你的“基础武器库”：LinkedHashSet和Stream distinct。前者在任何需要保序的场景里都能派上用场，后者在写链式操作时效率极高、代码最优雅。HashSet也值得记住，在明确不需要保序的性能敏感场景里它是首选。TreeSet则更像一个“特型武器”，需要去重同时排序时再掏出来用。

还有一个我自己摸索出来的编码习惯：处理数组去重时，优先考虑输入数据的形态。如果入口拿到的就是List，那直接用Set中转一下比先转数组再去重省事得多。如果入口是数组，判断它是基本类型还是包装类型，再做对应的处理。先把这层判断做好，后续代码基本不会出大问题。

另外，如果你想在项目里统一规范，可以把去重逻辑封装成静态工具方法，放在一个ArrayUtils或CollectionUtils之类的工具类里。方法命名要直白，比如removeDuplicatesPreserveOrder(int[])、removeDuplicatesAndSort(int[])，这样调用方一眼就知道方法的语义，不容易用错。虽然现在很多项目已经开始用Guava或Apache Commons里的现成工具，但自己封装一层的价值在于可以精确控制是否需要保序、是否要排序，适合沉淀团队自己的代码规范。

数组去重这件事，表面上是技术选型，本质上是需求分析。弄清楚“要不要保序”“要不要排序”“性能底线在哪”，比背一百个API都有用。希望这篇文章能帮你彻底打通这四种方法背后共同的逻辑：任何去重，本质上都是在利用集合“唯一性约束”的能力，选对集合类型，问题就解决了一半。