溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Hashtable與HashMap的區(qū)別有哪些

發(fā)布時間:2020-11-18 15:42:43 來源:億速云 閱讀:159 作者:Leah 欄目:編程語言

今天就跟大家聊聊有關(guān)Hashtable與HashMap的區(qū)別有哪些,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。

HashMap和Hashtable的詳細比較

前言:

可以直接根據(jù)hashcode值判斷兩個對象是否相等嗎?肯定是不可以的,因為不同的對象可能會生成相同的hashcode值。雖然不能根據(jù)hashcode值判斷兩個對象是否相等,但是可以直接根據(jù)hashcode值判斷兩個對象不等,如果兩個對象的hashcode值不等,則必定是兩個不同的對象。如果要判斷兩個對象是否真正相等,必須通過equals方法。

也就是說對于兩個對象,如果調(diào)用equals方法得到的結(jié)果為true,則兩個對象的hashcode值必定相等;如果equals方法得到的結(jié)果為false,則兩個對象的hashcode值不一定不同;如果兩個對象的hashcode值不等,則equals方法得到的結(jié)果必定為false;如果兩個對象的hashcode值相等,則equals方法得到的結(jié)果未知。

HashMap和Hashtable不保證map的順序,也不保證順序不會隨著時間不變。

HashMap實例有兩個參數(shù)影響性能:初始capacity和load factor。capacity是hashtable中桶的數(shù)量,初始capacity就是hashtable創(chuàng)建時的capacity。load factor影響hashtable多滿時允許自動增加capacity。當hashtable中entry的數(shù)量超過load factor和當前capacity的乘積,hashtable會重新哈希(意味著,內(nèi)部數(shù)據(jù)結(jié)構(gòu)重建)因此hashtable大約擁有桶數(shù)量的兩倍。

作為通用規(guī)則,默認load factor(0.75)在時間和空間消耗上提供了好的權(quán)衡。值越大,空間開銷越小,但是遍歷成本增加(表現(xiàn)在大多數(shù)操作,包括get和put)。當設(shè)置初始capacity時,為了最小化重新hash的操作次數(shù),應(yīng)該考慮map的entry數(shù)量和load factor。如果初始容量大于最大entry數(shù)量除以load factor,重新hash操作將不會發(fā)生。然而,設(shè)置初始capacity太大會浪費空間。

如果許多mapping存儲在HashMap實例中,創(chuàng)建時使用足夠大的capacity將允許mapping存儲得更有效率,因為不會隨著table的數(shù)量增大重新hash。注意使用許多相同hashCode()的key肯定會降低任意hashtable的性能。

二.相同點

DEFAULT_LOAD_FACTOR

0.75

TREEIFY_THRESHOLD

8

UNTREEIFY_THRESHOLD

6

MIN_TREEIFY_CAPACITY

否則resize()

64

size

mapping數(shù)量

threhold

capacity*load factor

三.不同點


     HashMap

Hashtable

線程安全

不安全

安全

允許null的鍵和值

允許

不允許

實現(xiàn)和繼承

實現(xiàn)Map

實現(xiàn)Map,繼承Dictionary

遍歷方式

Iterator

Iterator和Enumeration

計算哈希值

(key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16)

(key.hashCode() & 0x7FFFFFFF)

計算數(shù)組下標

(length - 1) & hash

hash % length

DEFAULT_INITIAL_CAPACITY

16

11

容量增加方式

old*2

長度始終為2的冪

old*2+1

構(gòu)造函數(shù)

threshold=tableSizeFor(initialCapacity)

threhold=initialCapacity*load factor

resize

從0-cap

鏈表順序不變

從cap-0

鏈表順序相反

 計算數(shù)組下標:當length總是2的n次方時,h&(length-1)運算等價于對length取模,也就是h%length,但是&比%具有更高的效率。

容量增加方式:當數(shù)組長度為2的n次冪的時候,不同的key算得的index相同的幾率較小,那么數(shù)據(jù)在數(shù)組上分布就比較均勻,也就是說碰撞的幾率小。相對的,查詢的時候就不用遍歷某個位置上的鏈表,這樣查詢效率也就較高了。導致resize()不同HashMap直接使用之前的數(shù)組下表,而Hashtable需要重新計算。

看完上述內(nèi)容,你們對Hashtable與HashMap的區(qū)別有哪些有進一步的了解嗎?如果還想了解更多知識或者相關(guān)內(nèi)容,請關(guān)注億速云行業(yè)資訊頻道,感謝大家的支持。

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI