我们应该使用 HashSet 吗？

Question

HashSet 由 HashMap 支持。从它的JavaDoc：

该类实现了 Set 接口，由一个哈希表（实际上是一个 HashMap 实例）支持

在查看来源时，我们还可以看到它们之间的关系：

// Dummy value to associate with an Object in the backing Map
private static final Object PRESENT = new Object();
public boolean add(E e) {
    return map.put(e, PRESENT)==null;
}

因此 aHashSet<E>由 a 支持HashMap<E,Object>。对于我们应用程序中的所有 HashSet，我们有一个引用对象PRESENT，HashMap用于值。虽然存储所需的内存PRESENT可以忽略不计，但我们仍然为映射中的每个值存储对它的引用。

使用null代替不是更有效PRESENT吗？进一步的考虑是我们是否应该HashSet完全放弃而直接使用 a HashMap，因为情况允许使用 aMap而不是 a Set。

我触发这些想法的基本问题是以下情况：我有一组具有以下属性的对象：

• 大量物品 > 30'000
• 广告订单不相关
• 有效检查是否包含项目
• 向集合中添加新项目无关紧要 选择的解决方案应在满足上述条件的上下文中执行最佳，并最大限度地减少内存消耗。在此基础上，数据结构HashSet又浮现HashMap在脑海中。在考虑替代方法时，关键问题是：

如何有效地检查遏制？

我想到的唯一答案是使用项目哈希来计算存储位置。我可能在这里遗漏了一些东西。还有其他方法吗？

我查看了各种问题，确实对这个问题有所了解，但并没有安静地回答我的问题：

• Java：HashSet 与 HashMap
• 澄清 Java 的 HashSet/HashMap 实现背后的事实
• Java HashSet 与 HashMap

我不是在寻找任何替代库或框架的建议来解决这个问题，但我想了解是否有其他方法来考虑对Collection.

Answer 1

简而言之，是的，你应该使用 HashSet。它可能不是最有效的 Set 实现，但这几乎不重要，除非您正在处理大量数据。

在这种情况下，我建议使用专门的库。如果您可以使用枚举，则使用 E​​numMap；如果您的数据主要是基元，则使用像 Trove 这样的基元映射；如果您的数据主要是基元，则使用一堆针对某些数据类型进行优化的其他数据结构，甚至是内存数据库。

不要误会我的意思，我也是一个喜欢性能调优的人，但是只有在真正必要时才应该更换内置数据结构。对于大多数情况，它们工作得很好。

如果您确实想保存最后一位内存并且不关心插入，您可以做的就是使用固定大小的数组，对其进行排序并每次都进行二分搜索。但我怀疑它比 HashSet 更有效。