当我知道最终元素数时，Hashmap创建性能

Question

如果我知道HashMap中元素的最终大小，从性能的角度来看，构建它的最佳方法是什么？基于JavaDoc以避免重复以下操作：

int TOTAL_ELEMENTS_TO_BE_STORED = 10;
... = new HashMap<T, Q>( TOTAL_ELEMENTS_TO_BE_STORED + 1, 1.0f );

但也是：

... = new HashMap<T, Q>( Math.ceil(TOTAL_ELEMENTS_TO_BE_STORED * 1.333) + 1 );

我从HashMap javadoc中读到：

  

较高的值会减少空间开销，但会增加查找成本（反映在HashMap类的大多数操作中，包括get和put）。

查找成本会更高吗？在这种情况下，通常建议使用默认的0.75负载系数，而是提供更大的容量或相反的情况？

Answer 1

是的，查询费用会更高。

选择取决于您的要求。

• 您需要能够快速查找元素，并且您的数据足够小 - 保留0.75负载系数
• 您拥有大量数据并且不想节省大量内存 - 请使用1.0作为加载因子。

BTW，负载系数不在[0.75,1]范围内 - 您可以选择任何正值。值越多，您需要的内存越少，但查找的时间就越长。

Answer 2

如果问题是关于性能并且您事先知道元素的数量，那么选择具有open addressing（自编或来自某个库）的哈希表可能会更好，但不能选择标准{{ 1}}。

使用少量元素，简单HashMap可能比任何哈希表数据结构更快。你需要做一些基准测试。

Answer 3

最昂贵的是用于存储的内部数组的resizing阶段。此时的条目需要重新散列并可能移动到不同的桶。虽然重新调整大小也可能由于其他一些原因而发生;避免显而易见的是一个很好的选择。

如果您知道自己将拥有多少条目，只需将该条目添加33％，并保留load_factor的默认0.75。

例如，当您有16个桶时，在调整大小之前只能放入12个条目。

此外，数组的大小是下一个power of two - 即使您没有这样提供。所以，如果你有100个条目; 125是+33%;内部大小将为128。