HashMap是基於哈希表的Map接口的非同步實現。此實現提供所有可選的映射操作,並允許使用null值和null鍵。此類不保證映射的順序,特別是它不保證該順序恆久不變。
在java編程語言中,最基本的結構就是兩種,一個是數組,另外一個是模擬指針(引用),所有的數據結構都可以用這兩個基本結構來構造的,HashMap也不例外。HashMap實際上是一個“鏈表散列”的數據結構,即數組和鏈表的結合體。
從上圖中可以看出,HashMap底層就是一個數組結構,數組中的每一項又是一個鏈表。當新建一個HashMap的時候,就會初始化一個數組。
源碼如下:
/** *Thetable,resizedasnecessary.LengthMUSTAlwaysbeapoweroftwo. */ transientEntry[]table; staticclassEntry可以看出,Entry就是數組中的元素,每個Map.Entry其實就是一個key-value對,它持有一個指向下一個元素的引用,這就構成了鏈表。
從上面的源代碼中可以看出:當我們往HashMap中put元素的時候,先根據key的hashCode重新計算hash值,根據hash值得到這個元素在數組中的位置(即下標),如果數組該位置上已經存放有其他元素了,那麼在這個位置上的元素將以鏈表的形式存放,新加入的放在鏈頭,最先加入的放在鏈尾。如果數組該位置上沒有元素,就直接將該元素放到此數組中的該位置上。
addEntry(hash, key, value, i)方法根據計算出的hash值,將key-value對放在數組table的i索引處。addEntry是HashMap提供的一個包訪問權限的方法,代碼如下:
voidaddEntry(inthash,Kkey,Vvalue,intbucketIndex){ //獲取指定bucketIndex索引處的Entry Entry當系統決定存儲HashMap中的key-value對時,完全沒有考慮Entry中的value,僅僅只是根據key來計算並決定每個Entry的存儲位置。我們完全可以把Map集合中的value當成key的附屬,當系統決定了key的存儲位置之後,value隨之保存在那裡即可。
hash(int h)方法根據key的hashCode重新計算一次散列。此算法加入了高位計算,防止低位不變,高位變化時,造成的hash沖突。這篇文章末尾有hash方法詳解。
staticinthash(inth){ h^=(h>>>20)^(h>>>12); returnh^(h>>>7)^(h>>>4); }我們可以看到在HashMap中要找到某個元素,需要根據key的hash值來求得對應數組中的位置。如何計算這個位置就是hash算法。前面說過HashMap的數據結構是數組和鏈表的結合,所以我們當然希望這個HashMap裡面的元素位置盡量的分布均勻些,盡量使得每個位置上的元素數量只有一個,那麼當我們用hash算法求得這個位置的時候,馬上就可以知道對應位置的元素就是我們要的,而不用再去遍歷鏈表,這樣就大大優化了查詢的效率。
對於任意給定的對象,只要它的hashCode()返回值相同,那麼程序調用hash(int h)方法所計算得到的hash碼值總是相同的。我們首先想到的就是把hash值對數組長度取模運算,這樣一來,元素的分布相對來說是比較均勻的。但是,“模”運算的消耗還是比較大的,在HashMap中是這樣做的:調用indexFor(int h, int length)方法來計算該對象應該保存在table數組的哪個索引處。indexFor(int h, int length)方法的代碼如下:
staticintindexFor(inth,intlength){ returnh&(length-1); }這個方法非常巧妙,它通過h & (table.length -1)來得到該對象的保存位,而HashMap底層數組的長度總是2的n次方,這是HashMap在速度上的優化。在HashMap構造器中有如下代碼:
intcapacity=1; while(capacity
當length總是2的n次方時,h& (length-1)運算等價於對length取模,也就是h%length,但是&比%具有更高的效率。
這看上去很簡單,其實比較有玄機的,我們舉個例子來說明:
假設數組長度分別為15和16,優化後的hash碼分別為8和9,那麼&運算後的結果如下:
h & (table.length-1) hash table.length-1
8 & (15-1):0100&1110= 0100
9 & (15-1):0101&1110 =0100
-----------------------------------------------------------------------------------------------------------------------
8 & (16-1):0100&1111=0100
9 & (16-1):0101&1111=0101
從上面的例子中可以看出:當它們和15-1(1110)“與”的時候,產生了相同的結果,也就是說它們會定位到數組中的同一個位置上去,這就產生了碰撞,8和9會被放到數組中的同一個位置上形成鏈表,那麼查詢的時候就需要遍歷這個鏈表,得到8或者9,這樣就降低了查詢的效率。同時,我們也可以發現,當數組長度為15的時候,hash值會與15-1(1110)進行“與”,那麼最後一位永遠是0,而0001,0011,0101,1001,1011,0111,1101這幾個位置永遠都不能存放元素了,空間浪費相當大,更糟的是這種情況中,數組可以使用的位置比數組長度小了很多,這意味著進一步增加了碰撞的幾率,減慢了查詢的效率!而當數組長度為16時,即為2的n次方時,2n-1得到的二進制數的每個位上的值都為1,這使得在低位上&時,得到的和原hash的低位相同,加之hash(int h)方法對key的hashCode的進一步優化,加入了高位計算,就使得只有相同的hash值的兩個值才會被放到數組中的同一個位置上形成鏈表。
所以說,當數組長度為2的n次冪的時候,不同的key算得得index相同的幾率較小,那麼數據在數組上分布就比較均勻,也就是說碰撞的幾率小,相對的,查詢的時候就不用遍歷某個位置上的鏈表,這樣查詢效率也就較高了。
根據上面put方法的源代碼可以看出,當程序試圖將一個key-value對放入HashMap中時,程序首先根據該key的hashCode()返回值決定該Entry的存儲位置:如果兩個Entry的key的hashCode()返回值相同,那它們的存儲位置相同。如果這兩個Entry的key通過equals比較返回true,新添加Entry的value將覆蓋集合中原有Entry的value,但key不會覆蓋。如果這兩個Entry的key通過equals比較返回false,新添加的Entry將與集合中原有Entry形成Entry鏈,而且新添加的Entry位於Entry鏈的頭部——具體說明繼續看addEntry()方法的說明。
有了上面存儲時的hash算法作為基礎,理解起來這段代碼就很容易了。從上面的源代碼中可以看出:從HashMap中get元素時,首先計算key的hashCode,找到數組中對應位置的某一元素,然後通過key的equals方法在對應位置的鏈表中找到需要的元素。
3)歸納起來簡單地說,HashMap在底層將key-value當成一個整體進行處理,這個整體就是一個Entry對象。HashMap底層采用一個Entry[]數組來保存所有的key-value對,當需要存儲一個Entry對象時,會根據hash算法來決定其在數組中的存儲位置,在根據equals方法決定其在該數組位置上的鏈表中的存儲位置;當需要取出一個Entry時,也會根據hash算法找到其在數組中的存儲位置,再根據equals方法從該位置上的鏈表中取出該Entry。
當HashMap中的元素越來越多的時候,hash沖突的幾率也就越來越高,因為數組的長度是固定的。所以為了提高查詢的效率,就要對HashMap的數組進行擴容,數組擴容這個操作也會出現在ArrayList中,這是一個常用的操作,而在HashMap數組擴容之後,最消耗性能的點就出現了:原數組中的數據必須重新計算其在新數組中的位置,並放進去,這就是resize。
那麼HashMap什麼時候進行擴容呢?當HashMap中的元素個數超過數組大小*loadFactor時,就會進行數組擴容,loadFactor的默認值為0.75,這是一個折中的取值。也就是說,默認情況下,數組大小為16,那麼當HashMap中元素個數超過16*0.75=12的時候,就把數組的大小擴展為2*16=32,即擴大一倍,然後重新計算每個元素在數組中的位置,而這是一個非常消耗性能的操作,所以如果我們已經預知HashMap中元素的個數,那麼預設元素的個數能夠有效的提高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的最大容量:
Java代碼 threshold=(int)(capacity*loadFactor);結合負載因子的定義公式可知,threshold就是在此loadFactor和capacity對應下允許的最大元素數目,超過這個數目就重新resize,以降低實際的負載因子。默認的的負載因子0.75是對空間和時間效率的一個平衡選擇。當容量超出此最大容量時,resize後的HashMap容量是容量的兩倍:
Java代碼 if(size++>=threshold) resize(2*table.length);我們知道java.util.HashMap不是線程安全的,因此如果在使用迭代器的過程中有其他線程修改了map,那麼將拋出ConcurrentModificationException,這就是所謂fail-fast策略。
這一策略在源碼中的實現是通過modCount域,modCount顧名思義就是修改次數,對HashMap內容的修改都將增加這個值,那麼在迭代器初始化過程中會將這個值賦給迭代器的expectedModCount。
Java代碼 HashIterator(){ expectedModCount=modCount; if(size>0){//advancetofirstentry Entry[]t=table; while(index
注意到modCount聲明為volatile,保證線程之間修改的可見性。
Java代碼 finalEntry在HashMap的API中指出:
由所有HashMap類的“collection視圖方法”所返回的迭代器都是快速失敗的:在迭代器創建之後,如果從結構上對映射進行修改,除非通過迭代器本身的remove方法,其他任何時間任何方式的修改,迭代器都將拋出ConcurrentModificationException。因此,面對並發的修改,迭代器很快就會完全失敗,而不冒在將來不確定的時間發生任意不確定行為的風險。
注意,迭代器的快速失敗行為不能得到保證,一般來說,存在非同步的並發修改時,不可能作出任何堅決的保證。快速失敗迭代器盡最大努力拋出ConcurrentModificationException。因此,編寫依賴於此異常的程序的做法是錯誤的,正確做法是:迭代器的快速失敗行為應該僅用於檢測程序錯誤。