hashMap在多線程環(huán)境下的表現(xiàn)

• 在jdk1.7中多線程put時(shí)可能會(huì)導(dǎo)致get無(wú)限循環(huán)，具體表現(xiàn)為CPU使用率100%；

該方法實(shí)現(xiàn)的機(jī)制就是將每個(gè)鏈表轉(zhuǎn)化到新鏈表，并且鏈表中的位置發(fā)生反轉(zhuǎn)，而這在多線程情況下是很容易造成鏈表回路，從而發(fā)生 get() 死循環(huán)。所以只要保證建新鏈時(shí)還是按照原來(lái)的順序的話就不會(huì)產(chǎn)生循環(huán)（JDK 8 的改進(jìn)）。即在jdk1.7是采用的頭插法，在jdk1.8使用了尾插法解決。

HashMap死循環(huán)只發(fā)生在JDK1.7版本中，主要原因是JDK1.7中的HashMap，在頭插法 加 鏈表 加 多線程并發(fā) 加 擴(kuò)容這幾個(gè)情形累加到一起就會(huì)形成死循環(huán)。多線程環(huán)境下建議采用ConcurrentHashMap替代。

• 多線程put時(shí)可能導(dǎo)致元素丟失 原因：當(dāng)多個(gè)線程同時(shí)執(zhí)行addEntry(hash,key ,value,i)時(shí)，如果產(chǎn)生哈希碰撞，導(dǎo)致兩個(gè)線程得到同樣的bucketIndex去存儲(chǔ)，就可能會(huì)發(fā)生元素覆蓋丟失的情況

Hashmap中的鏈表大小超過(guò)八個(gè)時(shí)會(huì)自動(dòng)轉(zhuǎn)化為紅黑樹(shù)，當(dāng)刪除小于六時(shí)重新變?yōu)殒湵?，為啥呢?/h2>

根據(jù)泊松分布，在負(fù)載因子默認(rèn)為0.75的時(shí)候，單個(gè)hash槽內(nèi)元素個(gè)數(shù)為8的概率小于百萬(wàn)分之一，所以將7作為一個(gè)分水嶺，等于7的時(shí)候不轉(zhuǎn)換，大于等于8的時(shí)候才進(jìn)行轉(zhuǎn)換，小于等于6的時(shí)候就化為鏈表。 避免樹(shù)和鏈表的頻繁轉(zhuǎn)換

從時(shí)間復(fù)雜度分析，樹(shù)的查詢時(shí)間復(fù)雜度是logn，所于大于等于8使用紅黑樹(shù)。

Collections.synchronizedMap是怎么實(shí)現(xiàn)線程安全的

在SynchronizedMap內(nèi)部維護(hù)了一個(gè)普通對(duì)象Map，還有排斥鎖mutex，如圖

我們?cè)谡{(diào)用這個(gè)方法的時(shí)候就需要傳入一個(gè)Map，可以看到有兩個(gè)構(gòu)造器，如果你傳入了mutex參數(shù)，則將對(duì)象排斥鎖賦值為傳入的對(duì)象。

如果沒(méi)有，則將對(duì)象排斥鎖賦值為this，即調(diào)用synchronizedMap的對(duì)象，就是上面的Map。

創(chuàng)建出synchronizedMap之后，再操作map的時(shí)候，就會(huì)對(duì)方法上鎖。

以上就是JDK1.7中HashMap的死循環(huán)問(wèn)題及解決方案的詳細(xì)內(nèi)容，更多關(guān)于JDK1.7 HashMap死循環(huán)解決的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論