java - IdentityHashMap 和 expectedmaxsize

我一直在浏览 IdentityHashMap 的文档。
该类有一个 constructor ，它采用 expectedmaxsize 。

public IdentityHashMap(int expectedMaxSize);

在内部，Java 使用 expectedmaxsize 计算容量，如下所示:

// Compute min capacity for expectedMaxSize given a load factor of 2/3
int minCapacity = (3 * expectedMaxSize)/2;

在进一步探索时，我发现用户应该传递一个很好的 expectedmaxsize 值，这样 IdentityHashMap 就不会随着添加更多元素而调整大小。

将此与 HashMap 进行比较，其 constructor 接受 initialCapacity :

 public HashMap(int initialCapacity)

...以及另一个接受 loadfactor 和 initialcapacity 的 constructor :

   public HashMap(int initialCapacity, float loadFactor)

…这里是 HashMap 没有关于 initialcapacity 的指导方针。

很明显，在 HashMap 和 IdentityHashMap 中管理内部数组大小的方式有所不同。我不明白为什么我们有这种差异？为什么 IdentityHashMap 不能提供与 HashMap 相同的构造函数？

最佳答案

正如 JB Nizet 所说，各个构造函数 API 的差异是由于设计人员对程序员最容易理解的“重新考虑”。 (旧方式不必要地暴露了内部设计的各个方面。)



这是一个错误的推论，事实上它是不正确的。如果仔细看 HashMap 和 IdentityHashMap 各自的代码，初始sizing和resize的代码是不一样的，但是逻辑基本是一样的。根据参数确定初始数组大小，然后在达到阈值时将数组大小加倍。 (这是我对代码的阅读……但您可以使用上面的链接自行检查。)
IdentityHashMap 的 javadoc 中没有包含这些内容的原因是不再需要它。在 HashMap 的情况下， Material 必须在那里，以便程序员知道构造函数参数的含义。简化构造函数参数意味着他们不需要解释这一点。因此(我假设)他们决定将实际的调整大小机制视为“实现细节”，而不是将其作为“契约(Contract)”的一部分。

关于java - IdentityHashMap 和 expectedmaxsize，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/15861227/