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

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
