面試技巧之HashMap VS HashTable

HashMap和HashTable有什么不同?在面試和被面試的過程中,我問過也被問過這個問題,也見過了不少回答,今天決定寫一寫自己心目中的理想答案。

JDK每一版本都在改進。本文討論的HashMap和HashTable基于JDK 1.7.0_67。

1. 時間

HashTable產(chǎn)生于JDK 1.1,而HashMap產(chǎn)生于JDK 1.2。從時間的維度上來看,HashMap要比HashTable出現(xiàn)得晚一些。

2. 作者

以下是HashTable的作者:

以下代碼及注釋來自java.util.HashTable*@authorArthur van Hoff*@authorJosh Bloch*@authorNeal Gafter

以下是HashMap的作者:

以下代碼及注釋來自java.util.HashMap*@authorDoug Lea*@authorJosh Bloch*@authorArthur van Hoff*@authorNeal Gafter

可以看到HashMap的作者多了大神Doug Lea。不了解Doug Lea的,可以百度搜一下。

3. 對外的接口(API)

HashMap和HashTable都是基于哈希表來實現(xiàn)鍵值映射的工具類。討論他們的不同,我們首先來看一下他們暴露在外的API有什么不同。

13.1 Public Method

下面兩張圖,我畫出了HashMap和HashTable的類繼承體系,并列出了這兩個類的可供外部調(diào)用的公開方法。

從圖中可以看出,兩個類的繼承體系有些不同。雖然都實現(xiàn)了Map、Cloneable、Serializable三個接口。但是HashMap繼承自抽象類AbstractMap,而HashTable繼承自抽象類Dictionary。

其中Dictionary類是一個已經(jīng)被廢棄的類,這一點我們可以從它代碼的注釋中看到:

以下代碼及注釋來自java.util.Dictionary* NOTE:Thisclassis obsolete.Newimplementations should* implement the Mapinterface, rather than extendingthisclass.

同時我們看到HashTable比HashMap多了兩個公開方法。一個是elements,這來自于抽象類Dictionary,鑒于該類已經(jīng)廢棄,所以這個方法也就沒什么用處了。另一個多出來的方法是contains,這個多出來的方法也沒什么用,因為它跟containsValue方法功能是一樣的。代碼為證:

以下代碼及注釋來自java.util.HashTablepublic synchronized booleancontains(Objectvalue){if(value==null) {thrownewNullPointerException(); } Entry tab[] = table;for(inti = tab.length ; i-- >0;) {for(Entry e = tab[i] ; e !=null; e = e.next) {if(e.value.equals(value)) {returntrue; } } }returnfalse;}publicbooleancontainsValue(Objectvalue){returncontains(value);}

所以從公開的方法上來看,這兩個類提供的,是一樣的功能。都提供鍵值映射的服務(wù),可以增、刪、查、改鍵值對,可以對建、值、鍵值對提供遍歷視圖。支持淺拷貝,支持序列化。

13.2 Null Key & Null Value

HashMap是支持null鍵和null值的,而HashTable在遇到null時,會拋出NullPointerException異常。這并不是因為HashTable有什么特殊的實現(xiàn)層面的原因?qū)е虏荒苤С謓ull鍵和null值,這僅僅是因為HashMap在實現(xiàn)時對null做了特殊處理,將null的hashCode值定為了0,從而將其存放在哈希表的第0個bucket中。我們一put方法為例,看一看代碼的細節(jié):

以下代碼及注釋來自java.util.HashTable

public synchronized Vput(Kkey, V value) { // 如果value為null,拋出NullPointerExceptionif(value == null) {thrownewNullPointerException(); } // 如果key為null,在調(diào)用key.hashCode()時拋出NullPointerException // ...}

以下代碼及注釋來自java.util.HasMap

publicV put(K key, V value) {if(table == EMPTY_TABLE) { inflateTable(threshold); } // 當(dāng)key為null時,調(diào)用putForNullKey特殊處理if(key ==null)returnputForNullKey(value); // ...}privateV putForNullKey(V value) { // key為null時,放到table[0]也就是第0個bucket中for(Entry e = table[0]; e !=null; e = e.next) {if(e.key ==null) { V oldValue = e.value; e.value = value; e.recordAccess(this);returnoldValue; } } modCount++; addEntry(0,null, value,0);returnnull;}

4.實現(xiàn)原理

本節(jié)討論HashMap和HashTable在數(shù)據(jù)結(jié)構(gòu)和算法層面,有什么不同。

14.1 數(shù)據(jù)結(jié)構(gòu)

HashMap和HashTable都使用哈希表來存儲鍵值對。在數(shù)據(jù)結(jié)構(gòu)上是基本相同的,都創(chuàng)建了一個繼承自Map.Entry的私有的內(nèi)部類Entry,每一個Entry對象表示存儲在哈希表中的一個鍵值對。

Entry對象唯一表示一個鍵值對,有四個屬性:

-K key 鍵對象

-V value 值對象

-int hash 鍵對象的hash值

-Entryentry 指向鏈表中下一個Entry對象,可為null,表示當(dāng)前Entry對象在鏈表尾部

可以說,有多少個鍵值對,就有多少個Entry對象,那么在HashMap和HashTable中是怎么存儲這些Entry對象,以方便我們快速查找和修改的呢?請看下圖。

上圖畫出的是一個桶數(shù)量為8,存有5個鍵值對的HashMap/HashTable的內(nèi)存布局情況。可以看到HashMap/HashTable內(nèi)部創(chuàng)建有一個Entry類型的引用數(shù)組,用來表示哈希表,數(shù)組的長度,即是哈希桶的數(shù)量。而數(shù)組的每一個元素都是一個Entry引用,從Entry對象的屬性里,也可以看出其是鏈表的節(jié)點,每一個Entry對象內(nèi)部又含有另一個Entry對象的引用。

這樣就可以得出結(jié)論,HashMap/HashTable內(nèi)部用Entry數(shù)組實現(xiàn)哈希表,而對于映射到同一個哈希桶(數(shù)組的同一個位置)的鍵值對,使用Entry鏈表來存儲(解決hash沖突)。

以下代碼及注釋來自java.util.HashTable/*** The hashtabledata.*/private transient Entry[]table;以下代碼及注釋來自java.util.HashMap/*** Thetable, resized as necessary. Length MUST Always be a power of two.*/transient Entry[]table= (Entry[]) EMPTY_TABLE;

從代碼可以看到,對于哈希桶的內(nèi)部表示,兩個類的實現(xiàn)是一致的。

14.2 算法

上一小節(jié)已經(jīng)說了用來表示哈希表的內(nèi)部數(shù)據(jù)結(jié)構(gòu)。HashMap/HashTable還需要有算法來將給定的鍵key,映射到確定的hash桶(數(shù)組位置)。需要有算法在哈希桶內(nèi)的鍵值對多到一定程度時,擴充哈希表的大小(數(shù)組的大小)。本小節(jié)比較這兩個類在算法層面有哪些不同。

初始容量大小和每次擴充容量大小的不同。先看代碼:

以下代碼及注釋來自java.util.HashTable// 哈希表默認初始大小為1public Hashtable() { this(11,0.5f);}protectedvoid rehash() {intoldCapacity = table.length;Entry[] oldMap = table; // 每次擴容為原來的n+1intnewCapacity = (oldCapacity <<1) +1; // ...}以下代碼及注釋來自java.util.HashMap// 哈希表默認初始大小為2^4=6staticfinalintDEFAULT_INITIAL_CAPACITY =1<<4; // aka 6void addEntry(inthash, K key, Vvalue,intbucketIndex) { // 每次擴充為原來的nif((size>= threshold) && (null!= table[bucketIndex])) { resize(2 * table.length);}

可以看到HashTable默認的初始大小為11,之后每次擴充為原來的2n+1。HashMap默認的初始化大小為16,之后每次擴充為原來的2倍。還有我沒列出代碼的一點,就是如果在創(chuàng)建時給定了初始化大小,那么HashTable會直接使用你給定的大小,而HashMap會將其擴充為2的冪次方大小。

也就是說HashTable會盡量使用素數(shù)、奇數(shù)。而HashMap則總是使用2的冪作為哈希表的大小。我們知道當(dāng)哈希表的大小為素數(shù)時,簡單的取模哈希的結(jié)果會更加均勻,所以單從這一點上看,HashTable的哈希表大小選擇,似乎更高明些。

但另一方面我們又知道,在取模計算時,如果模數(shù)是2的冪,那么我們可以直接使用位運算來得到結(jié)果,效率要大大高于做除法。所以從hash計算的效率上,又是HashMap更勝一籌。

所以,事實就是HashMap為了加快hash的速度,將哈希表的大小固定為了2的冪。當(dāng)然這引入了哈希分布不均勻的問題,所以HashMap為解決這問題,又對hash算法做了一些改動。具體我們來看看,在獲取了key對象的hashCode之后,HashTable和HashMap分別是怎樣將他們hash到確定的哈希桶(Entry數(shù)組位置)中的。

以下代碼及注釋來自java.util.HashTable// hash 不能超過Integer.MAX_VALUE 所以要取其最小的31個bitint hash = hash(key);int index = (hash &0x7FFFFFFF)%tab.length;// 直接計算key.hashCode()private int hash(Object k) { // hashSeed will be zeroifalternative hashingisdisabled.returnhashSeed ^ k.hashCode();}以下代碼及注釋來自java.util.HashMapint hash = hash(key);int i = indexFor(hash, table.length);// 在計算了key.hashCode()之后,做了一些位運算來減少哈希沖突final int hash(Object k) { int h = hashSeed;if(0!= h && k instanceof String) {returnsun.misc.Hashing.stringHash32((String) k); } h ^= k.hashCode(); // This function ensures that hashCodes that differ only by //constantmultiplesateach bitpositionhave a bounded // number of collisions (approximately8atdefaultloadfactor). h ^= (h >>>20) ^ (h >>>12);returnh ^ (h >>>7) ^ (h >>>4);}// 取模不再需要做除法static int indexFor(int h, intlength) { // assert Integer.bitCount(length) ==1:"length must be a non-zero power of 2";returnh & (length-1);}

正如我們所言,HashMap由于使用了2的冪次方,所以在取模運算時不需要做除法,只需要位的與運算就可以了。但是由于引入的hash沖突加劇問題,HashMap在調(diào)用了對象的hashCode方法之后,又做了一些位運算在打散數(shù)據(jù)。關(guān)于這些位計算為什么可以打散數(shù)據(jù)的問題,本文不再展開了。

如果你有細心讀代碼,還可以發(fā)現(xiàn)一點,就是HashMap和HashTable在計算hash時都用到了一個叫hashSeed的變量。這是因為映射到同一個hash桶內(nèi)的Entry對象,是以鏈表的形式存在的,而鏈表的查詢效率比較低,所以HashMap/HashTable的效率對哈希沖突非常敏感,所以可以額外開啟一個可選hash(hashSeed),從而減少哈希沖突。

因為這是兩個類相同的一點,所以本文不再展開了。事實上,這個優(yōu)化在JDK 1.8中已經(jīng)去掉了,因為JDK 1.8中,映射到同一個哈希桶(數(shù)組位置)的Entry對象,使用了紅黑樹來存儲,從而大大加速了其查找效率。

5. 線程安全

我們說HashTable是同步的,HashMap不是,也就是說HashTable在多線程使用的情況下,不需要做額外的同步,而HashMap則不行。那么HashTable是怎么做到的呢?

以下代碼及注釋來自java.util.HashTablepublicsynchronizedVget(Objectkey) { Entry tab[] = table;inthash = hash(key);intindex = (hash &0x7FFFFFFF) % tab.length;for(Entry e = tab[index] ; e !=null; e = e.next) {if((e.hash == hash) && e.key.equals(key)) {returne.value; } }returnnull;}publicSet keySet() {if(keySet ==null) keySet = Collections.synchronizedSet(newKeySet(),this);returnkeySet;}

可以看到,也比較簡單,就是公開的方法比如get都使用了synchronized描述符。而遍歷視圖比如keySet都使用了Collections.synchronizedXXX進行了同步包裝。

6. 代碼風(fēng)格

從我的品位來看,HashMap的代碼要比HashTable整潔很多。下面這段HashTable的代碼,我就覺著有點混亂,不太能接受這種代碼復(fù)用的方式。

以下代碼及注釋來自java.util.HashTable/*** A hashtable enumerator class. This class implements both the* Enumeration and Iterator interfaces, but individual instances* can be created with the Iterator methods disabled. This is necessary* to avoid unintentionally increasing the capabilities granted a user* by passing an Enumeration.*/privateclassEnumeratorimplementsEnumeration,Iterator{ Entry[] table = Hashtable.this.table;intindex= table.length; Entry entry =null; Entry lastReturned =null;inttype;/** * Indicates whether this Enumerator is serving as an Iterator * or an Enumeration. (true -> Iterator). */booleaniterator;/** * The modCount value that the iterator believes that the backing * Hashtable should have. If this expectation is violated, the iterator * has detected concurrent modification. */protectedintexpectedModCount = modCount; Enumerator(inttype,booleaniterator) {this.type = type;this.iterator = iterator; }//...}

HashTable已經(jīng)被淘汰了,不要在代碼中再使用它。

以下描述來自于HashTable的類注釋:

If a thread-safe implementation is not needed,

it is recommended to use HashMap in place of Hashtable.

If a thread-safe highly-concurrent implementation is desired,

then it is recommended to use java.util.concurrent.ConcurrentHashMap in place of Hashtable.

簡單來說就是,如果你不需要線程安全,那么使用HashMap,如果需要線程安全,那么使用ConcurrentHashMap。HashTable已經(jīng)被淘汰了,不要在新的代碼中再使用它。

7. 持續(xù)優(yōu)化

雖然HashMap和HashTable的公開接口應(yīng)該不會改變,或者說改變不頻繁。但每一版本的JDK,都會對HashMap和HashTable的內(nèi)部實現(xiàn)做優(yōu)化,比如上文曾提到的JDK 1.8的紅黑樹優(yōu)化。所以,盡可能的使用新版本的JDK吧,除了那些炫酷的新功能,普通的API也會有性能上有提升。

為什么HashTable已經(jīng)淘汰了,還要優(yōu)化它?因為有老的代碼還在使用它,所以優(yōu)化了它之后,這些老的代碼也能獲得性能提升。

想要了解更多面試技巧,避坑指南,知識體系的,可以加我的交流群650385180,群里有眾多前人面試經(jīng)驗的總結(jié),我也會在群里面分享我的一些工作經(jīng)驗與心得,希望可以幫助到大家。

注:喜歡我文章的朋友可以點贊關(guān)注一下,實時接受最新資訊。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,572評論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,071評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,409評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,569評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 71,360評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 54,895評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,979評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,123評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,643評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 40,559評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,742評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,250評論 5 356
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 43,981評論 3 346
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,363評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,622評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,354評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 47,707評論 2 370

推薦閱讀更多精彩內(nèi)容