HashSet初始容量应设为≥预估元素数÷0.75的最小2的幂，加载因子默认0.75是时空平衡点；容量过小致频繁扩容，过大浪费内存；调加载因子需谨慎，优先调整初始容量。
HashSet 的初始容量和加载因子直接影响内存占用和操作速度，不是设得越大越好，也不是越小越省，关键在平衡。
初始容量决定底层数组大小
HashSet 底层用 HashMap 存储，数组长度就是“容量”。默认是 16，且始终是 2 的幂（如 16、32、64）。容量太小会导致频繁扩容；太大则浪费空间。
- 每次扩容要新建数组、重新哈希所有元素、搬运数据——开销不小
- 如果预估要存 100 个元素，按默认加载因子 0.75 算，100 ÷ 0.75 ≈ 134，取最近的 2 的幂是 256，直接 new HashSet(256) 就能避免首次扩容
- 容量设为 134 或 150 没用，HashMap 会自动向上取整到 256
加载因子控制扩容时机
加载因子是“触发扩容”的密度阈值，默认 0.75。当元素数量 > 容量 × 加载因子时，就扩容。
- 设成 0.9：空间利用率高，但哈希冲突概率上升，链表变长，get/contains 可能变慢
- 设成 0.5：冲突少、查询快，但数组一半空着，内存浪费明显，且更早触发扩容
- 0.75 是 JDK 经验值，在空间和时间之间做了折中
扩容过程本身有性能代价
扩容不只是“变大”，而是整个重建过程：
立即学习“Java免费学习笔记（深入）”；
- 申请新数组（容量翻倍）
- 对每个已有元素重新计算 hash 值
- 根据新容量重定位位置（可能从链表进红黑树，也可能反之）
- 所有线程在此期间会被阻塞（HashSet 本身非线程安全，但 rehash 是独占操作）
实际选值建议
不靠猜，靠预估：
- 已知大概存 N 个元素 → 初始容量设为 ≥ N ÷ 0.75 的最小 2 的幂
- 读多写少、对查询延迟敏感 → 可略调低加载因子（如 0.6），换更快查找
- 内存紧张、元素极少变动 → 可略调高（如 0.85），但别超 0.9
- 除非明确压测过，否则不建议改加载因子；优先调初始容量更安全有效
