HashMap等人真的是O（1）？

Question

我正在研究Java集合性能特征，Big O表示法和复杂性等。有一个现实世界的部分我无法理解，这就是为什么HashMap和其他哈希容器被认为是O（1），这应该意味着在1000条目表中按键查找条目应该与1,000,000条目表大致相同。

假设您拥有HashMap myHashMap，使用名字+姓氏密钥存储。如果你调用myHashMap.get（“FredFlinstone”），它怎么能立即找到Fred Flinstone的Person对象？如何不必遍历存储在HashMap中的键集来查找指向对象的指针？如果HashMap中有1,000,000个条目，则密钥列表也将是1,000,000长（假设没有冲突），这必须比1.000的列表花费更多时间，即使它已经排序。那么get（）或containsKey（）时间如何不随n？

而改变

注意：我认为我的问题会在Is a Java hashmap really O(1)?中得到解答，但答案并没有真正解决这一问题。我的问题也不是碰撞。

Answer 1

“我的问题也不是碰撞问题。” - 实际上它是间接的。没有碰撞= O(1) ......

在最坏的情况下（病态情况），会有一个存储有N个项目的存储桶，然后它会是O(N)

Answer 2

计算给定键上的散列函数需要恒定的时间。查看是否存在存储到该键的值是随机访问操作 - 散列映射由数组支持。唯一的问题是确保具有SAME值（哈希冲突）的不同密钥不会经常发生。如果它在n中发生一次，那么在平均情况下这就足够了。

Answer 3

让我们看一个哈希映射和哈希函数的一个非常简单的例子。为了简单起见，我们假设您的哈希映射有10个桶，并且它使用整数作为键。出于本示例的目的，我们将使用以下散列函数：

public int hash(int key) {
  return key % 10;
}

现在，当我们想要在地图中存储一个条目时，我们对密钥进行散列，得到0-9之间的整数，然后将该条目放入相应的存储桶中。然后，当我们需要查找密钥时，我们只需要计算它的哈希值，并且我们确切地知道它在（或将在其中）的存储桶而不必查看任何其他存储桶。