5. HashMap 的性能參數：
HashMap 包含如下幾個構造器：
HashMap() ：構建一個初始容量爲 16 ，負載因子爲 0.75 的 HashMap 。
HashMap(int initialCapacity) ：構建一個初始容量爲 initialCapacity ，負載因子爲 0.75 的 HashMap 。
HashMap(int initialCapacity, float loadFactor) ：以指定初始容量、指定的負載因子創建一個 HashMap 。
HashMap 的基礎構造器 HashMap(int initialCapacity, float loadFactor) 帶有兩個參數，它們是初始容量 initialCapacity 和加載因子 loadFactor 。
initialCapacity ： HashMap 的最大容量，即爲底層數組的長度。
loadFactor ：負載因子 loadFactor 定義爲：散列表的實際元素數目 (n)/ 散列表的容量 (m) 。
負載因子衡量的是一個散列表的空間的使用程度，負載因子越大表示散列表的裝填程度越高，反之愈小。對於使用鏈表法的散列表來說，查找一個元素的平均時間是 O(1+a) ，因此如果負載因子越大，對空間的利用更充分，然而後果是查找效率的降低；如果負載因子太小，那麼散列表的數據將過於稀疏，對空間造成嚴重浪費。
HashMap 的實現中，通過 threshold 字段來判斷 HashMap 的最大容量：
threshold = (int)(capacity * loadFactor);
結合負載因子的定義公式可知， threshold 就是在此 loadFactor 和 capacity 對應下允許的最大元素數目，超過這個數目就重新 resize ，以降低實際的負載因子。默認的的負載因子 0.75 是對空間和時間效率的一個平衡選擇。當容量超出此最大容量時， resize 後的 HashMap 容量是容量的兩倍：
if (size++ >= threshold)
resize(2 * table.length);
6. Fail-Fast 機制：
我們知道 java.util.HashMap 不是線程安全的，因此如果在使用迭代器的過程中有其他線程修改了 map ，那麼將拋出 ConcurrentModificationException ，這就是所謂 fail-fast 策略。
這一策略在源碼中的實現是通過 modCount 域， modCount 顧名思義就是修改次數，對 HashMap 內容的修改都將增加這個值，那麼在迭代器初始化過程中會將這個值賦給迭代器的 expectedModCount 。
HashIterator() {
expectedModCount = modCount;
if (size > 0) { // advance to first entry
Entry[] t = table;
while (index < t.length && (next = t[index++]) == null)
;
}
}
在迭代過程中，判斷 modCount 跟 expectedModCount 是否相等，如果不相等就表示已經有其他線程修改了 Map：
注意到 modCount 聲明爲 volatile ，保證線程之間修改的可見性。
final Entry<K,V> nextEntry() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
在 HashMap 的 API 中指出：
由所有 HashMap 類的 “collection 視圖方法 ” 所返回的迭代器都是快速失敗的：在迭代器創建之後，如果從結構上對映射進行修改，除非通過迭代器本身的 remove 方法，其他任何時間任何方式的修改，迭代器都將拋出 ConcurrentModificationException 。因此，面對併發的修改，迭代器很快就會完全失敗，而不冒在將來不確定的時間發生任意不確定行爲的風險。
注意，迭代器的快速失敗行爲不能得到保證，一般來說，存在非同步的併發修改時，不可能作出任何堅決的保證。快速失敗迭代器盡最大努力拋出 ConcurrentModificationException 。因此，編寫依賴於此異常的程序的做法是錯誤的，正確做法是：迭代器的快速失敗行爲應該僅用於檢測程序錯誤。
參考資料：
JDK API HashMap HashMap 源代碼 深入理解HashMap
