java中hashmap容量的初始化

HashMap使用HashMap(int initialCapacity)對(duì)集合進(jìn)行初始化。

在默認(rèn)的情況下,HashMap的容量是16。但是如果用戶通過(guò)構(gòu)造函數(shù)指定了一個(gè)數(shù)字作為容量,那么Hash會(huì)選擇大于該數(shù)字的第一個(gè)2的冪作為容量。比如如果指定了3,則容量是4;如果指定了7,則容量是8;如果指定了9,則容量是16。

為什么要設(shè)置HashMap的初始化容量

在《阿里巴巴Java開(kāi)發(fā)手冊(cè)》中,有一條開(kāi)發(fā)建議是建議我們?cè)O(shè)置HashMap的初始化容量。

下面我們通過(guò)具體的代碼來(lái)了解下為什么會(huì)這么建議。

我們先來(lái)寫一段代碼在JDK1.7的環(huán)境下運(yùn)行,來(lái)分別測(cè)試下,在不指定初始化容量和指定初始化容量的情況下性能情況的不同。

public static void main(String[] args) {
int aHundredMillion = 10000000;

// 未初始化容量
Map<Integer, Integer> map = new HashMap<>();
long s1 = System.currentTimeMillis();
for (int i = 0; i < aHundredMillion; i++) {
map.put(i, i);
}
long s2 = System.currentTimeMillis();
System.out.println("未初始化容量,耗時(shí): " + (s2 - s1)); // 14322

// 初始化容量為50000000
Map<Integer, Integer> map1 = new HashMap<>(aHundredMillion / 2);
long s3 = System.currentTimeMillis();
for (int i = 0; i < aHundredMillion; i++) {
map1.put(i, i);
}
long s4 = System.currentTimeMillis();
System.out.println("初始化容量5000000,耗時(shí): " + (s4 - s3)); // 11819

// 初始化容量為100000000
Map<Integer, Integer> map2 = new HashMap<>(aHundredMillion);
long s5 = System.currentTimeMillis();
for (int i = 0; i < aHundredMillion; i++) {
map2.put(i, i);
}
long s6 = System.currentTimeMillis();
System.out.println("初始化容量為10000000,耗時(shí): " + (s6 - s5)); // 7978
}
從以上的代碼不難理解,我們創(chuàng)建了3個(gè)HashMap,分別使用默認(rèn)的容量(16)、使用元素個(gè)數(shù)的一半(5千萬(wàn))作為初始容量和使用元素個(gè)數(shù)(一億)作為初始容量進(jìn)行初始化,然后分別向其中put一億個(gè)KV。

從上面的打印結(jié)果中可以得到一個(gè)初步的結(jié)論:在已知HashMap中將要存放的KV個(gè)數(shù)的時(shí)候,設(shè)置一個(gè)合理的初始化容量可以有效地提高性能。下面我們來(lái)簡(jiǎn)單分析一下原因。

我們知道,HashMap是有擴(kuò)容機(jī)制的。所謂的擴(kuò)容機(jī)制,指的是當(dāng)達(dá)到擴(kuò)容條件的時(shí)候,HashMap就會(huì)自動(dòng)進(jìn)行擴(kuò)容。而HashMap的擴(kuò)容條件就是當(dāng)HashMap中的元素個(gè)數(shù)(Size)超過(guò)臨界值(Threshold)的情況下就會(huì)自動(dòng)擴(kuò)容。

threshold = loadFactor * capacity
在元素個(gè)數(shù)超過(guò)臨界值的情況下,隨著元素的不斷增加,HashMap就會(huì)發(fā)生擴(kuò)容,而HashMap中的擴(kuò)容機(jī)制決定了每次擴(kuò)容都需要重建hash表,這一操作需要消耗大量資源,是非常影響性能的。因此,如果我們沒(méi)有設(shè)置初始的容量大小,HashMap就可能會(huì)不斷發(fā)生擴(kuò)容,也就使得程序的性能降低了。

另外,在上面的代碼中我們會(huì)發(fā)現(xiàn),同樣是設(shè)置了初始化容量,設(shè)置的數(shù)值不同也會(huì)影響性能,那么當(dāng)我們已知HashMap中即將存放的KV個(gè)數(shù)的時(shí)候,容量的設(shè)置就成了一個(gè)問(wèn)題。

HashMap中容量的初始化

開(kāi)頭提到,在默認(rèn)的情況下,當(dāng)我們?cè)O(shè)置HashMap的初始化容量時(shí),實(shí)際上HashMap會(huì)采用第一個(gè)大于該數(shù)值的2的冪作為初始化容量。

Map<String, String> map = new HashMap<>(1);
map.put("huangq", "yanggb");

Class<?> mapType = map.getClass();
Method capacity = mapType.getDeclaredMethod("capacity");
capacity.setAccessible(true);
System.out.println("capacity : " + capacity.invoke(map)); // 2
當(dāng)初始化的容量設(shè)置成1的時(shí)候,通過(guò)反射取出來(lái)的capacity卻是2。在JDK1.8中,如果我們傳入的初始化容量為1,實(shí)際上設(shè)置的結(jié)果也是1。上面的代碼打印的結(jié)果為2的原因,是代碼中給map塞入值的操作導(dǎo)致了擴(kuò)容,容量從1擴(kuò)容到了2。事實(shí)上,在JDK1.7和JDK1.8中,HashMap初始化容量(capacity)的時(shí)機(jī)不同。在JDK1.8中,調(diào)用HashMap的構(gòu)造函數(shù)定義HashMap的時(shí)候,就會(huì)進(jìn)行容量的設(shè)定。而在JDK1.7中,要等到第一次put操作時(shí)才進(jìn)行這一操作。

因此,當(dāng)我們通過(guò)HashMap(int initialCapacity)設(shè)置初始容量的時(shí)候,HashMap并不一定會(huì)直接采用我們傳入的數(shù)值,而是經(jīng)過(guò)計(jì)算,得到一個(gè)新值,目的是提高h(yuǎn)ash的效率。比如1->1、3->4、7->8和9->16。

HashMap中初始容量的合理值

通過(guò)上面的分析我們可以知道,當(dāng)我們使用HashMap(int initialCapacity)來(lái)初始化容量的時(shí)候,JDK會(huì)默認(rèn)幫我們計(jì)算一個(gè)相對(duì)合理的值當(dāng)做初始容量。那么,是不是我們只需要把已知的HashMap中即將存放的元素個(gè)數(shù)直接傳給initialCapacity就可以了呢?

initialCapacity = (需要存儲(chǔ)的元素個(gè)數(shù) / 負(fù)載因子) + 1
這里的負(fù)載因子就是loaderFactor,默認(rèn)值為0.75。

initialCapacity = expectedSize / 0.75F + 1.0F
上面這個(gè)公式是《阿里巴巴Java開(kāi)發(fā)手冊(cè)》中的一個(gè)建議,在Guava中也是提供了相同的算法,更甚之,這個(gè)算法實(shí)際上是JDK8中putAll()方法的實(shí)現(xiàn)。這是公式的得出是因?yàn)椋?dāng)HashMap內(nèi)部維護(hù)的哈希表的容量達(dá)到75%時(shí)(默認(rèn)情況下),就會(huì)觸發(fā)rehash(重建hash表)操作。而rehash的過(guò)程是比較耗費(fèi)時(shí)間的。所以初始化容量要設(shè)置成expectedSize/0.75 + 1的話,可以有效地減少?zèng)_突,也可以減小誤差。

總結(jié)

當(dāng)我們想要在代碼中創(chuàng)建一個(gè)HashMap的時(shí)候,如果我們已知這個(gè)Map中即將存放的元素個(gè)數(shù),給HashMap設(shè)置初始容量可以在一定程度上提升效率。

但是,JDK并不會(huì)直接拿用戶傳進(jìn)來(lái)的數(shù)字當(dāng)做默認(rèn)容量,而是會(huì)進(jìn)行一番運(yùn)算,最終得到一個(gè)2的冪。而為了最大程度地避免擴(kuò)容帶來(lái)的性能消耗,通常是建議可以把默認(rèn)容量的數(shù)字設(shè)置成expectedSize / 0.75F + 1.0F。

在日常開(kāi)發(fā)中,可以使用Guava提供的一個(gè)方法來(lái)創(chuàng)建一個(gè)HashMap,計(jì)算的過(guò)程Guava會(huì)幫我們完成。

Map<String, String> map = Maps.newHashMapWithExpectedSize(10);
最后要說(shuō)的一點(diǎn)是,這種算法實(shí)際上是一種使用內(nèi)存換取性能的做法,在真正的應(yīng)用場(chǎng)景中要考慮到內(nèi)存的影響。

"當(dāng)你認(rèn)真喜歡一個(gè)人的時(shí)候,你的全世界都是她。"

你要去做一個(gè)大人,不要回頭,不要難過(guò)。

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

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