将数据作为键存储在具有空/空值的HashMap中是一个好主意吗？

Question

我最初编写了一个ArrayList并在其中存储了唯一值（用户名，即Strings ）。 我后来需要使用ArrayList来搜索用户是否存在。 那是搜索的O(n) 。

我的技术负责人希望我将其更改为HashMap并将用户名存储为数组中的键，将值存储为空Strings 。

所以，在Java中 -

hashmap.put("johndoe","");

我可以通过运行来查看此用户是否存在 -

hashmap.containsKey("johndoe"); 

这是O(1)对吗？

我的主管说这是一种更有效的方法来实现这一点，这对我来说很有意义，但是将hash / empty作为值放在hashmap中并将其中的元素作为键存放似乎有点过时了。

我的问题是，这是一个好方法吗？ 效率胜过ArrayList#contains或一般的数组搜索。 有用。 我担心的是，我没有看到其他人在搜索后这样做。 我可能在某个地方错过了一个明显的问题，但我看不到它。

Answer 1

由于您有一组唯一值，因此Set是适当的数据结构。 您可以将值放在HashSet ，这是Set接口的一个实现。

我的主管说这是一种更有效的方法来实现这一点，这对我来说很有意义，但是将hash / empty作为值放在hashmap中并将其中的元素作为键存放似乎有点过时了。

领导的建议是有缺陷的。 Map不是正确的抽象， Set是。 Map适用于键值对。 但是你没有价值观，只有钥匙。

用法示例：

Set<String> users = new HashSet<>(Arrays.asList("Alice", "Bob"));

System.out.println(users.contains("Alice"));
// -> prints true

System.out.println(users.contains("Jack"));
// -> prints false

使用Map会很尴尬，因为值应该是什么类型？ 这个问题在你的用例中毫无意义，因为你只有键，而不是键值对。 使用Set ，您无需询问，使用情况非常自然。

这是O（1）对吗？

是的，在HashMap或HashSet搜索是最坏情况下的O（1）摊销，而在List或数组中搜索是O（n）最坏情况。

---

一些评论指出HashSet是根据HashMap 。 这很好， 在那个抽象层面 。 在手头任务的抽象层面---存储一组独特的用户名，使用集合是一种自然的选择，比地图更自然。

Answer 2

这基本上就是HashSet的实现方式，所以我想你可以说这是一个很好的方法。 您也可以使用HashSet而不是使用空值的HashMap 。

例如 ：

HashSet的add实现是

public boolean add(E e) {
    return map.put(e, PRESENT)==null;
}

其中map是后备HashMap和PRESENT是一个虚拟值。

我担心的是，我没有看到其他人在搜索后这样做。 我可能在某个地方错过了一个明显的问题，但我看不到它。

正如我所提到的，JDK的开发人员正在使用相同的方法。