HashSet底层基于HashMap实现，元素作为key、value为静态对象PRESENT，唯一性由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，才拒绝插入。
立即学习“Java免费学习笔记（深入）”；
-
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，哪怕对象还在集合里——因为它现在算出的哈希值已经不对了。
