问题描述
假设我有一个哈希集，我决定其中仅包含3个元素。但是，例如，我随机插入和删除N个乱七八糟的单词，而一次最多不会包含3个元素。
此集合的空间复杂度是否仍为o（1），还是我可能要插入然后删除一百万（或任何其他）输入的事实会使哈希集发生变异，从而使该集合的大小成比例到N的方式？
解决方法
这将取决于您使用的特定哈希表实现，但是哈希表的“良好”实现在O（1）空间中应该没有问题。
更具体地说：
-
如果您使用链式哈希表，则通常仅在负载系数（元素与表槽之比）超过某个阈值时才调整表的大小。如果元素总数始终最多为三个，则此条件将永远不会触发。
-
如果您使用的是布谷鸟哈希表，如情况（1）所示，则仅在加载因子较高时才调整表的大小，因此，只有三个活动元素时，该表必须足够大才能重新调整大小在保持其负载系数的同时按住三个项目。
-
对于线性探测表或另一个打开的寻址表（二次探测，双哈希等），已删除的元素会用墓碑标记，这会导致在删除多个元素后，该表会被使用的插槽填满。但是，合理的表实现可以通过删除逻辑删除数量过多的表来轻松解决此问题。因此，大小不应取决于过去已插入的元素总数。
-
对于具有向后移位删除功能的Robin Hood哈希表，不需要逻辑删除，并且表的大小不应增加。
但是，这并不意味着哈希表的所有实现实际上都将执行此操作。而是说，这实际上并不意味着“标准”哈希表实际上不需要根据已添加的元素数来增长，而不必根据任何一点上存储的最大元素数来增长。
话虽这么说，我确实想知道哈希在这里是否是正确的主意。如果您知道一次只处理三个项目，并且担心性能，那么只用三个变量保存三个项目然后检查每个项目可能会更快。
,哈希表的空间复杂度为O（N + H），其中N是哈希表中元素的（最大）数目，而H是哈希表的原始大小（通常为常数）。
例如，如果您的哈希函数是X % 51，则有51个框用于存储元素。这是O（1），固定大小。如果发生哈希冲突，则可以使用链表（或另一个哈希函数）将多个元素存储在单个框中。这将增加与散列表中存储的元素数量成比例的内存需求，大小为O（N）。
如果您继续以不超过3个元素（N = 3）的方式存储和删除元素的情况，则哈希表的大小为O（1），因为两个原始元素的大小和最大数量是一个常数。插入和删除元素不会改变哈希函数。