Java 对于较小的贴图，HashMap速度更快

这可能是一个奇怪的问题，但它是基于我使用Java Map得到的一些结果——当Map较小时，HashMap的元素检索速度是否会更快

我有一部分代码使用了

HashMap

的

containsKey

和

get（key）

方法，如果映射中的元素数量较少，那么运行速度会更快？是这样吗

据我所知，

HashMap

使用一些散列函数来访问映射的某个字段，在某些版本中，该字段是对链表的引用（因为一些键可以映射到相同的值），或者是映射中的其他字段，当完全静态实现时

这是否正确？如果地图元素较少，速度可能会更快

我需要用一个具体的例子来扩展我的问题

我有两种情况，两种情况下的元素总数是相同的

• 在第一种情况下，我有10个hashmap，我不知道元素是如何分布的。该部分算法的执行时间为141ms
• 在第二种情况下，我有25个hashmap，元素总数相同。同一算法的执行时间为69ms

在这两种情况下，我都有一个for循环，它遍历每个hashmap，试图找到相同的元素，并获取元素（如果存在）

是否执行时间会更小，因为HashMap中的单个搜索更小，所以是否存在总和

我知道这很奇怪，但这样的事情是可能的，还是我做错了什么

---

考虑映射（整数，双精度）。很难说元素的分布是什么，因为它实际上是KMeans聚类算法的一个实现，元素是聚类质心的表示。这意味着它们主要取决于算法的初始化。元素的总数在很大程度上是不一样的，但是我已经尝试过简化这个问题，如果这有误导性的话，很抱歉。

碰撞的数量对于减速是决定性的

假设一个数组有一定的大小，对该大小进行模化的哈希代码将指向放置该对象的索引。具有相同索引的两个对象发生碰撞

就元素数量而言，拥有大容量（数组大小）会有所帮助

对于，存在具有额外设置的重载构造函数

public HashMap(int initialCapacity,
               float loadFactor)

构造具有指定初始容量和负载因子的空哈希映射

你可以尝试一下

对于与HashMap一起使用的特定键类，拥有好的hashCode也会有所帮助。散列码是一个单独的数学字段

---

当然，使用较少的内存有助于提高处理器/物理内存级别，但我怀疑这种情况会产生影响。

您的计时是否只考虑了

获取
/
containsKey
的成本，或者您是否也在计时代码部分执行
放入
的操作？如果是这样，并且使用默认构造函数（初始容量16，负载系数0.75），则较大的哈希表需要比较小的哈希表更频繁地调整自身大小。就像Joop Eggen在回答中所说的，试着利用构造函数中的初始容量，例如，如果您知道您有
N
元素，则将初始容量设置为
N/number\u\u hash\u tables
或类似的值-这应该会导致更小和更大的hash tables具有足够的容量，因此它们不需要调整大小
我知道您在说什么，但如果我会添加一些具体的细节。任何更小的数据结构都会更好更快地适合CPU缓存。这与其说是数据结构的一个特性，不如说是CPU的工作方式。谢谢，这是一个很好的观察结果，通常非常有用。你从我这里得到+1。你能考虑一下我的具体问题吗？请提供关于你使用的元素的类型的信息，hash码/等于重写，总共有多少个元素。如果您不知道元素是如何分布的，那么在第一种情况下，所有元素都放在最后检查的地图中，而在第二种情况下，它们都放在第一个地图中，会发生这种情况吗？谢谢您的回答，很好，但不考虑放置。