引言
由於近期忙著搬家,又偷懶了幾個禮拜!
其實我很早以前就想寫一篇關於HashMap的面試專題。對於JAVA求職者來說,HashMap可謂是集合類的重中之重,甚至你在複習的時候,其他集合類都不用看,專攻HashMap即可。
然而,鑑於網上大部分的關於HashMap的面試方向文章,煙哥看過後都不是太滿意。因此,斗膽嘗試也寫一篇關於HashMap的面試專題文章!
正文
(1)HashMap的實現原理?
此題可以組成如下連環炮來問
- 你看過HashMap原始碼嘛,知道原理嘛?
- 為什麼用陣列+連結串列?
- hash衝突你還知道哪些解決辦法?
- 我用LinkedList代替陣列結構可以麼?
- 既然是可以的,為什麼HashMap不用LinkedList,而選用陣列?
你看過HashMap原始碼嘛,知道原理嘛?
針對這個問題,嗯,當然是必須看過HashMap原始碼。至於原理,下面那張圖很清楚了:
HashMap採用Entry陣列來儲存key-value對,每一個鍵值對組成了一個Entry實體,Entry類實際上是一個單向的連結串列結構,它具有Next指標,可以連線下一個Entry實體。
只是在JDK1.8中,連結串列長度大於8的時候,連結串列會轉成紅黑樹!
為什麼用陣列+連結串列?
陣列是用來確定桶的位置,利用元素的key的hash值對陣列長度取模得到.
連結串列是用來解決hash衝突問題,當出現hash值一樣的情形,就在陣列上的對應位置形成一條連結串列。
ps
:這裡的hash值並不是指hashcode,而是將hashcode高低十六位異或過的。至於為什麼要這麼做,繼續往下看。
hash衝突你還知道哪些解決辦法?
比較出名的有四種(1)開放定址法(2)鏈地址法(3)再雜湊法(4)公共溢位區域法
ps:
大家有興趣擴充的,自己去搜一下就懂了,這個就不擴充了!
我用LinkedList代替陣列結構可以麼?
這裡我稍微說明一下,此題的意思是,原始碼中是這樣的
Entry[] table = new Entry[capacity];
ps:
Entry就是一個連結串列節點。
那我用下面這樣表示
List<Entry> table = new LinkedList<Entry>();
是否可行?
答案很明顯,必須是可以的。
既然是可以的,為什麼HashMap不用LinkedList,而選用陣列?
因為用陣列效率最高!
在HashMap中,定位桶的位置是利用元素的key的雜湊值對陣列長度取模得到。此時,我們已得到桶的位置。顯然陣列的查詢效率比LinkedList大。
那ArrayList,底層也是陣列,查詢也快啊,為啥不用ArrayList?
(煙哥寫到這裡的時候,不禁覺得自己真有想法,自己把自己問死了,還好我靈機一動想出了答案)
因為採用基本陣列結構,擴容機制可以自己定義,HashMap中陣列擴容剛好是2的次冪,在做取模運算的效率高。
而ArrayList的擴容機制是1.5倍擴容,那ArrayList為什麼是1.5倍擴容這就不在本文說明了。
(2)HashMap在什麼條件下擴容?
此題可以組成如下連環炮來問
- HashMap在什麼條件下擴容?
- 為什麼擴容是2的n次冪?
- 為什麼為什麼要先高16位異或低16位再取模運算?
HashMap在什麼條件下擴容?
如果bucket滿了(超過load factor*current capacity),就要resize。
load factor為0.75,為了最大程度避免雜湊衝突
current capacity為當前陣列大小。
為什麼擴容是2的次冪?
HashMap為了存取高效,要儘量較少碰撞,就是要儘量把資料分配均勻,每個連結串列長度大致相同,這個實現就在把資料存到哪個連結串列中的演算法; 這個演算法實際就是取模,hash%length。
但是,大家都知道這種運算不如位移運算快。
因此,原始碼中做了優化hash&(length-1)。
也就是說hash%length==hash&(length-1)
那為什麼是2的n次方呢?
因為2的n次方實際就是1後面n個0,2的n次方-1,實際就是n個1。
例如長度為8時候,3&(8-1)=3 2&(8-1)=2 ,不同位置上,不碰撞。
而長度為5的時候,3&(5-1)=0 2&(5-1)=0,都在0上,出現碰撞了。
所以,保證容積是2的n次方,是為了保證在做(length-1)的時候,每一位都能&1 ,也就是和1111……1111111進行與運算。
為什麼為什麼要先高16位異或低16位再取模運算?
我先曬一下,jdk1.8裡的hash方法。1.7的比較複雜,我們就不看了。
hashmap這麼做,只是為了降低hash衝突的機率。打個比方,
當我們的length為16的時候,雜湊碼(字串“abcabcabcabcabc”的key對應的雜湊碼)對(16-1)與操作,對於多個key生成的hashCode,只要雜湊碼的後4位為0,不論不論高位怎麼變化,最終的結果均為0。
如下圖所示
而加上高16位異或低16位的“擾動函式”後,結果如下
可以看到: 擾動函式優化前:1954974080 % 16 = 1954974080 & (16 - 1) = 0 擾動函式優化後:1955003654 % 16 = 1955003654 & (16 - 1) = 6 很顯然,減少了碰撞的機率。
(3)講講hashmap的get/put的過程?
此題可以組成如下連環炮來問
- 知道hashmap中put元素的過程是什麼樣麼?
- 知道hashmap中get元素的過程是什麼樣麼?
- 你還知道哪些hash演算法?
- 說說String中hashcode的實現?(此題很多大廠問過)
知道hashmap中put元素的過程是什麼樣麼?
對key的hashCode()做hash運算,計算index;
如果沒碰撞直接放到bucket裡;
如果碰撞了,以連結串列的形式存在buckets後;
如果碰撞導致連結串列過長(大於等於TREEIFY_THRESHOLD),就把連結串列轉換成紅黑樹(JDK1.8中的改動);
如果節點已經存在就替換old value(保證key的唯一性)
如果bucket滿了(超過load factor*current capacity),就要resize。
知道hashmap中get元素的過程是什麼樣麼?
對key的hashCode()做hash運算,計算index;
如果在bucket裡的第一個節點裡直接命中,則直接返回;
如果有衝突,則通過key.equals(k)去查詢對應的Entry;
- 若為樹,則在樹中通過key.equals(k)查詢,O(logn);
- 若為連結串列,則在連結串列中通過key.equals(k)查詢,O(n)。
你還知道哪些hash演算法?
先說一下hash演算法幹嘛的,Hash函式是指把一個大範圍對映到一個小範圍。把大範圍對映到一個小範圍的目的往往是為了節省空間,使得資料容易儲存。
比較出名的有MurmurHash、MD4、MD5等等
說說String中hashcode的實現?(此題頻率很高)
public int hashCode() {
int h = hash;
if (h == 0 && value.length > 0) {
char val[] = value;
for (int i = 0; i < value.length; i++) {
h = 31 * h + val[i];
}
hash = h;
}
return h;
}
String類中的hashCode計算方法還是比較簡單的,就是以31為權,每一位為字元的ASCII值進行運算,用自然溢位來等效取模。
雜湊計算公式可以計為s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
那為什麼以31為質數呢?
主要是因為31是一個奇質數,所以31*i=32*i-i=(i<<5)-i
,這種位移與減法結合的計算相比一般的運算快很多。
(4)為什麼hashmap的在連結串列元素數量超過8時改為紅黑樹?
此題可以組成如下連環炮來問
- 知道jdk1.8中hashmap改了啥麼?
- 為什麼在解決hash衝突的時候,不直接用紅黑樹?而選擇先用連結串列,再轉紅黑樹?
- 我不用紅黑樹,用二叉查詢樹可以麼?
- 那為什麼閥值是8呢?
- 當連結串列轉為紅黑樹後,什麼時候退化為連結串列?
知道jdk1.8中hashmap改了啥麼?
- 由陣列+連結串列的結構改為陣列+連結串列+紅黑樹。
- 優化了高位運算的hash演算法:h^(h>>>16)
- 擴容後,元素要麼是在原位置,要麼是在原位置再移動2次冪的位置,且連結串列順序不變。
最後一條是重點,因為最後一條的變動,hashmap在1.8中,不會在出現死迴圈問題。
為什麼在解決hash衝突的時候,不直接用紅黑樹?而選擇先用連結串列,再轉紅黑樹?
因為紅黑樹需要進行左旋,右旋,變色這些操作來保持平衡,而單連結串列不需要。
當元素小於8個當時候,此時做查詢操作,連結串列結構已經能保證查詢效能。當元素大於8個的時候,此時需要紅黑樹來加快查詢速度,但是新增節點的效率變慢了。
因此,如果一開始就用紅黑樹結構,元素太少,新增效率又比較慢,無疑這是浪費效能的。
我不用紅黑樹,用二叉查詢樹可以麼?
可以。但是二叉查詢樹在特殊情況下會變成一條線性結構(這就跟原來使用連結串列結構一樣了,造成很深的問題),遍歷查詢會非常慢。
那為什麼閥值是8呢?
不知道,等jdk作者來回答。
這道題,網上能找到的答案都是扯淡。
我隨便貼一個牛客網的答案,如下圖所示
看出bug沒?交點是6.64?交點分明是4,好麼。
log4=2,4/2=2。
jdk作者選擇8,一定經過了嚴格的運算,覺得在長度為8的時候,與其保證連結串列結構的查詢開銷,不如轉換為紅黑樹,改為維持其平衡開銷。
當連結串列轉為紅黑樹後,什麼時候退化為連結串列?
為6的時候退轉為連結串列。中間有個差值7可以防止連結串列和樹之間頻繁的轉換。假設一下,如果設計成連結串列個數超過8則連結串列轉換成樹結構,連結串列個數小於8則樹結構轉換成連結串列,如果一個HashMap不停的插入、刪除元素,連結串列個數在8左右徘徊,就會頻繁的發生樹轉連結串列、連結串列轉樹,效率會很低。
(5)HashMap的併發問題?
此題可以組成如下連環炮來問
- HashMap在併發程式設計環境下有什麼問題啊?
- 在jdk1.8中還有這些問題麼?
- 你一般怎麼解決這些問題的?
HashMap在併發程式設計環境下有什麼問題啊?
- (1)多執行緒擴容,引起的死迴圈問題
- (2)多執行緒put的時候可能導致元素丟失
- (3)put非null元素後get出來的卻是null
在jdk1.8中還有這些問題麼?
在jdk1.8中,死迴圈問題已經解決。其他兩個問題還是存在。
你一般怎麼解決這些問題的?
比如ConcurrentHashmap,Hashtable等執行緒安全等集合類。
(6)你一般用什麼作為HashMap的key?
此題可以組成如下連環炮來問
- 健可以為Null值麼?
- 你一般用什麼作為HashMap的key?
- 我用可變類當HashMap的key有什麼問題?
- 如果讓你實現一個自定義的class作為HashMap的key該如何實現?
健可以為Null值麼?
必須可以,key為null的時候,hash演算法最後的值以0來計算,也就是放在陣列的第一個位置。
你一般用什麼作為HashMap的key?
一般用Integer、String這種不可變類當HashMap當key,而且String最為常用。
- (1)因為字串是不可變的,所以在它建立的時候hashcode就被快取了,不需要重新計算。這就使得字串很適合作為Map中的鍵,字串的處理速度要快過其它的鍵物件。這就是HashMap中的鍵往往都使用字串。
- (2)因為獲取物件的時候要用到equals()和hashCode()方法,那麼鍵物件正確的重寫這兩個方法是非常重要的,這些類已經很規範的覆寫了hashCode()以及equals()方法。
我用可變類當HashMap的key有什麼問題?
hashcode可能發生改變,導致put進去的值,無法get出,如下所示
HashMap<List<String>, Object> changeMap = new HashMap<>();
List<String> list = new ArrayList<>();
list.add("hello");
Object objectValue = new Object();
changeMap.put(list, objectValue);
System.out.println(changeMap.get(list));
list.add("hello world");//hashcode發生了改變
System.out.println(changeMap.get(list));
輸出值如下
java.lang.Object@74a14482
null
如果讓你實現一個自定義的class作為HashMap的key該如何實現?
此題考察兩個知識點
- 重寫hashcode和equals方法注意什麼?
- 如何設計一個不變類
針對問題一,記住下面四個原則即可
(1)兩個物件相等,hashcode一定相等
(2)兩個物件不等,hashcode不一定不等
(3)hashcode相等,兩個物件不一定相等
(4)hashcode不等,兩個物件一定不等
針對問題二,記住如何寫一個不可變類
(1)類新增final修飾符,保證類不被繼承。
如果類可以被繼承會破壞類的不可變性機制,只要繼承類覆蓋父類的方法並且繼承類可以改變成員變數值,那麼一旦子類以父類的形式出現時,不能保證當前類是否可變。
(2)保證所有成員變數必須私有,並且加上final修飾
通過這種方式保證成員變數不可改變。但只做到這一步還不夠,因為如果是物件成員變數有可能再外部改變其值。所以第4點彌補這個不足。
(3)不提供改變成員變數的方法,包括setter
避免通過其他介面改變成員變數的值,破壞不可變特性。
(4)通過構造器初始化所有成員,進行深拷貝(deep copy)
如果構造器傳入的物件直接賦值給成員變數,還是可以通過對傳入物件的修改進而導致改變內部變數的值。例如:
public final class ImmutableDemo {
private final int[] myArray;
public ImmutableDemo(int[] array) {
this.myArray = array; // wrong
}
}
這種方式不能保證不可變性,myArray和array指向同一塊記憶體地址,使用者可以在ImmutableDemo之外通過修改array物件的值來改變myArray內部的值。
為了保證內部的值不被修改,可以採用深度copy來建立一個新記憶體儲存傳入的值。正確做法:
public final class MyImmutableDemo {
private final int[] myArray;
public MyImmutableDemo(int[] array) {
this.myArray = array.clone();
}
}
(5)在getter方法中,不要直接返回物件本身,而是克隆物件,並返回物件的拷貝
這種做法也是防止物件外洩,防止通過getter獲得內部可變成員物件後對成員變數直接操作,導致成員變數發生改變。
總結
這篇文章能概括大部分HashMap的面試題了,希望大家有所收穫!