为什么Sun Java中的HashSet实现使用HashMap作为支持？

Question

看一下Java 6的源代码，HashSet<E>实际上是通过HashMap<E,Object>使用Set的每个条目上的伪对象实例来实现的。

我认为这浪费了4字节（在32位计算机上）用于条目本身的大小。

但是，为什么仍然使用它呢？除了使代码维护更容易之外，还有什么理由要使用它？

Answer 1

实际上，不只是HashSet。 Java 6中该接口的 所有
实现Set都基于底层Map。这不是必需的；这只是实现的方式。您可以通过查阅有关的各种实现的文档来自己查看Set。

您的主要问题是

但是，为什么仍然使用它呢？除了使代码维护更容易之外，还有什么理由要使用它？

我认为代码维护是一个很大的动机。因此防止重复和膨胀。

Set和Map相似的接口，因为不允许重复的元素。（我认为唯一Set 不受a
支持的Map是CopyOnWriteArraySet，这是一个不寻常的Collection，因为它是不可变的。）

特别：

从以下文档中Set：

不包含重复元素的集合。更正式地说，集合不包含元素对e1和e2，使得e1.equals（e2）最多包含一个空元素。顾名思义，此接口对数学集合抽象进行建模。

除了从Collection接口继承的规定之外，Set接口还对所有构造函数的协定以及add，equals和hashCode方法的协定规定了其他规定。为了方便起见，还包括其他继承方法的声明。（这些声明随附的规范是针对Set接口量身定制的，但不包含任何其他规定。）

毫不奇怪，对构造函数的附加规定是，所有构造函数都必须创建一个不包含重复元素的集合（如上定义）。

来自Map：

将键映射到值的对象。映射不能包含重复的键；每个键最多可以映射到一个值。

如果您可以Set使用现有代码实现，那么您也可以从现有代码中获得任何好处（例如速度）Set。

如果您选择Set不带任何Map支持的实现，则必须复制旨在防止重复元素的代码。啊，好讽刺。

也就是说，没有什么可以阻止您Set以不同的方式实现。