在HashMap上使用HashSet的优点
根据JavaDoc API，HashSet只是HashMap的包装器。 因此，在HashMap上使用HashSet会有任何性能优势。 自从？ 自从？ 或者只是有一个不同的API适合其他情况？
不，没有“表现”的好处; 只有使用正确的API来解决正确的问题才能带来好处……这是相当可观的。
并非真的没有性能优势，它们都有不同的用途。
关于API文档中的Hashset
此类实现Set接口，由哈希表（实际上是HashMap实例）支持。 它不保证集合的迭代顺序; 特别是，它不保证订单会随着时间的推移保持不变。 该类允许null元素。
该类为基本操作（添加，删除，包含和大小）提供恒定的时间性能，假设散列函数在桶之间正确地分散元素。 迭代此集合需要的时间与HashSet实例的大小（元素数量）加上后备HashMap实例的“容量”（桶数）之和成比例。 因此，如果迭代性能很重要，则不要将初始容量设置得太高（或负载因子太低）非常重要。
请注意，此实现不同步。 如果多个线程同时访问哈希集，并且至少有一个线程修改了该集，则必须在外部进行同步。 这通常通过在自然封装集合的某个对象上进行同步来实现。 如果不存在此类对象，则应使用Collections.synchronizedSet方法“包装”该集合。 这最好在创建时完成，以防止对集合的意外不同步访问：
Set s = Collections.synchronizedSet(new HashSet(...));
这个类的迭代器方法返回的迭代器是快速失败的：如果在创建迭代器之后的任何时候修改了set，除了通过迭代器自己的remove方法之外，迭代器抛出ConcurrentModificationException。 因此，在并发修改的情况下，迭代器快速而干净地失败，而不是在未来的未确定时间冒任意，非确定性行为的风险。
请注意，迭代器的快速失败行为无法得到保证，因为一般来说，在存在不同步的并发修改时，不可能做出任何硬性保证。 失败快速迭代器会尽最大努力抛出ConcurrentModificationException。 因此，编写依赖于此exception的程序以确保其正确性是错误的：迭代器的快速失败行为应该仅用于检测错误。
检查此参考： HashSet