IdentityHashMap和expectedmaxsize

Question

我一直在瀏覽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的有沒有關於初始容量的指導原則。

顯然，在HashMap和IdentityHashMap中內部數組的大小管理方式存在差異。我不明白爲什麼我們有這種差異？爲什麼Identityhashmap不能提供與Hashmap相同的構造函數？

Answer 1

由於JB Nizet說，在各自的構造函數的API不同的是，由於「第二次思想」通過對什麼是設計師程序員最容易理解。 （舊的方式不必要地暴露內部設計的方面）

很明顯，在HashMap和IdentityHashMap中內部數組的大小管理方式有所不同。

這是一個不正確的推論，事實上並非如此。如果仔細查看HashMap和IdentityHashMap的各自代碼，初始大小調整和調整大小代碼是不同的，但邏輯基本相同。根據參數確定初始數組大小，然後在達到閾值時數組的大小加倍。 （這是我對代碼的閱讀......但你可以使用上面的鏈接自己檢查它。）

將東西遺漏在javadoc中的原因是IdentityHashMap不再需要。在HashMap的情況下，材料必須在那裏，以便程序員知道構造參數意味着什麼。簡化構造參數意味着他們沒有需要來解釋這一點。所以（我認爲）他們決定把實際的調整機制看作是「實施細節」，而不是「合同」的一部分。

Answer 2

IdentityHashMap的日期從JDK1.4開始，而HashMap的日期從JDK1.2開始。與此同時，收集框架的作者可能意識到，通過預期的最大規模比通過容量更加自然，頻繁和開發人員友好。

但傳送容量或最大尺寸基本相同的事情：

max size = capacity * load factor.