ConcurrentHashMap 和 Hashtable 的區(qū)別是什么，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

成都創(chuàng)新互聯(lián)長(zhǎng)期為上1000家客戶(hù)提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開(kāi)放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為嘉峪關(guān)企業(yè)提供專(zhuān)業(yè)的網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作，嘉峪關(guān)網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。

實(shí)現(xiàn)線(xiàn)程安全的方式不同

• 從原理上分析，Hashtable 實(shí)現(xiàn)并發(fā)安全的原理是通過(guò) synchronized 關(guān)鍵字，從源碼角度，以 clear() 方法為例，代碼如下：

public synchronized void clear() {
    Entry<?,?> tab[] = table;
    modCount++;
    for (int index = tab.length; --index >= 0; )
        tab[index] = null;
    count = 0;
}

clear() 方法是被 synchronized 關(guān)鍵字所修飾的，同理其他的方法例如 put、get、size 等，也同樣是被 synchronized 關(guān)鍵字修飾的。之所以 Hashtable 是線(xiàn)程安全的，是因?yàn)閹缀趺總€(gè)方法都被 synchronized 關(guān)鍵字所修飾了，這也就保證了線(xiàn)程安全。

Collections.SynchronizedMap(new HashMap()) 的原理和 Hashtable 類(lèi)似，也是利用 synchronized 實(shí)現(xiàn)的。

• 而 ConcurrentHashMap 實(shí)現(xiàn)的原理，卻有大大的不同

本質(zhì)上它實(shí)現(xiàn)線(xiàn)程安全的原理是利用了 CAS + synchronized + Node 節(jié)點(diǎn)的方式，這和 Hashtable 的完全利用 synchronized 的方式有很大的不同。

性能不同

因?yàn)樗鼈冊(cè)诰€(xiàn)程安全的實(shí)現(xiàn)方式上的不同，導(dǎo)致它們?cè)谛阅芊矫嬉灿泻艽蟮牟煌．?dāng)線(xiàn)程數(shù)量增加的時(shí)候：

• Hashtable 的性能會(huì)急劇下降，因?yàn)槊恳淮涡薷亩夹枰i住整個(gè)對(duì)象，而其他線(xiàn)程在此期間是不能操作的。不僅如此，還會(huì)帶來(lái)額外的上下文切換等開(kāi)銷(xiāo)，所以此時(shí)它的吞吐量甚至還不如單線(xiàn)程的情況。

• 而在 ConcurrentHashMap 中，就算上鎖也僅僅會(huì)對(duì)一部分上鎖而不是全部都上鎖，所以多線(xiàn)程中的吞吐量通常都會(huì)大于單線(xiàn)程的情況，也就是說(shuō)，在并發(fā)效率上，ConcurrentHashMap 比 Hashtable 提高了很多。

迭代時(shí)修改的不同

Hashtable（包括 HashMap）不允許在迭代期間修改內(nèi)容，否則會(huì)拋出ConcurrentModificationException 異常，其原理是檢測(cè) modCount 變量，迭代器的 next() 方法的代碼如下：

public T next() {
    if (modCount != expectedModCount)
        throw new ConcurrentModificationException();
    return nextElement();
}

next() 方法中，會(huì)首先判斷 modCount 是否等于 expectedModCount。其中 expectedModCount 是在迭代器生成的時(shí)候隨之生成的，并且不會(huì)改變。

它所代表的含義是當(dāng)前 Hashtable 被修改的次數(shù)，而每一次去調(diào)用 Hashtable 的包括 addEntry()、remove()、rehash() 等方法中，都會(huì)修改 modCount 的值。這樣一來(lái)，如果我們?cè)诘倪^(guò)程中，去對(duì)整個(gè) Hashtable 的內(nèi)容做了修改的話(huà)，也就同樣會(huì)反映到 modCount 中。這樣一來(lái)，迭代器在進(jìn)行 next 的時(shí)候，也可以感知到，于是它就會(huì)發(fā)現(xiàn) modCount 不等于 expectedModCount，就會(huì)拋出 ConcurrentModificationException 異常。

• 所以對(duì)于 Hashtable 而言，它是不允許在迭代期間對(duì)內(nèi)容進(jìn)行修改的。

• 相反，ConcurrentHashMap 即便在迭代期間修改內(nèi)容，也不會(huì)拋出ConcurrentModificationException。

如果我們有并發(fā)的場(chǎng)景，那么使用 ConcurrentHashMap 是最合適的，Hashtable 已經(jīng)不再推薦使用。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。

分享標(biāo)題：ConcurrentHashMap和Hashtable的區(qū)別是什么
文章來(lái)源：http://m.newbst.com/article42/gcsgec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、外貿(mào)建站、靜態(tài)網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)公司、微信小程序、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)