我相信插入哈希表是平均情况 O(1) 和最坏情况 O(n)。因此，如果我们遍历一个字符串并将每个单词添加到一个哈希表（将单词映射到它在字符串中出现的次数），那不是 O(n^2) 运行时的最坏情况吗？我之前试图问过这个问题，但答案说这是最坏的情况 O(n)。谢谢！
【问题讨论】：
O(|s|) 平均时间，其中|s| 是字符串的长度。这就是计算哈希的成本，即使您缓存每个字符串的哈希并将其成本分摊到大量插入中，您仍然需要支付O(|s|) 才能发现您刚刚查找的字符串是表（通过比较每个字符）。因此，如果字符串只有一个字符，则只有 O(1)，在这种情况下，哈希表可能会过大。
标签： algorithm data-structures hash big-o hashtable
您是对的，在合理的假设下，哈希表将在 O(1) 平均时间和 O(n) 更坏情况时间中插入元素。
至于您的问题，假设您在一个字符串中有 n 个单词，您将不得不遍历每个单词并将其输入到哈希表中，这将花费 O(n) 平均时间或 O(n^2) 最坏情况时间。
【讨论】：
插入的最坏情况取决于插入函数的实现如何处理冲突和解决技术。这将对 put() 和 get() 操作产生更大的影响。冲突解决技术在每个库中的实现方式不同。核心思想是将所有碰撞的键保存在同一个桶中。并且在检索期间遍历所有冲突的键并应用一些相等性检查来检索给定的键。需要注意的重要一点是，我们需要在存储桶中同时维护“键”和“值”，以方便上述相等性检查。
要考虑的另一件事是，在插入操作期间，将为给定键生成哈希码。我们可以认为这是每个键的常数 O(1)。
在最坏的情况下，所有的键都可能落在同一个桶中，因此 O(n) for 1 get(). 但是对于 put() 操作，它总是恒定的 O( 1) 与碰撞无关。
维护碰撞列表是一个关键因素。一些实现使用 BST 而不是链表。因此，插入和检索的最坏情况是 O(log N)。
不惜任何代价，O(N log N) 可能是插入 N 个元素的运行时间，而不是 O(N^2)。
任何体面的实现都必须确保生成的对象的最小冲突哈希码，以获得更好的性能。
【讨论】：