在Java开发的日常琐碎中，处理数组去重简直就像是家常便饭。你可Neng会觉得，这不就是把重复的数字挑出来扔掉吗？但当你真正深入进去，会发现这kan似简单的水面下其实暗流涌动。不同的实现方式，性Neng差异可Neng高达几百倍，甚至geng多。今天我们就来聊聊这个老生常谈却又不得不谈的话题，kankan除了那些教科书式的答案，我们还Neng玩出什么花样。

老实说hen多时候我们写代码只是为了“跑通”，但在面对海量数据时一个糟糕的去重算法足以让你的系统卡顿到怀疑人生。所以搞清楚这些背后的逻辑，不仅仅是为了面试，geng是为了对得起每一毫秒的CPU时间。

一、 原始社会的生存智慧：暴力循环去重

让我们先回到Zui原始的时代。那时候没有各种花哨的集合框架，手里只有一把名为“数组”的锤子。这种思路的核心非常直接：既然没有现成的工具，那就自己造。我们通过嵌套循环，拿着每一个元素去跟后面的所有元素比对，Ru果发现一样的，就把它干掉。

这种方法的逻辑Zui符合人类的直觉，但代价也是惨痛的。因为每判断一个元素，dou要遍历一遍剩下的数据，时间复杂度直接飙升到了O。想象一下当数据量变成几万、几十万的时候，这种写法简直就是一场灾难。

1. 双重循环的硬核实现

Zui经典的写法莫过于双重循环。外层循环负责遍历每一个元素，内层循环则负责“查户口”，kankan这个元素之前有没有出现过。Ru果没出现过就把它请进新数组；Ru果出现过那就直接无视。

public static int bruteForceDedup {
    // 先假设结果数组和原数组一样大，虽然浪费点空间，但省心
    int tempResult = new int;
    int count = 0;
    for  {
        boolean isDuplicate = false;
        // 拿着当前的 arr 去前面Yi经确认过的部分找找kan
        for  {
            if  {
                isDuplicate = true;
                break; // 找到重复的了赶紧撤，别浪费时间
            }
        }
        // Ru果前面没出现过那就是“独苗”，留下来
        if  {
            tempResult = arr;
        }
    }
    // Zui后把数组切一下把多余的尾巴扔掉
    return Arrays.copyOf;
}

这种写法虽然笨重，但在某些极度受限的环境下它可Neng是唯一的选择。毕竟它不依赖任何额外的类库，纯靠逻辑硬刚。

2. 利用List的contains方法

稍微“进化”一点的写法，是借助ArrayList。我们新建一个List，遍历原数组时先问问List：“这里面Yi经有这个数了吗？”Ru果List摇头说没有，我们就把它加进去。

public static Integer listContainsDedup {
    List uniqueList = new ArrayList<>;
    for  {
        // ArrayList.contains 底层其实也是循环，所以本质上还是O
        if ) {
            uniqueList.add;
        }
    }
    return uniqueList.toArray;
}

虽然代码kan起来清爽了不少，但别被表象迷惑了。`contains`方法内部依然是在Zuo线性扫描，所以性Neng上并没有质的飞跃，只是代码可读性稍微好点而Yi。

二、 集合框架的降维打击：Set与Map的运用

随着Java集合框架的普及，我们终于有了geng趁手的兵器。Set集合天生就具有“排他性”，它内部的契约就是：拒绝重复。这简直是上帝为了去重而专门创造的数据结构。

3. HashSet：速度之王，但秩序混乱

Ru果你对数据的顺序没有任何要求，只求快，那HashSet绝对是首选。它基于哈希表实现，插入和查询的时间复杂度接近O。把数组丢进HashSet，再转出来去重任务瞬间完成。

public static Integer hashSetDedup {
    // HashSet 不保证顺序，只保证唯一性
    Set set = new HashSet<>);
    return set.toArray;
}

不过要注意，HashSet内部是按哈希值乱序存储的，Ru果你原本的数据是去重后可Neng变成。Ru果你不在乎顺序，这就是Zui优解。

4. LinkedHashSet：鱼和熊掌兼得

但在实际业务中，我们往往希望保留元素第一次出现的顺序。这时候，LinkedHashSet就派上用场了。它在HashSet的基础上维护了一个链表，记录了插入的顺序。

public static Integer linkedHashSetDedup {
    // 既去重，又保留了你第一次见到它时的样子
    Set set = new LinkedHashSet<>);
    return set.toArray;
}

这大概是工程实践中Zui常用的“标准答案”了。性Neng不错，逻辑清晰，还Neng保序，简直是居家旅行必备良药。

5. TreeSet：自带排序功Neng的强迫症

有时候，去重只是第一步，你还希望结果是有序的。TreeSet不仅Neng去重，还Neng利用红黑树结构自动排序。默认是升序，Ru果你想要降序，也Ke以自定义比较器。

public static Integer treeSetDedup {
    // 去重的同时顺便帮你排好序了
    Set set = new TreeSet<>);
    return set.toArray;
}

三、 现代Java的优雅：Stream流式处理

Java 8的横空出世，让代码写起来开始变得像是在吟诗。Stream API提供了一种声明式的编程范式，把“Zuo什么”和“怎么Zuo”分离开来。对于去重这种操作，Stream简直是为之而生的。

6. Stream.distinct：一行代码的艺术

这是Zui简洁、Zui现代的写法。`distinct`方法内部其实就是利用了LinkedHashSet来实现去重的，但它把所有的脏活累活dou封装了起来只留给你一个干净的接口。

public static Integer streamDistinct {
    // 优雅，太优雅了
    return Arrays.stream
                 .distinct
                 .toArray;
}

这种写法不仅短，而且可读性极强。哪怕是不懂Java的人，kan一眼大概也Neng猜到这是在“去重”。在微服务或者复杂的业务逻辑链中，这种链式调用Neng极大地减少代码的行数，降低维护成本。

7. Collectors.toMap：按业务规则去重

有时候，我们面对的不是简单的整数数组，而是一堆对象。比如我们要根据用户的ID去重，Ru果ID重复了保留分数高的那个。这时候，简单的`distinct`就不够用了我们需要geng强大的`toMap`收集器。

public static List distinctByKey {
    Map map = students.stream
        .collect(Collectors.toMap(
            Student::getId, 
            student -> student, 
             -> existing.getScore> replacement.getScore ? existing : replacement,
            LinkedHashMap::new
        ));
    return new ArrayList<>);
}

这段代码的逻辑是：把List转成Map，Key是学生ID。Ru果遇到Key冲突，就触发合并函数，比较分数，留下高的。Zui后再用LinkedHashMap保证顺序。这展示了Stream API在处理复杂业务逻辑时的强大威力。

四、 另辟蹊径：排序与位图的巧思

除了常规手段，还有一些特定场景下的“奇技淫巧”。它们可Neng不通用，但在特定条件下往往Neng起到意想不到的效果。

8. 先排序再去重：空间换时间

Ru果我们不介意改变原数组的顺序，或者本来就需要排序，那么Ke以先对数组进行排序。排序之后相同的元素就会紧紧挨在一起。这时候，我们只需要遍历一遍，比较当前元素和前一个元素是否相同即可。

public static int sortAndDedup {
    if  return arr;
    // 先来个排序，让相同的元素“团聚”
    Arrays.sort;
    int index = 0;
    for  {
        // 只要当前元素和前一个不一样，就把它往前挪
        if  {
            arr = arr;
        }
    }
    // 截取有效部分
    return Arrays.copyOf;
}

这种方法的复杂度取决于排序算法，通常是O。虽然比HashSet慢一点，但它不需要额外的存储空间，在内存极度敏感的场景下hen有用。

9. BitSet：海量数据的终极杀器

Ru果我们要去重的数据是海量的非负整数，比如几亿个用户ID，那么普通的Set集合可Neng会因为内存不足而崩溃。这时候，Java提供的BitSet就是救星。

BitSet本质上是一个位图，用每一个bit位来表示一个数字是否存在。1表示出现过0表示没出现过。这极其节省空间，存储10亿个int只需要大约128MB内存。

public static int bitSetDedup {
    BitSet bitSet = new BitSet;
    int temp = new int;
    int count = 0;
    for  {
        // 检查第 num 位是否被标记过
        if ) {
            bitSet.set; // 标记为Yi出现
            temp = num;
        }
    }
    return Arrays.copyOf;
}

当然BitSet也有局限性，它只Neng处理非负整数，而且Ru果数据分布极其稀疏，那空间浪费就比较严重。但在处理密集型的大数据去重统计时它绝对是神器。

五、 性Neng实测与选择指南

说了这么多，到底该选哪种？我们不妨Zuo个简单的对比。假设我们有10万个随机整数，其中包含大量重复项。

双重循环慢到让你怀疑人生，可Neng需要几秒钟甚至geng久。

HashSet/Stream.distinct瞬间完成，毫秒级。

TreeSet稍微慢一点，因为要排序，但依然在可接受范围内。

BitSetRu果是整数场景，速度和内存dou是Zui优的。

所以选择的标准其实hen清晰：

日常开发无脑选 `stream.distinct` 或者 `new LinkedHashSet<>`。代码少，bug少，维护方便。

需要排序选 `TreeSet` 或者先 `sort` 再去重。

海量非负整数必须上 `BitSet`，这是性Neng和成本的平衡点。

极客精神/面试Ke以研究一下双重循环或者原地排序去重，展示你对底层的理解。

六、 避坑指南：关于对象的去重

Zui后不得不提一个常见的坑。当我们对自定义对象数组去重时HashSet和Stream.distinct可Neng会“失效”。比如你定义了一个Student类，即使两个对象的ID和名字dou一样，Set依然认为它们是不同的。

这是因为Java默认是用内存地址来判断对象是否相等的。要让Set正确工作，你必须重写 `hashCode` 和 `equals` 方法。记住这两个方法必须成对出现，且逻辑一致。`equals` 相等的对象，`hashCode` 必须相同。

class Student {
    private int id;
    private String name;
    @Override
    public boolean equals {
        if  return true;
        if  != o.getClass) return false;
        Student student =  o;
        return id == student.id && Objects.equals;
    }
    @Override
    public int hashCode {
        return Objects.hash;
    }
}

只有补上了这两个方法，集合框架才Neng识别出你眼中的“重复”。

数组去重，虽是雕虫小技，却也是Java基础功底的试金石。从Zui原始的循环嵌套，到集合框架的便捷，再到Stream的优雅，以及BitSet的极致，每一种方法dou有它存或许我们Ke以让机器帮我们生成代码，但选择哪种方案、理解背后的权衡，依然需要我们那颗不断思考的大脑。希望这篇文章Neng让你在下次面对去重需求时Neng多一份从容，少一份纠结。

---