HashSet底层基于HashMap实现，元素作为key、PRESENT为统一value；其公有构造方法不直接暴露容量与负载因子参数，而是通过内部HashMap间接控制，以简化接口设计。
HashSet 初始化时不能直接指定初始容量和负载因子，因为它的构造方法不接受这两个参数。但你可以通过其底层 HashMap 实现间接控制——关键是用带 initialCapacity 和 loadFactor 的 HashMap 构造器 来创建 backing map。
为什么 HashSet 构造方法没有 capacity 和 loadFactor 参数？
HashSet 是基于 HashMap 实现的（JDK 8+ 中，元素作为 HashMap 的 key，value 固定为一个静态的 PRESENT 对象）。它对外只暴露了简单易用的接口，而容量和负载因子的控制权交给了内部的 HashMap。所以 HashSet 的三个公有构造方法：
-
HashSet()—— 使用默认 HashMap（初始容量 16，负载因子 0.75） -
HashSet(Collection extends E> c)—— 根据集合大小预估容量 -
HashSet(int initialCapacity)—— 注意：这个initialCapacity是传给内部 HashMap 的，但 仍使用默认负载因子 0.75
也就是说，new HashSet(32) 只设了初始容量，负载因子固定为 0.75，无法修改。
如何真正同时指定初始容量和负载因子？
必须绕过 HashSet 的公有构造器，利用其受保护的构造方法（JDK 提供了包级访问的 HashSet(int, float, boolean)），但该方法是 package-private（仅限 java.util 包内使用），普通代码无法调用。
因此，**唯一可靠、可移植的方式是：自己创建 HashMap，再用它构造 HashSet**（需借助反射或继承——但反射不推荐；更实用的是继承并调用父类受保护构造器）：
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
public class CustomHashSet<e> extends HashSet<e> {
public CustomHashSet(int initialCapacity, float loadFactor) {
super(initialCapacity, loadFactor);
}
}</e></e>
然后使用：
Set<string> set = new CustomHashSet(64, 0.5f);</string>
✅ 这样就真正设置了初始容量 64、负载因子 0.5。
不推荐但“能跑通”的反射方式（仅作了解）
理论上可通过反射调用 HashSet(int, float, boolean)，但该构造器第三个参数是 boolean（标识是否为 dummy 构造），且属于非公开 API，不同 JDK 版本可能变化，生产环境应避免：
- 破坏封装性，兼容性差
- 可能触发 SecurityManager 拒绝或模块系统限制（JDK 9+）
- IDE 和静态检查工具通常会警告
实际建议：多数场景无需手动设置
除非你明确知道数据规模和性能瓶颈：
- 如果预计存 1000 个元素，用
new HashSet(1000 / 0.75 + 1)≈new HashSet(1334)就够了（默认负载因子下避免扩容） - 负载因子调低（如 0.5）可减少哈希冲突，但浪费内存；调高（如 0.9）节省空间但增加查找开销
- 日常业务代码中，优先让 JVM 自动管理；高频/大数据量集合（如缓存、批处理中间结果）才值得优化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
