HashSet元素唯一性原理解析

HashSet的元素唯一性并非来自“哈希表”本身的神秘机制，而是由底层HashMap的put逻辑严格保障——关键在于hashCode()与equals()方法必须协同工作：hashCode()决定元素落进哪个桶，而equals()在桶内逐个比对以最终判定重复；二者缺一不可，且重写时必须保持契约一致——参与equals比较的字段必须全部纳入hashCode计算，反之亦然；尤其要注意可变对象一旦修改影响哈希值的字段，就会导致该对象在HashSet中“失联”，再也无法被查找或删除；String、Integer等内置类之所以开箱即用，正是因为它们早已按值语义正确实现了不可变、一致的hashCode和equals。

HashSet底层用的是HashMap，不是哈希表独立实现

Java里的HashSet本身不存储元素，它只是HashMap的一个包装：所有添加的元素都作为HashMap的key，而value统一是同一个静态对象PRESENT（类型为Object）。所以“唯一性”实际由HashMap的put逻辑保证。

这意味着：判断两个元素是否重复，完全依赖于hashCode()和equals()两个方法的配合。缺一不可。

• 如果只重写hashCode()不重写equals()，可能把逻辑上相等的对象散列到同一桶，但比较时用的是Object.equals()（即地址比较），导致重复插入
• 如果只重写equals()不重写hashCode()，对象大概率被分配到不同桶中，HashMap甚至不会调用equals()去比——因为压根没进同一个链表或红黑树

hashCode()返回值决定桶位置，但不决定唯一性

HashSet.add(e)执行时，先调用e.hashCode()，再与table.length - 1做按位与（即hash & (n-1)），算出数组下标。这一步只决定“去哪个桶找”，不是“算不算重复”。

真正判定重复发生在桶内：如果桶里已有节点，就遍历链表或红黑树，对每个节点调用node.key.equals(e)。只有hashCode()相同 且 equals()返回true，才拒绝插入。

• hashCode()冲突很常见（比如"ABC"和"BCE"在某些JDK版本中可能同码），只要equals()能兜底，就不影响正确性
• 但hashCode()分布越均匀，桶越少链化，查找越快；过度冲突会导致从O(1)退化成O(n)
• JDK 8之后，当桶中节点数≥8且table.length ≥ 64，会转成红黑树，此时查找是O(log n)，但构造树本身有开销

自定义类放进HashSet必须同时重写hashCode和equals

这是最容易翻车的地方。IDE生成的hashCode()/equals()通常没问题，但要注意：

• 参与equals()比较的字段，必须全部参与hashCode()计算；反之，hashCode()里用的字段，最好也在equals()里用到
• 字段值为null时，Objects.hash(...)能安全处理；手写别直接调field.hashCode()，否则NPE
• 如果类是可变的（字段后续会被修改），且对象已加入HashSet，之后改了影响hashCode()的字段——这个对象很可能再也找不到了，也删不掉

示例：new Person("Alice", 25)和new Person("Alice", 25)要被视为相同，就必须确保这两个对象的hashCode()相等、equals()返回true。否则HashSet会存两份。

String、Integer等JDK内置类为什么能直接用

因为它们的hashCode()和equals()早已按值语义实现好，并严格遵循契约：

• String.hashCode()基于字符序列计算，相同内容字符串一定同码
• Integer.hashCode()直接返回其int值，new Integer(100)和Integer.valueOf(100)（缓存范围内）甚至可能==
• 它们都是不可变类，放入HashSet后不会因内部状态改变导致哈希失联

但注意：new Integer(1000)和new Integer(1000)虽然equals()为true，但==为false——这正好说明HashSet依赖的是equals()，不是引用相等。

真正容易被忽略的是：一旦你往HashSet里放了可变对象，又在外部改了它的状态，那个桶位置就失效了。这时候contains()可能返回false，哪怕对象还在集合里——因为它现在算出的哈希值已经不对了。

今天关于《HashSet元素唯一性原理解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！