最高效方式是预估元素数N后计算(int)(N/0.75)+1再向上取最近2的幂作为初始容量；因HashSet底层HashMap要求容量为2的幂，直接传N会导致无效或误判扩容时机，负载因子默认0.75已平衡时空开销。
最高效的方式是：预估元素总数，代入公式 (int)(预计元素数 / 0.75) + 1，再向上取最近的 2 的幂次作为初始容量，并保持负载因子为默认 0.75。
为什么不能直接用预计数量？
HashSet 底层基于 HashMap，其数组容量必须是 2 的整数次幂。即使你传入 new HashSet(20)，实际初始化容量也会被自动调整为 32（因为 32 是 ≥20 的最小 2 的幂）。若直接设为 20，不仅无效，还可能误导自己以为“刚好够用”，结果在插入第 15 个元素时就触发首次扩容（16 × 0.75 = 12），带来不必要的 rehash 开销。
怎么算出真正该传的数值？
按预期存放 N 个唯一元素，推荐分两步：
- 先算理论最小容量：
(int)(N / 0.75) + 1（加 1 是防临界扩容） - 再取该值向上最近的 2 的幂 —— Java 内部用
tableSizeFor()实现，你无需手算，但可快速估算：
• N = 50 → 50 ÷ 0.75 ≈ 66.7 → 取 67 → 最近 2 的幂是 128
• N = 100 → 100 ÷ 0.75 ≈ 133.3 → 取 134 → 最近 2 的幂是 256
• N = 12 → 12 ÷ 0.75 = 16 → 取 17 → 最近 2 的幂是 32（不是 16）
负载因子要不要改？
一般不建议改动。默认 0.75 是时间与空间的平衡点：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 设为 1.0 虽省空间，但哈希冲突概率上升，查找变慢
- 设为 0.5 查找更快，但内存占用翻倍，且频繁扩容反而更耗时
- 除非业务极度敏感于内存（如嵌入式）或极度追求读性能（且写极少），否则保持 0.75 即可
代码示例与验证
正确写法：
Set<String> set = new HashSet<>(128); // 预估存 96 个左右元素（128 × 0.75 = 96）
错误写法：
-
new HashSet(96)→ 实际容量仍为 128，但语义不清，易被误读 -
new HashSet(96, 1.0f)→ 容量变为 128，阈值变成 128，看似“刚好”，实则冲突率显著升高
