Java哈希集性能

我是根据HashMap来理解HashSet的，因为它们非常相似。它使代码更加灵活，并使实现工作量最小化。但是，如果类禁止

null

元素，则HashSet的

条目中的一个引用变量对我来说似乎是不必要的，因此整个条目没有意义。尽管如此，一个
条目
需要24字节的内存/元素，而如果我的数字正确，一个包含集合元素的数组只需要4字节/元素。（除了数组的头）

如果我的论点是正确的，那么这些优势真的会加重这次性能打击吗？

（如果我错了，我也会从中吸取教训）
虽然这个问题主要是基于观点的，但我会总结一些关于这个主题的观点：


HashSet
多年前出现在Java1.2中。现在很难猜测当时做出设计决策的确切原因，但显然Java没有用于高负载的应用程序；性能所起的作用不如简单
您是对的，
HashSet
在内存消耗方面是次优的。问题是已知的，bug是注册的，并且会不时在上进行讨论。但是，对于许多实际应用程序来说，这是一个拦截器吗？可能不会
对于那些无法接受
HashSet
内存使用的不常见应用程序，已经有了很好的替代方案，比如trove
请注意，开放寻址算法有其缺点，例如，当负载系数接近1时，性能会显著下降；元素移除困难。看
单个数组不是哈希集。如何将O（1）contains（）与一个简单数组结合使用？@JBNizet线性探测（或通常的开放寻址）只与一个数组结合使用。我也很好奇设计决定是什么，但我不确定我们是否找到了要报告的作者；-）@JBNizet您可以轻松地在一个数组中实现几种类型的哈希表，即布谷鸟、线性等。。。编辑：linear没有O（1）contains（），但布谷鸟确实有一些库将其映射作为其集合的扩展来实现，这将更有效，但是这个决定至少是20年前做出的，所以虽然当时是有意义的，但现在可能不是最优的。@PeterLawrey实际上不到20年前。20年前，Java1.1还没有问世。HashSet是在1.2中引入的。