3

我一直在浏览IdentityHashMap. 该类有一个构造函数，它采用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, 其构造函数接受initialCapacity：

 public HashMap(int initialCapacity)

…以及另一个接受and的构造函数：loadfactorinitialcapacity

   public HashMap(int initialCapacity, float loadFactor)

......这里HashMap没有关于initialcapacity.

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

4

2 回答 2

2

IdentityHashMap从 JDK 1.4 开始，而HashMap从 JDK 1.2 开始。与此同时，Java Collections Framework的作者可能意识到传递预期的最大大小比传递容量更自然、更频繁且对开发人员友好得多。

但是传递容量或最大大小基本上是一样的：

max size = capacity * load factor.
于 2013-04-07T10:45:20.430 回答
2

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

很明显，HashMap 和 IdentityHashMap 管理内部数组大小的方式有所不同。

这是一个错误的推论，事实上它是不正确的。如果你仔细看各自的代码，HashMap初始IdentityHashMap大小和调整大小的代码是不同的，但逻辑基本相同。根据参数确定初始数组大小，然后在达到阈值时将数组大小加倍。（这是我对代码的阅读......但您可以使用上面的链接自己检查。）

javadoc 中没有包含这些内容的原因IdentityHashMap是不再需要它。在这种HashMap情况下，材料必须在那里，以便程序员知道构造函数参数的含义。简化构造函数参数意味着他们不需要解释这一点。所以（我想）他们决定将实际的大小调整机制视为“实施细节”，而不是使其成为“合同”的一部分。

于 2013-04-07T11:02:56.473 回答