HashSet与LinkedHashSet底层原理对比：从去重到有序的集合实践

1. 项目概述与核心价值

1.1 什么是HashSet和LinkedHashSet

凡是写过Java业务的，几乎没人能绕开Set家族。HashSet是Set接口最典型的实现，底层借用HashMap来存储元素，特点是无序、去重、允许null值（只能存一个null）。而LinkedHashSet是HashSet的子类，它在HashSet基础上额外维护了一条双向链表，用来记录元素的插入顺序，所以你遍历LinkedHashSet时拿到的顺序，就是你add进去的顺序。一句话概括：HashSet管去重，LinkedHashSet管去重的同时还管“先来后到”。

我最初接触这两个类是在做接口幂等性校验的时候。某个下游回调接口需要防止同一笔订单重复处理，最粗鲁的做法是每次请求来了都对订单号查一次库，但高频场景下这会对数据库造成不必要的压力。后来我把处理过的订单号放进HashSet里做内存去重，配合过期时间做清理，问题就解决了。那会儿只是“会用”，真正把HashSet的脾气摸透，是在啃完源码、踩过几个隐藏很深的坑之后——比如可变对象改字段导致集合里出现“幽灵元素”、遍历时被别的线程改了一下就抛ConcurrentModificationException、两个对象明明业务上相等却因为没重写hashCode而去重失败。

这篇内容适合这么几类人：正在准备Java面试、刷八股的；工作中经常做集合选型但没认真抠过底层的；还有刚学完Java基础、想弄明白“为什么HashSet不能重复”的初学者。我会从源码和实际场景两条线来讲，尽量把原理讲明白，顺带分享一些我实际踩过的坑和排查思路。

1.2 为什么值得专门研究这两个类

很多人觉得集合框架里HashMap才是重头戏，HashSet和LinkedHashSet只是“衍生品”，没必要花太多精力。这个观点有一定道理，但我个人认为，HashSet恰恰是理解HashMap最好的入口。因为HashSet的实现非常“薄”，它几乎没有自己的存储逻辑，add、remove、contains这些方法全是调HashMap内部的方法。你把HashSet的源码读透了，等于把HashMap的put流程、hash扰动、扩容机制、链表和红黑树切换这些核心机制都过了一遍，而且是站在一个相对简单的视角去理解。

LinkedHashSet的价值更多在生产环境。凡是需要用set去重、又希望保留添加顺序的场景，LinkedHashSet都是首选。比如运营后台的“最近浏览记录”、并发环境下的任务白名单、需要按配置顺序去重的模板ID集合，这些都是LinkedHashSet的典型应用。而且它和LinkedHashMap是同一套底层机制，弄懂了LinkedHashSet，以后看LinkedHashMap源码也会轻松很多。

2. HashSet整体设计与实现思路拆解

2.1 设计哲学：用组合而不是继承，复用HashMap的能力

打开HashSet源码，第一眼你就知道这个类有多“偷懒”。它内部只声明了这么几个字段：

java复制private transient HashMap<E,Object> map;

// Dummy value to associate with an Object in the backing Map
private static final Object PRESENT = new Object();

构造方法里初始化一个HashMap，add方法就是把元素当作key、把PRESENT当作value塞进map：

java复制public boolean add(E e) {
    return map.put(e, PRESENT) == null;
}

HashMap的put方法返回的是“key之前被覆盖的旧value”，如果key不存在，返回null。所以HashSet判断元素是否重复，完全依赖HashMap的key判重逻辑。PRESENT只是一个占位对象，所有HashSet元素共享同一个dummy value，这样设计省去了每个元素都要存一个value的内存开销。

这个设计最聪明的地方在于：Set和Map在数学意义上本来就是互通的——你能用Map去重，就能用Map实现Set。Java没有单独为Set写一套哈希表存储结构，而是直接复用HashMap这个被反复打磨过的存储引擎。自己在业务代码里写类似逻辑时，也应该遵循这个思路：能复用成熟组件的能力，就不要从头造轮子。

2.2 HashSet、LinkedHashSet、TreeSet三个兄弟的定位差异

先看一张对比表，把三者的核心区别摆清楚：

注意区分“无序”和“随机”这两个概念。HashSet的无序不是说每次遍历结果都不一样，而是说元素的存储位置由哈希值决定，你无法预测它内部的组织顺序，也不应该依赖这个顺序。迭代时它通常会呈现出一种看起来“乱”的顺序，但其实是稳定的（前提是没有触发扩容、没有移除元素）。

举个例子：同样add进1、2、3三个数字，HashSet的遍历顺序可能是[1, 2, 3]，也可能是[2, 1, 3]，这取决于它们hash后落到的桶位置；而LinkedHashSet的遍历顺序永远是[1, 2, 3]，和插入顺序完全一致。TreeSet则会把顺序排成[1, 2, 3]（按自然顺序），哪怕你插入顺序是3、1、2。

2.3 为什么LinkedHashSet选择继承HashSet，而不是直接实现Set接口

这个问题很有意思，也是很多讲集合的博客很少提到的点。LinkedHashSet的声明是：

java复制public class LinkedHashSet<E> extends HashSet<E>
        implements Set<E>, Cloneable, java.io.Serializable {

理论上，LinkedHashSet完全可以像HashSet一样直接implements Set，自己持有LinkedHashMap字段来实现所有方法。但JDK团队选择了继承HashSet，除了复用public方法之外，还有一个很关键的细节——构造器的“技巧性传参”。

LinkedHashSet的构造方法长这样：

java复制public LinkedHashSet(int initialCapacity, float loadFactor) {
    super(initialCapacity, loadFactor, true);
}

这个super调的是HashSet的一个package-private构造器：

java复制HashSet(int initialCapacity, float loadFactor, boolean dummy) {
    map = new LinkedHashMap<>(initialCapacity, loadFactor);
}

第三个参数dummy纯粹是为了区分签名，因为Java构造器重载不能只看参数类型，还得看个数。这个package-private构造器只在java.util包内部可见，外面的类根本调不到，只有LinkedHashSet这个在同一包下的“自家人”才能用。通过这种手法，HashSet内部的map字段被初始化为LinkedHashMap，后续add、remove等所有方法都能直接复用，同时又能满足LinkedHashSet保序的需求。

这个细节告诉我一个道理：有些时候想复用父类能力，不一定非要大改父类逻辑，通过构造器传入“定制化的组件实例”就能实现灵活扩展。业务代码里如果想要一个类在保留原始行为的基础上做增强，优先考虑“在构造阶段注入增强后的组件”，而不是大范围重写方法。

3. 核心细节解析与底层原理

3.1 hashCode与equals的契约——去重的基石

HashSet去重，说白了就是依赖两个方法：hashCode和equals。HashMap在put元素时，先根据key的hashCode定位到桶，再通过equals与桶内已有元素比较，判断key是否重复。所以这两个方法必须满足一条铁律：equals相等，hashCode必须相等；反过来，hashCode相等，equals不一定相等（哈希冲突）。

我见过太多人栽在这个契约上。比如定义一个用户类，只重写了equals，没重写hashCode，然后往HashSet里add两个字段完全相同的“用户”，结果两个都进去了。原因很简单：Object默认的hashCode是对象的地址派生出的值，两个new出来的对象地址不同，hashCode就不同，HashMap在找桶时就已经把它们分到了不同的桶里，根本来不及调用equals比较。

重写这两个方法的黄金准则：

• hashCode用参与equals比较的字段来生成，业务上相关的字段尽量都参与。
• 推荐用Objects.hash方法生成，JDK 7开始提供，比自己手写效率高且不易出错。
• equals判断用instanceof而不是getClass()，否则子类继承时容易出问题。
• 两个方法的重写必须一致，千万别“只重写一个”。

一段实际工作里我用过的模板：

java复制public class OrderPair {
    private final String orderNo;
    private final String scene;

    public OrderPair(String orderNo, String scene) {
        this.orderNo = orderNo;
        this.scene = scene;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof OrderPair)) return false;
        OrderPair that = (OrderPair) o;
        return Objects.equals(orderNo, that.orderNo)
                && Objects.equals(scene, that.scene);
    }

    @Override
    public int hashCode() {
        return Objects.hash(orderNo, scene);
    }
}

这里把orderNo和scene组合成一个去重维度，只有当两个字段都相等时，两个OrderPair才算同一个元素。

3.2 哈希冲突：链地址法和红黑树化

哈希表最怕的就是哈希冲突。所谓冲突，就是两个不同的key经过hash运算后落到了同一个数组下标上。HashMap（以及背后的HashSet）处理冲突的方式是链地址法：数组的每个位置不直接存储元素，而是存储一个链表的头节点，冲突的元素串在链表上。

Java 8之前，这个链表是普通的单向链表；Java 8之后，当链表长度达到8、且数组容量达到64时，链表会转换成红黑树。为什么要做这个转换？因为链表查找的时间复杂度是O(n)，一旦某个桶里串了上百个元素，查找效率会急剧下降；红黑树可以把查找降到O(log n)。为什么选8这个阈值？官方注释里给了个统计依据：在随机哈希码场景下，桶中节点个数符合泊松分布，当容量为16、加载因子为0.75时，链表长度达到8的概率只有千万分之六。也就是说，正常开发中很少会遇到链表长度超过8的情况，如果真遇到了，多半是某个类的hashCode写得极差，或者被恶意构造数据攻击。

反过来，当红黑树的节点数减少到6时，又会转回链表。8和6中间留了1个数字的缓冲，避免元素在边界反复增删导致链表和树频繁切换。切换本身是有代价的，每次树化、反树化都要重新组织节点结构，能避免就尽量避免。

3.3 LinkedHashSet如何维持插入顺序——双向链表的before/after

LinkedHashSet底层用的是LinkedHashMap，而LinkedHashMap在HashMap的数组+链表/红黑树结构之上，额外维护了一条贯穿所有节点的双向链表。每个节点都多出两个指针：before指向前一个节点，after指向后一个节点。

当我执行add操作时，节点不仅会按照哈希值挂到对应的桶上，还会被追加到双向链表的尾部。这样遍历的时候，从链表头节点出发，逐个访问after指针，就能按插入顺序访问所有元素。

这个链表是LinkedHashMap内部通过重写父类HashMap的回调方法实现的。HashMap在创建新节点时会调用newNode方法：

java复制Node<K,V> newNode(int hash, K key, V value, Node<K,V> next) {
    return new Node<>(hash, key, value, next);
}

LinkedHashMap重写了这个方法，返回的是自己定义的Entry节点，并维护了两个链表指针：

java复制Node<K,V> newNode(int hash, K key, V value, Node<K,V> e) {
    LinkedHashMap.Entry<K,V> p =
        new LinkedHashMap.Entry<>(hash, key, value, e);
    linkNodeLast(p);
    return p;
}

linkNodeLast方法会把新节点链接到双向链表的尾部。这个过程非常巧妙：存储相关的逻辑完全复用HashMap，顺序相关的逻辑通过回调机制插入到节点创建的环节中。这也是LinkedHashSet只比HashSet多花了少量内存（两个指针的引用开销），却得到了完整顺序保证的原因。

3.4 线程安全与fail-fast机制

经常有人问：HashSet是线程安全的吗？答案是否定的。真正线程安全的Set实现是CopyOnWriteArraySet、ConcurrentHashMap.newKeySet()、Collections.synchronizedSet包装后的Set。HashSet的所有方法都没有加锁，多线程并发读写时，可能出现数据错乱、丢失更新等问题。

更需要注意的是，HashSet的迭代器是fail-fast的。也就是说，当迭代器创建之后，如果集合结构被修改（新增、删除元素，不包括用迭代器自身的remove方法），迭代器在下次调用next时会抛出ConcurrentModificationException。这个机制靠的是modCount字段：每次结构性修改modCount都会+1，迭代器初始化时记录当前modCount，每次返回元素前检查modCount是否变化，变了就抛异常。

我遇到过最典型的场景：一个定时任务里，一边遍历消费者上报的订单号集合，一边有个线程往集合里补充新订单号，结果线上疯狂抛异常。排查了很久才发现是共享的HashSet被多线程访问了。解决方式根据场景选：如果读多写少用CopyOnWriteArraySet，如果写多且只是想并发安全，可以用ConcurrentHashMap.newKeySet()，它支持并发put且没有读写锁的瓶颈。

4. 实操过程与核心环节实现

4.1 源码级拆解：add一个元素的完整旅程

很多人在面试时被问“HashSet的add方法内部做了什么”，回答往往卡在“就是调HashMap的put”。这没错，但太浅了。这里我完整走一遍add一个元素的源码路径，以JDK 8为例。

第一步：计算hash值。HashSet.add调map.put(e, PRESENT)，HashMap的put方法先调hash(key)：

java复制static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

这里把key的hashCode右移16位后和原值做异或，目的是让高16位的信息也参与到底部下标计算中。因为计算数组下标用的是 (n - 1) & hash，如果数组长度n比较小（比如16，二进制是1111），那下标只取决于hash的低4位，高28位的差异全被丢弃了，很容易产生冲突。通过一次异或扰动，高16位相当于“混入”低16位，让分布更均匀。

第二步：找桶。HashMap的putVal方法里，通过 (n - 1) & hash 定位到数组下标。这一步等价于 hash % n，但位运算更快，且要求n必须是2的幂次。HashMap在扩容时始终保持容量是2的幂，就是为了让这个位运算成立。

第三步：判重。如果桶位置为空，直接newNode放入；如果桶位置不为空，说明有冲突，需要遍历桶里的链表或树，逐一调用equals比较。如果某个元素equals相等，说明key已存在，HashSet.add直接返回false（因为map.put返回了旧value，不为null）。如果遍历完都没找到相等的，新节点会插入链表尾部（JDK 8的尾插法，JDK 7是头插法，尾插法避免了并发扩容时循环链表的问题，但HashSet本身不保证线程安全，这个改进更多是给HashMap单线程场景下更稳定的行为）。

第四步：扩容检查。插入完成后，HashMap会检查当前size是否超过了阈值 threshold = capacity * loadFactor，超过就触发扩容。

一个关键的认知：HashSet每次add的耗时不是固定的，大多数时候是O(1)，但哈希冲突严重时会退化成O(n)（链表场景）或O(log n)（红黑树场景）。实际开发里，如果确定集合元素会特别多，可以考虑在构造HashSet时指定初始容量和加载因子，减少扩容次数。

4.2 扩容机制：resize为什么高效

HashMap扩容是HashSet性能优化的核心环节。JDK 8的resize有两个值得说的点：容量翻倍和链表拆分。

容量翻倍很好理解，数组长度变为原来的两倍，阈值也翻倍。做这一步时，所有旧元素需要重新计算桶位置。很多人以为要重新计算每个元素的hash，其实不用。因为下标公式是 (n - 1) & hash，扩容后n变大了，只是多了一位二进制位参与计算。具体来说，扩容前长度为16时，下标由hash的低4位决定；扩容后长度为32时，下标由低5位决定。新增的那一位取0还是取1，取决于 hash & oldCap 是否为0。

所以JDK 8的resize把每个桶里的链表拆成两条：一条是 (e.hash & oldCap) == 0 的元素，它们的位置不变；另一条是 (e.hash & oldCap) != 0 的元素，它们的新位置是“原位置 + 旧容量”。这里用位运算就完成了，不需要重新计算hash，效率非常高。

扩容时还有一个初始化细节：如果使用无参构造器 new HashSet<>()，HashMap的初始容量是16，加载因子0.75，阈值是12。也就是说，当元素数达到13个时，会触发第一次扩容，容量翻到32。如果你事先知道集合会存放100万条数据，直接 new HashSet<>(1000000 * 4 / 3 + 1) 可以省去多次扩容的损耗，但这里有个坑：初始容量未必是2的幂，HashMap构造器内部会用 tableSizeFor 方法把容量修正为最接近的2的幂次。比如你传3，它内部会变成4；传1000000，它会变成1048576。

4.3 实操案例一：用HashSet做幂等性校验

我做过一个真实的场景：支付回调接口，同一笔支付成功订单可能被上游多次通知，第一次处理成功后，后面的通知必须直接忽略。因为单机部署，所以可以用内存级Set做短期幂等。

代码思路如下：

java复制public class PaymentIdempotentChecker {
    // initial capacity=256, loadFactor=0.75, 防止频繁扩容
    private final Set<String> processedOrderNos = new HashSet<>(256);

    public boolean markIfAbsent(String orderNo) {
        return processedOrderNos.add(orderNo); // true表示第一次处理
    }

    public void remove(String orderNo) {
        processedOrderNos.remove(orderNo);
    }

    public int size() {
        return processedOrderNos.size();
    }
}

这里有个关键点：String类已经正确重写了hashCode和equals，所以直接用String作为Set的元素类型没有坑。真正容易出错的是自定义对象入Set。比如回调报文里有个包含订单号、渠道、金额的DTO，只想根据“订单号+渠道”去重，就必须按我前面写的模板重写hashCode和equals。

还有一个生产环境常用的优化：幂等校验通常需要在接口入口、核心业务逻辑之前各check一次。入口处用HashSet做快速拦截，能省去后续数据库查询和处理的成本。但这种内存集合无法跨实例共享，所以大规模分布式部署时还是要依赖Redis的SETNX或者数据库唯一索引，HashSet只能作为单机内部的“第一道防线”。

4.4 实操案例二：用LinkedHashSet实现“最近浏览记录”

产品经理提了个需求：用户浏览过的商品ID要展示在首页，最近看的排前面，去重，最多保留20条。这个需求用LinkedHashSet天然合适，因为它的插入顺序就是最早add的顺序，配合“删除最老元素、添加新元素”的反复操作，能维持一个有序去重的集合。

不过要注意，LinkedHashSet的迭代顺序是插入顺序，而不是访问顺序。如果你希望“访问过的元素排到队尾”，那就不能用LinkedHashSet直接实现，得借助LinkedHashMap的accessOrder属性。LinkedHashMap提供了三个参数的构造器，第三个参数true表示按访问顺序组织双向链表，每次get或put都会把对应节点移到链表尾部，这样链表头部的节点就是“最久未访问”的。

用LinkedHashMap实现最近浏览记录的代码：

java复制public class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int maxSize;

    public LRUCache(int maxSize) {
        super(16, 0.75f, true);
        this.maxSize = maxSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > maxSize;
    }
}

removeEldestEntry是LinkedHashMap留给子类的钩子方法，默认返回false。在每次put完成后，LinkedHashMap会调用这个方法，如果返回true，就把链表头部的节点移除——正好是“最久未访问”的元素。用这个思路，LinkedHashSet虽然本身不提供accessOrder能力，但它作为LinkedHashMap的Set视角封装，让我在需要的时候直接使用LinkedHashMap的完整能力，这也是理解集合框架底层的好处。

4.5 关于初始容量和加载因子的最佳实践

很多博客会建议“如果预计存100个元素，就用new HashSet<>(100)”，但这是不严谨的。因为HashMap的扩容阈值是容量乘以加载因子，默认加载因子0.75。如果初始容量设为100，实际可存的阈值是75，超过75就扩容。所以正确做法是：容量不要保守，要按 预计元素数 / 加载因子 + 1 来设置。比如预计存100个，建议设成 100 / 0.75 + 1 = 134，HashMap内部会tableSizeFor成256。虽然看起来浪费了一点内存，但避免了多次扩容的拷贝开销。数据量大时（比如几十万、上百万条），这个优化效果很直接。

加载因子这个参数，如果只是做去重、且已知元素量巨大，可以适当调高到0.8甚至0.9，牺牲一点查询速度换取更小的内存占用；如果查询频率极高、要求低延迟，可以调低到0.6，用更多内存换更快定位。但不建议离开默认值太远，0.75是官方在时间和空间上做的平衡。

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

5.1 可变对象入Set后的“幽灵”问题

这是踩过最深的坑之一。往HashSet里放进一个对象后，如果外部直接修改了对象中参与hashCode计算的字段，这个对象在集合里的位置就会变得“不正确”。它原本所在的桶是根据旧hashCode算出来的，现在去contains或remove时，集合会用新的hashCode定位到另一个桶，结果什么都找不到。这个对象就成了集合里的“幽灵元素”，明明还在集合里，却无法被正确访问。

我遇到过一个真实案例：任务调度器里有Set，Task有个state字段参与hashCode计算。任务执行过程中state从PENDING变成RUNNING，然后又变成FINISHED，结果remove的时候怎么都删不掉。复查代码时发现，Task对象虽然已添加到Set中，但state一直在变，导致它“驻留”在一个错误的桶里。

解决这类问题有两个思路：一是设计上让入Set的对象不可变，所有参与hashCode计算的字段都用final修饰，或者干脆不把state这类会变化的字段纳入hashCode计算；二是如果必须可变，要在修改字段之前先从Set中移除，改完再add回去。我后来统一规范了团队里“入集合对象必须不可变”这条铁律，虽然麻烦一些，但直接从源头上消除了这类难以排查的bug。

5.2 遍历时修改集合——ConcurrentModificationException怎么排查

fail-fast机制保护了集合的一致性，但也让很多人摸不着头脑。最常见的报错场景：

java复制for (String s : set) {
    if (s.startsWith("order_")) {
        set.remove(s);  // 抛ConcurrentModificationException
    }
}

这里的for-each本质是迭代器遍历，迭代器每次next都会检查modCount。集合的remove方法会使modCount+1，但迭代器里的expectedModCount还是旧值，一检查就崩了。

正确做法是用迭代器自身的remove方法：

java复制Iterator<String> it = set.iterator();
while (it.hasNext()) {
    String s = it.next();
    if (s.startsWith("order_")) {
        it.remove();
    }
}

JDK 8之后也可以用removeIf：

java复制set.removeIf(s -> s.startsWith("order_"));

removeIf内部也是通过Iterator.remove实现的，所以不会抛异常。需要注意的是，如果你一边遍历一边往集合里加元素，无论用哪种方式都无法安全处理，应当先把待加元素收集到一个临时列表里，遍历结束后统一addAll。

5.3 装填因子为什么是0.75？为什么hash要扰动两次？

这两个问题是面试高频题，本质上都在考察“你是否理解哈希表的时间和空间权衡”。

0.75这个值不是拍脑袋定的。它在时间和空间成本之间取了平衡：负载率低于0.75，数组空闲位置多，冲突少，查找速度快，但内存浪费明显；负载率高于0.75，数组利用率高，内存节省，但冲突概率上升，链表长度增加，查询变慢。0.75是经过大量实践检验的经验值，与泊松分布配合下，链表长度超过8的概率已经极低。如果因为特殊场景改了加载因子，记住：越高越省内存但越慢，越低越快但越耗内存。

至于hash扰动，也就是 h ^ (h >>> 16)，前面已经提过，是为了让高位信息参与低位计算。数组长度是2的幂时，取下标只看低n位，如果不扰动，那些hashCode高16位不同、低16位完全相同的key会全部落进同一个桶，形成极长的链表。异或一次后，高16位的随机性被“叠加”到低16位上，分布会更均匀。这段位运算代码非常简短，带来的性能收益却不小。

5.4 面试高频追问总结

从“HashSet怎么去重”往上深挖，面试官通常会连续追问这么几个问题，我把回答要点整理成一张速查表：

回答这些题时，能自然地引用源码里的阈值8、64、0.75，以及hash扰动方法，会比背书式的概念回答更有说服力。这也是我逼着自己读源码的动力：一个类只有从源码层面理解了，才能真正在面试和开发中都游刃有余。

6. 个人经验与后续扩展建议

6.1 我踩过坑之后沉淀的几条实操心得

第一，能用LinkedHashSet就不要默认用HashSet。插入顺序没有坏处，但对某些场景有巨大价值，代价只是多两个指针的内存开销。如果你写的集合将来要打印日志、要按添加顺序消费、要稳定顺序做回归断言，LinkedHashSet都比HashSet舒服。实际项目里我几乎都用LinkedHashSet替代HashSet，只有明确不需要顺序、且元素量巨大时才切回HashSet。

第二，自定义对象入Set之前，先检查hashCode和equals是否满足契约。我见过很多线上Bug就是因为团队里有人new了对象、忘了重写这两个方法、然后往Set里add，结果数据“去重”失败。代码review时看到“new 一个业务对象再 add 进 Set”，我会强烈要求确认类里已经实现这两个方法。

第三，Set配合HashMap的“Map视图”也能玩出花。比如 Collections.newSetFromMap(new IdentityHashMap<>()) 可以按对象地址去重，而不用重写类里的equals/hashCode。这种方式在处理第三方jar包里的类时很好用，因为你不方便修改那些类的源码，但又能按自己的语义去重。

6.2 后续学习建议

如果你已经能把HashSet和LinkedHashSet的源码读通，下一步建议直接啃LinkedHashMap和HashMap的完整实现，重点看resize、treeifyBin、computeIfAbsent这些方法。很多面试官会用“把HashSet的原理讲清”来开题，再让候选人自然过渡到HashMap的扩容、红黑树、并发问题。这几个知识点串起来，一套完整的集合框架理解就成型了。

如果想进一步巩固，可以动手写一个简易的HashMap，支持put、get、resize、链表冲突处理，再对比JDK源码看看哪里不同。这个过程比单纯看十篇博客都管用，因为你会亲身体会到“扰动函数到底提升了多少分布均匀度”“为什么链表转红黑树阈值是8”这些设计决策的合理性。后端技术不是靠背出来的，是靠踩坑和重写积累起来的。