HashSet无序且不保证插入顺序，基于哈希表实现，依赖equals()和hashCode()判重，需重写二者并保持逻辑一致；线程不安全；初始容量指桶数组长度，非元素上限；哈希分布影响性能；元素须可序列化。
Set 接口不保证插入顺序，但 HashSet 是无序的典型代表
Java 的 Set 接口只承诺元素唯一、不重复，**不规定顺序**。而 HashSet 是基于哈希表实现的，它既不维护插入顺序，也不保证任何逻辑顺序——哪怕你连续 add("a"), add("b"), add("c")，迭代结果可能每次都不一样（取决于哈希值和扩容时机）。
如果你需要记住插入顺序，请直接换用 LinkedHashSet；如果需要自然排序，用 TreeSet。别指望 HashSet 碰巧“看起来有序”就在线上环境依赖它。
-
HashSet允许一个null元素，但不能存重复对象（靠equals()+hashCode()判重） - 自定义类放进
HashSet前，必须重写equals()和hashCode()，且二者逻辑要一致 - 多线程环境下，
HashSet不是线程安全的；要用Collections.synchronizedSet(new HashSet())或ConcurrentHashMap.newKeySet()（JDK 8+）
new HashSet(initialCapacity) 的初始容量不是“能存多少个”
HashSet 构造时传的 initialCapacity 实际是底层 HashMap 的初始桶数组长度，**不是元素个数上限**。真正触发扩容的是「元素数量 > 容量 × 负载因子」（默认负载因子 0.75）。
比如 new HashSet(16)，最多存 12 个元素就会扩容（16 × 0.75 = 12）。若你明确知道要塞 100 个元素，应设为 new HashSet(134)（向上取整到 2 的幂：128 → 128×0.75=96 不够，所以用 134 对应 128 的下一个 2 的幂？不对——更稳妥是直接算：100 / 0.75 ≈ 133.3 → 向上取整为 134，然后 HashMap 会自动对齐到 256）。
立即学习“Java免费学习笔记（深入）”；
- 常见误写：
new HashSet(100)，以为能无扩容存 100 个——实际在第 76 个元素时就扩容了 - 构造时传入
initialCapacity过大会浪费内存；过小会导致频繁 rehash，影响性能 - 如果用
HashSet(Collection)构造，内部会按源集合 size / 0.75 + 1 计算初始容量，一般够用
contains() 和 remove() 的性能依赖 hashCode() 分布质量
HashSet.contains() 和 remove() 平均时间复杂度是 O(1)，但这前提是哈希值分布均匀。一旦大量对象返回相同 hashCode()（比如所有对象都 return 1），它们会挤进同一个桶，退化成链表遍历，最坏变成 O(n)。
尤其注意 String、Integer 等 JDK 类已优化良好；但自定义类若只重写 equals() 忘了 hashCode()，或 hashCode() 返回常量，就会踩坑。
- 测试哈希分布：可临时把
HashSet替换为LinkedHashSet，再遍历set.stream().map(o -> o.hashCode()).collect(Collectors.groupingBy(i -> i, Collectors.counting()))查看碰撞情况 - IDE 自动生成的
hashCode()（如 IntelliJ 的 “Generate → hashCode and equals”）基本可靠，避免手写简单常量返回 - 使用 Lombok 的
@EqualsAndHashCode时，确保未被忽略的字段参与计算，且字段本身有合理hashCode()
HashSet 无法序列化非 Serializable 元素
HashSet 本身实现了 Serializable，但序列化时会递归序列化每个元素。如果其中某个元素类型没实现 Serializable（比如某个内部类没加 static、或用了 ThreadLocal 字段），反序列化时会抛 java.io.NotSerializableException。
这个异常不会在 add() 时出现，而是在 writeObject / readObject 阶段才暴露，容易漏测。
- 检查方式：对集合做
new ObjectOutputStream(new ByteArrayOutputStream()).writeObject(set)单元测试 - 修复手段：让元素类实现
Serializable，或标记不参与序列化的字段为transient - 若用 JSON 库（如 Jackson）替代 Java 原生序列化，问题表现不同（可能报 No Serializer found），但根源仍是对象结构不可序列化
public class Person {
private String name;
private int age;
// 必须同时存在，且逻辑一致
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person person = (Person) o;
return age == person.age && Objects.equals(name, person.name);
}
@Override
public int hashCode() {
return Objects.hash(name, age); // ✅ 推荐用 Objects.hash
}
}
真实项目里，HashSet 的坑往往不在语法，而在哈希一致性、序列化边界、并发误用这些隐性约束上。写完 equals/hashCode 后，记得跑一遍单元测试验证判重逻辑；上线前确认是否涉及跨 JVM 传递——那就不只是“能跑”，而是“能正确重建”。 
