在HashMap上使用HashSet的优点

Question

根据JavaDoc API，HashSet只是HashMap的包装器。因此，在HashMap上使用HashSet会有任何性能优势。自从？自从？或者只是有一个适合其他情况的不同API？

Answer 1

不，没有“表现”的好处;只有使用正确的API来解决正确的问题才能带来好处......这是相当可观的。

Answer 2

并非真的没有性能优势，它们都有不同的用途。

关于API文档中的Hashset

此类实现Set接口，由哈希表（实际上是HashMap实例）支持。它不能保证集合的迭代顺序;特别是，它不保证订单会随着时间的推移保持不变。该类允许null元素。

该类为基本操作（添加，删除，包含和大小）提供恒定的时间性能，假设散列函数在桶之间正确地分散元素。迭代此集合需要的时间与HashSet实例的大小（元素数量）加上后备HashMap实例的“容量”（桶数）之和成比例。因此，如果迭代性能很重要，则不要将初始容量设置得太高（或负载因子太低）非常重要。

请注意，此实现未同步。如果多个线程同时访问哈希集，并且至少有一个线程修改了该集，则必须在外部进行同步。这通常通过在自然封装集合的某个对象上进行同步来实现。如果不存在此类对象，则应使用Collections.synchronizedSet方法“包装”该集合。这最好在创建时完成，以防止意外地不同步访问集：

   Set s = Collections.synchronizedSet(new HashSet(...));

此类的迭代器方法返回的迭代器是快速失败的：如果在创建迭代器之后的任何时间修改了集合，除了通过迭代器自己的remove方法之外，Iterator抛出ConcurrentModificationException。因此，面对并发修改，迭代器会快速而干净地失败，而不是在未来不确定的时间冒着任意的，非确定性行为的风险。

请注意，迭代器的快速失败行为无法得到保证，因为一般来说，在存在非同步并发修改的情况下，不可能做出任何硬性保证。失败快速迭代器会尽最大努力抛出ConcurrentModificationException。因此，编写依赖于此异常的程序以确保其正确性是错误的：迭代器的快速失败行为应仅用于检测错误。

请查看此参考：HashSet