Java 无序（或散列）映射中的迭代器

据我所知，哈希映射比标准映射更可取，因为您可以在接近O（1）的时间内找到元素。这是通过使用散列或键作为数组查找来完成的。然后解决所有冲突并提取值

这对于查找非常有用，但是如果我们进行哈希查找的数组空间中的填充空间非常稀疏，那么hashmap/unorderedmap如何在不彻底遍历数组空间的情况下有效地迭代hashmap中的所有元素呢

---

编辑：但是Boost、SGI和C++11哈希映射/无序映射都有迭代器，那么它们是如何工作的呢？

除非有并行结构（例如a中的链表），否则不能：迭代将需要检查每个bucket的内容

---

因此，如果您的存储桶非常稀少，这可能成为一个因素。这就是您不想选择过高的存储桶计数的原因之一（较大的存储桶显然是浪费内存）。

迭代为O（n），其中n是映射的容量（即存储桶数）。但通常情况下，存储6把钥匙的容量不应达到100000。这意味着O（size）应该是O（capacity），这意味着迭代通常也是O（size）。

但是大多数hashmap容器都有迭代器，它们是如何工作的？我猜，通过迭代存储桶（以及通常构建存储桶内容的链表），可以实现。这可能不是最快的事情，但它确实有效，而且通常足够快™.旁注：Java

Map

实现（包括

HashMap

）也为键、值和条目提供迭代器。在某些情况下，可能会看到性能下降。例如，

while（！map.empty（））map.erase（map.begin（））是
O（n²）
，而不是人们所期望的
O（n）
。（虽然有些实现专门跟踪第一个占用的存储桶来解决这个问题。）这不应该是
O（n+m）
其中
n
是容量，
m
是条目数吗？至少在哈希表使用链接进行合并时是这样。在最坏的情况下，它需要检查
n
bucket并遵循
m-1
链接来查找所有条目。正常情况下是没有冲突。在最坏的情况下，O（n+m）是O（2n），它仍然是O（n）：它以线性方式增加。实际上，在最坏的情况下，没有重新灰化
m
可能大于
n
。但我明白你的意思。