合理设置 HashSet 初始容量需满足：容量 ≥ 元素数 ÷ 0.75，再向上规整为最接近的 2 的幂；如存 1000 个元素，1000 ÷ 0.75 ≈ 1334，规整为 2048。
合理设置 HashSet 初始容量，核心是让集合在装满预估元素时，刚好达到扩容阈值（即 容量 × 0.75），避免首次插入就触发扩容，也避免预留过大浪费内存。
先算理论最小容量
HashSet 底层用 HashMap 存储，扩容触发条件是：元素个数 ≥ 容量 × 负载因子（默认 0.75）。所以如果你明确知道要放 n 个元素，理论最小容量应满足：
- n ≤ capacity × 0.75 → 推出 capacity ≥ n / 0.75
- 比如预计放 1000 个元素：1000 ÷ 0.75 ≈ 1333.33，向上取整得 1334
再取最接近的 2 的幂次方
HashMap（也就是 HashSet）内部数组长度必须是 2 的幂。JDK 会自动把传入的初始容量“规整”为 ≥ 该值的最小 2 的幂。例如：
- 传 1334 → 规整为 2048（2¹¹ = 2048）
- 传 16 → 保持 16（2⁴）
- 传 17 → 规整为 32（2⁵）
你可以手动计算：用 Integer.highestOneBit(n - 1) 或直接查表（16、32、64、128、256、512、1024、2048、4096…），选第一个 ≥ 理论值的即可。
要不要加 1？看场景
有些资料建议公式写成 (int)(n / 0.75) + 1，目的是留一点余量防止边界抖动。但实际效果有限——因为 JDK 自动规整后往往已有足够空间。更稳妥的做法是：
- 若 n 较小（
- 若 n 在几百到几千，按上述方法算出 2 的幂后，再确认下：2048 × 0.75 = 1536，能稳装 1000 个，没问题
- 若对内存极度敏感（如嵌入式或高频实时系统），可适当调高负载因子（如 0.9），但会略微增加哈希冲突概率
验证是否值得设
不是所有场景都需要手动指定。以下情况可跳过：
- 集合生命周期短、元素少（≤ 50）、使用频次低
- 无法预估大小，或大小波动极大（如从几个到上万）
- 项目已用对象池或复用机制，集合被反复清空重用
反之，像缓存规则、批量解析结果、配置项去重等大小稳定且可预估的场景，设对初始容量能减少 1～2 次扩容，提升初始化和写入性能。
