HashSet平均操作为O(1)，依赖哈希定位；最坏O(n)源于哈希冲突严重；扩容时O(n)重散列；线程不安全，多线程需并发控制。
HashSet 的性能特点主要围绕“快”和“稳”两个维度展开，关键看它在什么条件下快、为什么有时不够稳。
平均操作接近 O(1)，靠哈希定位
添加、删除、查找元素时，HashSet 先调用元素的 hashCode() 计算哈希值，再根据该值快速定位到哈希表中的桶（bucket）。只要哈希分布较均匀，基本一步到位，所以平均时间复杂度是常数级 O(1)。
- 理想情况：每个元素哈希值不冲突，直接映射到独立位置
- 实际中：少量冲突由链表或红黑树处理（JDK8+），仍能维持高效
最坏情况退化为 O(n)，源于哈希冲突严重
如果大量元素的 hashCode() 返回相同值（比如自定义类没重写 hashCode 或返回固定值），所有元素会挤进同一个桶。此时查找需遍历整个链表或树，时间开销变成线性 O(n)。
- 典型诱因：自定义对象未正确实现 hashCode() 和 equals() 方法
- 隐性风险：String 等常用类型没问题，但 Student、User 等类容易踩坑
扩容机制影响阶段性性能
HashSet 默认初始容量是 16，负载因子 0.75。当元素数量超过 16 × 0.75 = 12 时，会触发扩容——重建哈希表、重新散列所有元素。这个过程是 O(n) 的，虽不频繁，但在批量插入场景下可能造成短暂卡顿。
- 可预估数据量时，建议构造时指定初始容量，如
new HashSet(1000) - 避免频繁扩容，也能减少内存碎片和哈希重散列次数
线程不安全带来隐性开销
HashSet 本身不是线程安全的。若在多线程环境下直接使用，可能出现数据丢失、死循环（如 HashMap 扩容时的环形链表）等问题。强行加锁或改用 Collections.synchronizedSet() 会引入同步开销，性能明显下降；更优解是换用 ConcurrentHashMap.newKeySet()（JDK8+）。
- 单线程环境：无额外开销，性能最优
- 多线程环境：必须做并发控制，否则行为不可预测
