如何成为O（1）？如果你有一个空的哈希表，它显然是不变的，但是当元素数量增加并且冲突开始时，它是否也会增加复杂性？
我的意思是对于包含更多元素的表格，搜索时间会增加，这是如何不变的？
答案 0 :(得分：0)
非常简单的玩具＆＃34;静电＆＃34;经常用于向学生介绍哈希表的哈希表实现确实存在你指出的问题。
在实践中，许多流行的哈希算法实现是＆＃34;动态＆＃34; - 而不是允许表填满和哈希链越来越长，导致你指出的问题，在插入（）期间，他们主动识别何时有太多＆＃34;碰撞，然后做一些事情。 通常他们不会费心去弄清楚为什么存在如此多的碰撞 - 也就是说，他们不知道或关心真正的问题是（a）还是（c） ） - 他们继续做两者（b）和（d）：
哈希表有两种不同的方式可以获得大量冲突，并且它们都有已知的解决方案：
（a）如果有很多数据项，而不是很多桶，则会发生冲突。在尝试插入150个项目之后，具有100个插槽的（单独链接）哈希表将不可避免地具有数十个冲突。 （由于生日效应，你可能会比这更快地得到数十次碰撞）。为了避免这个问题，
（c）对于需要存储的特定项目，当前正在使用的特定哈希函数＆＃34;巧合地＆＃34;将许多物品发送到同一个桶中，许多物品会超过生日效果。为了避免这个问题，
为了防止你指出的问题， 实际的in-RAM哈希表实现在insert（）函数中有代码，偶尔会触发一些＆＃34;额外的工作＆＃34; resize-by-copying-all-entries需要O（n + k）时间来做（c）和（d），这很少发生n插入需要总时间为O（n），因此平均插入时间为O（ 1）。
许多哈希表实现 - 单独链接，线性探测等的实现 - 经常调整哈希表查找需要O(1) comparisons on average，尽管它们不能保证worst-case hash-table lookup time。
一些哈希表实现 - 跳房子哈希，布谷鸟哈希，动态完美哈希等的实现 - 做更多＆＃34;额外工作＆＃34;以（b）的形式和重复（d），但有必要多次保证hash table lookups require O(1) comparisons even in the worst case。