HashSet容量调优本质是调优其底层HashMap：初始容量应按预估元素数÷0.75向上取整再由JDK对齐为2的幂，负载因子默认0.75最优，非均匀哈希场景下不宜修改。
HashSet 本身不直接暴露 initialCapacity 和 loadFactor 参数，但它底层完全复用 HashMap 的存储结构——也就是说，对 HashSet 的容量与负载因子调优，本质上就是对它背后那个 HashMap 的调优。降低哈希冲突的关键，不是靠“避免碰撞”，而是通过合理设置初始桶数量和触发扩容的阈值，让元素分布更稀疏、链表更短、红黑树更少被触发。
初始容量要按需算，别直接传个整数完事
HashSet(int initialCapacity) 构造函数传入的数值，并不会直接变成桶数组大小。JDK 会自动向上取整到最接近的 2 的幂。比如传 20，实际容量变成 32；传 100，变成 128。
- 正确算法是：initialCapacity = (int) Math.ceil(预估元素总数 / 0.75)，再由 JVM 自动对齐为 2 的幂
- 例如：预计存 90 个唯一元素 → 90 ÷ 0.75 = 120 → 向上取整得 120 → JDK 调整为 128
- 如果直接 new HashSet(100)，实际容量是 128，但阈值（threshold）= 128 × 0.75 = 96，第 97 个元素就触发 resize ——反而比算准后更早扩容
负载因子不宜改动，默认 0.75 是平衡点
loadFactor 控制的是“什么时候开始扩容”，不是“能不能存下”。它影响的是平均每个桶里有多少元素（即平均链表长度）。改高或改低都可能适得其反：
- 设成 0.9：内存省了约 20%，但实测链表遍历开销增加 35%，尤其 key 的 hashCode 分布稍有偏差时，局部桶迅速堆积
- 设成 0.5：内存多占 42%，get() 速度只快 8% 左右，且 table 长期小于 64，无法触发链表转红黑树（Java 8+ 要求 length ≥ 64 且链长 ≥ 8），失去性能兜底能力
- 除非你有强证据（如所有 key 都是 UUID，散列极均匀），否则不要动 loadFactor
扩容本身会加剧局部冲突，初始容量错配比不设还糟
resize 不是简单复制，而是重哈希。新桶数是旧桶数的两倍，每个元素要重新计算位置。但如果原始数据的 hash 值低位重复（比如全是偶数 ID），扩容后仍集中在偶数下标桶中，导致部分桶严重过载，而其他桶空置。
立即学习“Java免费学习笔记（深入）”；
- 初始容量太小 → 频繁 resize → 多次重哈希 → 局部失衡累积
- 初始容量太大 → 内存浪费 + GC 压力 + CPU 缓存行利用率下降
- 真正有效的做法：基于业务数据量预估，用公式算出理论最小容量，再交由 JDK 对齐为 2 的幂
HashSet 场景下的实操建议
当你明确知道要塞多少个唯一元素（比如读数据库 500 行配置、解析 JSON 得到 237 个标签），初始化时就该主动设参：
- new HashSet(317) → 预估 237 个元素，237 ÷ 0.75 = 316 → 取整 317 → JDK 调整为 512（2⁹），阈值 = 512 × 0.75 = 384，全程无扩容
- 批量导入场景：先查 count(*)，再构造 HashSet，避免边 put 边 resize
- 缓存预热：若已知 key 列表，可提前初始化并 putAll，比逐个 add 更稳
