快捷導(dǎo)航

Java?HashMap中除了死循環(huán)之外的那些問題

更新時(shí)間：2022年05月09日 10:28:46 作者：??Java中文社群????

這篇文章主要介紹了Java?HashMap中除了死循環(huán)之外的那些問題，這些問題大致可以分為兩類，程序問題和業(yè)務(wù)問題，下面文章我們一個(gè)一個(gè)來(lái)看，需要的小伙伴可以參考一下

1.死循環(huán)問題

死循環(huán)問題發(fā)生在 JDK 1.7 版本中，形成的原因是 JDK 1.7 HashMap 使用的是頭插法，那么在并發(fā)擴(kuò)容時(shí)可能就會(huì)導(dǎo)致死循環(huán)的問題，具體產(chǎn)生的過(guò)程如下流程所示。

HashMap 正常情況下的擴(kuò)容實(shí)現(xiàn)如下圖所示：

舊 HashMap 的節(jié)點(diǎn)會(huì)依次轉(zhuǎn)移到新 HashMap 中，舊 HashMap 轉(zhuǎn)移的順序是 A、B、C，而新 HashMap 使用的是頭插法，所以最終在新 HashMap 中的順序是 C、B、A，也就是上圖展示的那樣。有了這些前置知識(shí)之后，咱們來(lái)看死循環(huán)是如何誕生的？

1.1 死循環(huán)執(zhí)行流程一

死循環(huán)是因?yàn)椴l(fā) HashMap 擴(kuò)容導(dǎo)致的，并發(fā)擴(kuò)容的第一步，線程 T1 和線程 T2 要對(duì) HashMap 進(jìn)行擴(kuò)容操作，此時(shí) T1 和 T2 指向的是鏈表的頭結(jié)點(diǎn)元素 A，而 T1 和 T2 的下一個(gè)節(jié)點(diǎn)，也就是 T1.next 和 T2.next 指向的是 B 節(jié)點(diǎn)，

如下圖所示：

1.2 死循環(huán)執(zhí)行流程二

死循環(huán)的第二步操作是，線程 T2 時(shí)間片用完進(jìn)入休眠狀態(tài)，而線程 T1 開始執(zhí)行擴(kuò)容操作，一直到線程 T1 擴(kuò)容完成后，線程 T2 才被喚醒，擴(kuò)容之后的場(chǎng)景如下圖所示：

從上圖可知線程 T1 執(zhí)行之后，因?yàn)槭穷^插法，所以 HashMap 的順序已經(jīng)發(fā)生了改變，但線程 T2 對(duì)于發(fā)生的一切是不可知的，所以它的指向元素依然沒變，如上圖展示的那樣，T2 指向的是 A 元素，T2.next 指向的節(jié)點(diǎn)是 B 元素。

1.3 死循環(huán)執(zhí)行流程三

當(dāng)線程 T1 執(zhí)行完，而線程 T2 恢復(fù)執(zhí)行時(shí)，死循環(huán)就建立了，如下圖所示：

因?yàn)?T1 執(zhí)行完擴(kuò)容之后 B 節(jié)點(diǎn)的下一個(gè)節(jié)點(diǎn)是 A，而 T2 線程指向的首節(jié)點(diǎn)是 A，第二個(gè)節(jié)點(diǎn)是 B，這個(gè)順序剛好和 T1 擴(kuò)完容完之后的節(jié)點(diǎn)順序是相反的。T1 執(zhí)行完之后的順序是 B 到 A，而 T2 的順序是 A 到 B，這樣 A 節(jié)點(diǎn)和 B 節(jié)點(diǎn)就形成死循環(huán)了，這就是 HashMap 死循環(huán)導(dǎo)致的原因。

1.4 解決方案

使用線程安全的容器來(lái)替代 HashMap，比如 ConcurrentHashMap 或 Hashtable，因?yàn)?ConcurrentHashMap 的性能遠(yuǎn)高于 Hashtable，因此推薦使用 ConcurrentHashMap 來(lái)替代 HashMap。

2.數(shù)據(jù)覆蓋問題

數(shù)據(jù)覆蓋問題發(fā)生在并發(fā)添加元素的場(chǎng)景下，它不止出現(xiàn)在 JDK 1.7 版本中，其他版本中也存在此問題

數(shù)據(jù)覆蓋產(chǎn)生的流程如下：

線程 T1 進(jìn)行添加時(shí)，判斷某個(gè)位置可以插入元素，但還沒有真正的進(jìn)行插入操作，自己時(shí)間片就用完了。
線程 T2 也執(zhí)行添加操作，并且 T2 產(chǎn)生的哈希值和 T1 相同，也就是 T2 即將要存儲(chǔ)的位置和 T1 相同，因?yàn)榇宋恢蒙形床迦胫担═1 線程執(zhí)行了一半），于是 T2 就把自己的值存入到當(dāng)前位置了。
T1 恢復(fù)執(zhí)行之后，因?yàn)榉强张袛嘁呀?jīng)執(zhí)行完了，它感知不到此位置已經(jīng)有值了，于是就把自己的值也插入到了此位置，那么 T2 的值就被覆蓋了。

具體執(zhí)行流程如下圖所示。

2.1 數(shù)據(jù)覆蓋執(zhí)行流程一

線程 T1 準(zhǔn)備將數(shù)據(jù) k1:v1 插入到 Null 處，但還沒有真正的執(zhí)行，自己的時(shí)間片就用完了，進(jìn)入休眠狀態(tài)了，

如下圖所示：

2.2 數(shù)據(jù)覆蓋執(zhí)行流程二

線程 T2 準(zhǔn)備將數(shù)據(jù) k2:v2 插入到 Null 處，因?yàn)榇颂幀F(xiàn)在并未有值，如果此處有值的話，它會(huì)使用鏈?zhǔn)椒▽?shù)據(jù)插入到下一個(gè)沒值的位置上，但判斷之后發(fā)現(xiàn)此處并未有值，那么就直接進(jìn)行數(shù)據(jù)插入了，

如下圖所示：

2.3 數(shù)據(jù)覆蓋執(zhí)行流程三

線程 T2 執(zhí)行完成之后，線程 T1 恢復(fù)執(zhí)行，因?yàn)榫€程 T1 之前已經(jīng)判斷過(guò)此位置沒值了，所以會(huì)直接插入，此時(shí)線程 T2 插入的值就被覆蓋了，

如下圖所示：

2.4 解決方案

解決方案和第一個(gè)解決方案相同，使用 ConcurrentHashMap 來(lái)替代 HashMap 就可以解決此問題了。

3.無(wú)序性問題

這里的無(wú)序性問題指的是 HashMap 添加和查詢的順序不一致，導(dǎo)致程序執(zhí)行的結(jié)果和程序員預(yù)期的結(jié)果不相符，

如以下代碼所示：

HashMap<String, String> map = new HashMap<>();
// 添加元素
for (int i = 1; i <= 5; i++) {
    map.put("2022-10-" + i, "Hello，Java：" + i);
}
// 查詢?cè)?
map.forEach((k, v) -> {
    System.out.println(k + "：" + v);
});

我們添加的順序：

我們期望查詢的順序和添加的順序是一致的，然而以上代碼輸出的結(jié)果卻是：

執(zhí)行結(jié)果和我們預(yù)期結(jié)果不相符，這就是 HashMap 的無(wú)序性問題。我們期望輸出的結(jié)果是 Hello，Java 1、2、3、4、5，而得到的順序卻是 2、1、4、3、5。

3.1 解決方案

想要解決 HashMap 無(wú)序問題，我們只需要將 HashMap 替換成 LinkedHashMap 就可以了，

如下代碼所示：

LinkedHashMap<String, String> map = new LinkedHashMap<>();
// 添加元素
for (int i = 1; i <= 5; i++) {
    map.put("2022-10-" + i, "Hello，Java：" + i);
}
// 查詢?cè)?
map.forEach((k, v) -> {
    System.out.println(k + "：" + v);
});

以上程序的執(zhí)行結(jié)果如下圖所示：

總結(jié)

本文演示了 3 個(gè) HashMap 的經(jīng)典問題，其中死循環(huán)和數(shù)據(jù)覆蓋是發(fā)生在并發(fā)添加元素時(shí)，而無(wú)序問題是添加元素的順序和查詢的順序不一致的問題，這些問題本質(zhì)來(lái)說(shuō)都是對(duì) HashMap 使用不當(dāng)才會(huì)造成的問題，比如在多線程情況下就應(yīng)該使用 ConcurrentHashMap，想要保證插入順序和查詢順序一致就應(yīng)該使用 LinkedHashMap，但剛開始時(shí)我們對(duì) HashMap 不熟悉，所以才會(huì)造成這些問題，不過(guò)了解了它們之后，就能更好的使用它和更好的應(yīng)對(duì)面試了。

到此這篇關(guān)于Java HashMap中除了死循環(huán)之外的那些問題的文章就介紹到這了,更多相關(guān)Java HashMap內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: