我一直在浏览IdentityHashMaps的文档。 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)
和另一个接受loadfactor和initialcapacity的构造函数：
public HashMap(int initialCapacity, float loadFactor)
这里是hashmap，没有关于initialcapacity的指南。
很明显，在HashMap和IdentityHashMap中管理内部数组的大小有所不同。我不明白为什么我们有这个区别？为什么Identityhashmap不能提供与Hashmap相同的构造函数？
答案 0 :(得分：1)
IdentityHashMap的日期来自JDK1.4，而HashMap的日期来自JDK1.2。与此同时，集合框架的作者可能意识到，传递预期的最大大小比传递容量更自然，更频繁，更适合开发人员。
但是传递容量或最大尺寸基本上是一样的：
max size = capacity * load factor.
答案 1 :(得分：1)
正如JB Nizet所说，各个构造函数API的不同之处在于设计人员对于程序员最容易理解的内容的“第二个想法”。 （旧的方式不必要地暴露了内部设计的各个方面。）
很明显，在HashMap和IdentityHashMap中管理内部数组的大小有所不同。
这是一个不正确的推理，事实上并非如此。如果仔细查看HashMap和IdentityHashMap的相应代码，初始大小调整和调整大小代码会有所不同，但逻辑基本相同。基于参数确定初始阵列大小，然后当达到阈值时阵列的大小加倍。 （这是我对代码的阅读......但您可以使用上面的链接自行检查。）
IdentityHashMap的javadoc之外的东西是不再需要它的原因。在HashMap的情况下，材料必须在那里，以便程序员知道构造函数参数的含义。简化构造函数参数意味着他们没有需要来解释这一点。因此（我推测）他们决定将实际的调整大小机制视为“实施细节”，而不是将其作为“合同”的一部分。