來(lái)源：cnblogs.com/zhuoqingsen/p/HashMap.html

現(xiàn)在是晚上11點(diǎn)了，學(xué)校屠豬館的自習(xí)室因?yàn)樘硪P(guān)閉了。勤奮且疲憊的小魯班也從屠豬館出來(lái)了，正準(zhǔn)備回宿舍洗洗睡，由于自習(xí)室位置比較偏僻所以是接收不到手機(jī)網(wǎng)絡(luò)信號(hào)的，因此小魯班從兜里掏出手機(jī)的時(shí)候，信息可真是炸了呀。小魯班心想，微信群平時(shí)都沒(méi)什么人聊天，今晚肯定是發(fā)生了什么大事。仔細(xì)一看，才發(fā)現(xiàn)原來(lái)是小魯班的室友達(dá)摩（光頭）拿到了阿里巴巴 Java 開(kāi)發(fā)實(shí)習(xí)生的 Offer，此時(shí)小魯班真替他室友感到高興的同時(shí)，心里也難免會(huì)產(chǎn)生一絲絲的失落感，那是因?yàn)樽约和读撕芏喾莺?jiǎn)歷，別說(shuō)拿不拿得到 Offer，就連給面試邀的公司也都寥寥無(wú)幾。小魯班這會(huì)可真是受到了一萬(wàn)點(diǎn)真實(shí)暴擊。不過(guò)小魯班還是很樂(lè)觀的，很快調(diào)整了心態(tài)，帶上耳機(jī)，慢慢的走回了宿舍，正打算準(zhǔn)備向他那神室友達(dá)摩取取經(jīng)。

片刻后~

小魯班：666，聽(tīng)說(shuō)你拿到了阿里的 Offer，能透露一下面試內(nèi)容和技巧嗎？
達(dá)摩：嘿嘿嘿，沒(méi)問(wèn)題鴨，叫聲爸爸我就告訴你。
小魯班：耙耙（表面笑嘻嘻，心里MMP）
達(dá)摩：其實(shí)我也不是很記得了（請(qǐng)繼續(xù)裝），但我還是記得那么一些。如果你是面的 Java，首先當(dāng)然是 Java 的基礎(chǔ)知識(shí)：數(shù)據(jù)結(jié)構(gòu)（Map / List / Set等）、設(shè)計(jì)模式、算法、線程相關(guān)、IO/NIO、序列化等等。其次是高級(jí)特性：反射機(jī)制、并發(fā)與鎖、JVM（GC策略 / 類加載機(jī)制 / 內(nèi)存模型）等等。
小魯班：問(wèn)這么多內(nèi)容，那豈不是一個(gè)人都面試很久嗎？
達(dá)摩：不是的，面試官一般都會(huì)用連環(huán)炮的方式提問(wèn)的。
小魯班：你說(shuō)的連環(huán)炮是什么意思鴨？
達(dá)摩：那我舉個(gè)例子：

• 就比如問(wèn)你?HashMap 是不是有序的？你回答不是有序的。

• 那面試官就會(huì)可能繼續(xù)問(wèn)你，有沒(méi)有有序的Map實(shí)現(xiàn)類呢？你如果這個(gè)時(shí)候說(shuō)不知道的話，那這塊問(wèn)題就到此結(jié)束了。如果你說(shuō)有 TreeMap 和 LinkedHashMap。

• 那么面試官接下來(lái)就可能會(huì)問(wèn)你，TreeMap 和 LinkedHashMap 是如何保證它的順序的？如果你回答不上來(lái)，那么到此為止。如果你說(shuō) TreeMap 是通過(guò)實(shí)現(xiàn) SortMap 接口，能夠把它保存的鍵值對(duì)根據(jù) key 排序，基于紅黑樹(shù)，從而保證 TreeMap 中所有鍵值對(duì)處于有序狀態(tài)。LinkedHashMap 則是通過(guò)插入排序（就是你 put 的時(shí)候的順序是什么，取出來(lái)的時(shí)候就是什么樣子）和訪問(wèn)排序（改變排序把訪問(wèn)過(guò)的放到底部）讓鍵值有序。

• 那么面試官還會(huì)繼續(xù)問(wèn)你，你覺(jué)得它們兩個(gè)哪個(gè)的有序?qū)崿F(xiàn)比較好？如果你依然可以回答的話，那么面試官會(huì)繼續(xù)問(wèn)你，你覺(jué)得還有沒(méi)有比它更好或者更高效的實(shí)現(xiàn)方式？

無(wú)窮無(wú)盡深入，直到你回答不出來(lái)或者面試官認(rèn)為問(wèn)題到底了。

小魯班捏了一把汗，我去……這是魔鬼吧，那我們來(lái)試試唄（因?yàn)樾◆敯鄤倓傇谧粤?xí)室才看了這章的知識(shí)，想趁機(jī)裝一波逼，畢竟剛剛叫了聲爸爸~~）

于是達(dá)摩 and 小魯班就開(kāi)始了對(duì)決：

1、為什么用HashMap？

• HashMap 是一個(gè)散列桶（數(shù)組和鏈表），它存儲(chǔ)的內(nèi)容是鍵值對(duì) key-value 映射

• HashMap 采用了數(shù)組和鏈表的數(shù)據(jù)結(jié)構(gòu)，能在查詢和修改方便繼承了數(shù)組的線性查找和鏈表的尋址修改

• HashMap 是非 synchronized，所以 HashMap 很快

• HashMap 可以接受 null 鍵和值，而 Hashtable 則不能（原因就是 equlas() 方法需要對(duì)象，因?yàn)?HashMap 是后出的 API 經(jīng)過(guò)處理才可以）

2、HashMap 的工作原理是什么？

HashMap 是基于 hashing 的原理

我們使用 put(key, value) 存儲(chǔ)對(duì)象到 HashMap 中，使用 get(key) 從 HashMap 中獲取對(duì)象。當(dāng)我們給 put() 方法傳遞鍵和值時(shí)，我們先對(duì)鍵調(diào)用 hashCode() 方法，計(jì)算并返回的 hashCode 是用于找到 Map 數(shù)組的 bucket 位置來(lái)儲(chǔ)存 Node 對(duì)象。

這里關(guān)鍵點(diǎn)在于指出，HashMap 是在 bucket 中儲(chǔ)存鍵對(duì)象和值對(duì)象，作為Map.Node 。

以下是 HashMap 初始化

簡(jiǎn)化的模擬數(shù)據(jù)結(jié)構(gòu)：

Node[] table = new Node[16]; // 散列桶初始化，table
class Node {
? ?hash; //hash值
? ?key; //鍵
? ?value; //值
? ?node next; //用于指向鏈表的下一層（產(chǎn)生沖突，用拉鏈法）
}

以下是具體的 put 過(guò)程（JDK1.8）

對(duì) Key 求 Hash 值，然后再計(jì)算下標(biāo)

如果沒(méi)有碰撞，直接放入桶中（碰撞的意思是計(jì)算得到的 Hash 值相同，需要放到同一個(gè) bucket 中）

如果碰撞了，以鏈表的方式鏈接到后面

如果鏈表長(zhǎng)度超過(guò)閥值（TREEIFY THRESHOLD==8），就把鏈表轉(zhuǎn)成紅黑樹(shù)，鏈表長(zhǎng)度低于6，就把紅黑樹(shù)轉(zhuǎn)回鏈表

如果節(jié)點(diǎn)已經(jīng)存在就替換舊值

如果桶滿了（容量16 * 加載因子0.75），就需要 resize（擴(kuò)容2倍后重排）

以下是具體 get 過(guò)程

考慮特殊情況：如果兩個(gè)鍵的 hashcode 相同，你如何獲取值對(duì)象？

當(dāng)我們調(diào)用 get() 方法，HashMap 會(huì)使用鍵對(duì)象的 hashcode 找到 bucket 位置，找到 bucket 位置之后，會(huì)調(diào)用 keys.equals() 方法去找到鏈表中正確的節(jié)點(diǎn)，最終找到要找的值對(duì)象。

3、有什么方法可以減少碰撞？

擾動(dòng)函數(shù)可以減少碰撞

原理是如果兩個(gè)不相等的對(duì)象返回不同的 hashcode 的話，那么碰撞的幾率就會(huì)小些。這就意味著存鏈表結(jié)構(gòu)減小，這樣取值的話就不會(huì)頻繁調(diào)用 equal 方法，從而提高 HashMap 的性能（擾動(dòng)即 Hash 方法內(nèi)部的算法實(shí)現(xiàn)，目的是讓不同對(duì)象返回不同 hashcode）。

使用不可變的、聲明作 final 對(duì)象，并且采用合適的 equals() 和 hashCode() 方法，將會(huì)減少碰撞的發(fā)生

不可變性使得能夠緩存不同鍵的 hashcode，這將提高整個(gè)獲取對(duì)象的速度，使用 String、Integer 這樣的 wrapper 類作為鍵是非常好的選擇。

為什么 String、Integer 這樣的 wrapper 類適合作為鍵？

因?yàn)?String 是 final，而且已經(jīng)重寫(xiě)了 equals() 和 hashCode() 方法了。不可變性是必要的，因?yàn)闉榱艘?jì)算 hashCode()，就要防止鍵值改變，如果鍵值在放入時(shí)和獲取時(shí)返回不同的 hashcode 的話，那么就不能從 HashMap 中找到你想要的對(duì)象。

4、HashMap 中 hash 函數(shù)怎么是實(shí)現(xiàn)的？

我們可以看到，在 hashmap 中要找到某個(gè)元素，需要根據(jù) key 的 hash 值來(lái)求得對(duì)應(yīng)數(shù)組中的位置。如何計(jì)算這個(gè)位置就是 hash 算法。

前面說(shuō)過(guò)，hashmap 的數(shù)據(jù)結(jié)構(gòu)是數(shù)組和鏈表的結(jié)合，所以我們當(dāng)然希望這個(gè) hashmap 里面的元素位置盡量的分布均勻些，盡量使得每個(gè)位置上的元素?cái)?shù)量只有一個(gè)。那么當(dāng)我們用 hash 算法求得這個(gè)位置的時(shí)候，馬上就可以知道對(duì)應(yīng)位置的元素就是我們要的，而不用再去遍歷鏈表。 所以，我們首先想到的就是把 hashcode 對(duì)數(shù)組長(zhǎng)度取模運(yùn)算。這樣一來(lái)，元素的分布相對(duì)來(lái)說(shuō)是比較均勻的。

但是“模”運(yùn)算的消耗還是比較大的，能不能找一種更快速、消耗更小的方式？我們來(lái)看看 JDK1.8 源碼是怎么做的（被樓主修飾了一下）

static final int hash(Object key) {
? ?if (key == null){
? ? ? ?return 0;
? ?}
? ?int h;
? ?h = key.hashCode()；返回散列值也就是hashcode
? ?// ^ ：按位異或
? ?// >>>:無(wú)符號(hào)右移，忽略符號(hào)位，空位都以0補(bǔ)齊
? ?//其中n是數(shù)組的長(zhǎng)度，即Map的數(shù)組部分初始化長(zhǎng)度
? ?return (n-1)&(h ^ (h >>> 16));
}

簡(jiǎn)單來(lái)說(shuō)就是：

• 高16 bit 不變，低16 bit 和高16 bit 做了一個(gè)異或（得到的 hashcode 轉(zhuǎn)化為32位二進(jìn)制，前16位和后16位低16 bit 和高16 bit 做了一個(gè)異或）

• (n·1) & hash = -> 得到下標(biāo)

5、拉鏈法導(dǎo)致的鏈表過(guò)深，為什么不用二叉查找樹(shù)代替而選擇紅黑樹(shù)？為什么不一直使用紅黑樹(shù)？

之所以選擇紅黑樹(shù)是為了解決二叉查找樹(shù)的缺陷：二叉查找樹(shù)在特殊情況下會(huì)變成一條線性結(jié)構(gòu)（這就跟原來(lái)使用鏈表結(jié)構(gòu)一樣了，造成層次很深的問(wèn)題），遍歷查找會(huì)非常慢。而紅黑樹(shù)在插入新數(shù)據(jù)后可能需要通過(guò)左旋、右旋、變色這些操作來(lái)保持平衡。引入紅黑樹(shù)就是為了查找數(shù)據(jù)快，解決鏈表查詢深度的問(wèn)題。我們知道紅黑樹(shù)屬于平衡二叉樹(shù)，為了保持“平衡”是需要付出代價(jià)的，但是該代價(jià)所損耗的資源要比遍歷線性鏈表要少。所以當(dāng)長(zhǎng)度大于8的時(shí)候，會(huì)使用紅黑樹(shù)；如果鏈表長(zhǎng)度很短的話，根本不需要引入紅黑樹(shù)，引入反而會(huì)慢。

6、說(shuō)說(shuō)你對(duì)紅黑樹(shù)的見(jiàn)解？

每個(gè)節(jié)點(diǎn)非紅即黑

根節(jié)點(diǎn)總是黑色的

如果節(jié)點(diǎn)是紅色的，則它的子節(jié)點(diǎn)必須是黑色的（反之不一定）

每個(gè)葉子節(jié)點(diǎn)都是黑色的空節(jié)點(diǎn)（NIL節(jié)點(diǎn)）

從根節(jié)點(diǎn)到葉節(jié)點(diǎn)或空子節(jié)點(diǎn)的每條路徑，必須包含相同數(shù)目的黑色節(jié)點(diǎn)（即相同的黑色高度）

7、解決 hash 碰撞還有那些辦法？

開(kāi)放定址法

當(dāng)沖突發(fā)生時(shí)，使用某種探查技術(shù)在散列表中形成一個(gè)探查（測(cè)）序列。沿此序列逐個(gè)單元地查找，直到找到給定的地址。按照形成探查序列的方法不同，可將開(kāi)放定址法區(qū)分為線性探查法、二次探查法、雙重散列法等。

下面給一個(gè)線性探查法的例子：

問(wèn)題：已知一組關(guān)鍵字為 (26，36，41，38，44，15，68，12，06，51)，用除余法構(gòu)造散列函數(shù)，用線性探查法解決沖突構(gòu)造這組關(guān)鍵字的散列表。
解答：

為了減少?zèng)_突，通常令裝填因子 α 由除余法因子是13的散列函數(shù)計(jì)算出的上述關(guān)鍵字序列的散列地址為 (0，10，2，12，5，2，3，12，6，12)。
前5個(gè)關(guān)鍵字插入時(shí)，其相應(yīng)的地址均為開(kāi)放地址，故將它們直接插入 T[0]、T[10)、T[2]、T[12] 和 T[5] 中。
當(dāng)插入第6個(gè)關(guān)鍵字15時(shí)，其散列地址2（即 h(15)=15％13=2）已被關(guān)鍵字 41（15和41互為同義詞）占用。故探查 h1=(2+1)％13=3，此地址開(kāi)放，所以將 15 放入 T[3] 中。
當(dāng)插入第7個(gè)關(guān)鍵字68時(shí)，其散列地址3已被非同義詞15先占用，故將其插入到T[4]中。
當(dāng)插入第8個(gè)關(guān)鍵字12時(shí)，散列地址12已被同義詞38占用，故探查 hl=(12+1)％13=0，而 T[0] 亦被26占用，再探查 h2=(12+2)％13=1，此地址開(kāi)放，可將12插入其中。
類似地，第9個(gè)關(guān)鍵字06直接插入 T[6] 中；而最后一個(gè)關(guān)鍵字51插人時(shí)，因探查的地址 12，0，1，…，6 均非空，故51插入 T[7] 中。

8、如果 HashMap 的大小超過(guò)了負(fù)載因子（load factor）定義的容量怎么辦？

HashMap 默認(rèn)的負(fù)載因子大小為0.75。也就是說(shuō)，當(dāng)一個(gè) Map 填滿了75%的 bucket 時(shí)候，和其它集合類一樣（如 ArrayList 等），將會(huì)創(chuàng)建原來(lái) HashMap 大小的兩倍的 bucket 數(shù)組來(lái)重新調(diào)整 Map 大小，并將原來(lái)的對(duì)象放入新的 bucket 數(shù)組中。這個(gè)過(guò)程叫作?rehashing。

因?yàn)樗{(diào)用 hash 方法找到新的 bucket 位置。這個(gè)值只可能在兩個(gè)地方，一個(gè)是原下標(biāo)的位置，另一種是在下標(biāo)為?<原下標(biāo)+原容量>?的位置。

9、重新調(diào)整 HashMap 大小存在什么問(wèn)題嗎？

重新調(diào)整 HashMap 大小的時(shí)候，確實(shí)存在條件競(jìng)爭(zhēng)。

因?yàn)槿绻麅蓚€(gè)線程都發(fā)現(xiàn) HashMap 需要重新調(diào)整大小了，它們會(huì)同時(shí)試著調(diào)整大小。在調(diào)整大小的過(guò)程中，存儲(chǔ)在鏈表中的元素的次序會(huì)反過(guò)來(lái)。因?yàn)橐苿?dòng)到新的 bucket 位置的時(shí)候，HashMap 并不會(huì)將元素放在鏈表的尾部，而是放在頭部。這是為了避免尾部遍歷（tail traversing）。如果條件競(jìng)爭(zhēng)發(fā)生了，那么就死循環(huán)了。多線程的環(huán)境下不使用 HashMap。

為什么多線程會(huì)導(dǎo)致死循環(huán)，它是怎么發(fā)生的？

HashMap 的容量是有限的。當(dāng)經(jīng)過(guò)多次元素插入，使得 HashMap 達(dá)到一定飽和度時(shí)，Key 映射位置發(fā)生沖突的幾率會(huì)逐漸提高。這時(shí)候， HashMap 需要擴(kuò)展它的長(zhǎng)度，也就是進(jìn)行Resize。

擴(kuò)容：創(chuàng)建一個(gè)新的 Entry 空數(shù)組，長(zhǎng)度是原數(shù)組的2倍

rehash：遍歷原 Entry 數(shù)組，把所有的 Entry 重新 Hash 到新數(shù)組

（這個(gè)過(guò)程比較燒腦，暫不作流程圖演示，有興趣去看看我的另一篇博文“HashMap擴(kuò)容全過(guò)程”）

達(dá)摩：哎呦，小老弟不錯(cuò)嘛~~意料之外呀
小魯班：嘿嘿，優(yōu)秀吧，中場(chǎng)休息一波，我先喝口水
達(dá)摩：不僅僅是這些哦，面試官還會(huì)問(wèn)你相關(guān)的集合類對(duì)比，比如：

10、HashTable

• 數(shù)組 + 鏈表方式存儲(chǔ)

• 默認(rèn)容量：11（質(zhì)數(shù)為宜）

• put操作：首先進(jìn)行索引計(jì)算 （key.hashCode() & 0x7FFFFFFF）% table.length；若在鏈表中找到了，則替換舊值，若未找到則繼續(xù)；當(dāng)總元素個(gè)數(shù)超過(guò) 容量 * 加載因子 時(shí)，擴(kuò)容為原來(lái) 2 倍并重新散列；將新元素加到鏈表頭部

• 對(duì)修改 Hashtable 內(nèi)部共享數(shù)據(jù)的方法添加了 synchronized，保證線程安全

11、HashMap 與 HashTable 區(qū)別

• 默認(rèn)容量不同，擴(kuò)容不同

• 線程安全性：HashTable 安全

• 效率不同：HashTable 要慢，因?yàn)榧渔i

12、可以使用 CocurrentHashMap 來(lái)代替 Hashtable 嗎？

• 我們知道 Hashtable 是 synchronized 的，但是 ConcurrentHashMap 同步性能更好，因?yàn)樗鼉H僅根據(jù)同步級(jí)別對(duì) map 的一部分進(jìn)行上鎖

• ConcurrentHashMap 當(dāng)然可以代替 HashTable，但是 HashTable 提供更強(qiáng)的線程安全性

• 它們都可以用于多線程的環(huán)境，但是當(dāng) Hashtable 的大小增加到一定的時(shí)候，性能會(huì)急劇下降，因?yàn)榈鷷r(shí)需要被鎖定很長(zhǎng)的時(shí)間。由于 ConcurrentHashMap 引入了分割（segmentation），不論它變得多么大，僅僅需要鎖定 Map 的某個(gè)部分，其它的線程不需要等到迭代完成才能訪問(wèn) Map。簡(jiǎn)而言之，在迭代的過(guò)程中，ConcurrentHashMap 僅僅鎖定 Map 的某個(gè)部分，而 Hashtable 則會(huì)鎖定整個(gè) Map

13、CocurrentHashMap（JDK 1.7）

• CocurrentHashMap 是由 Segment 數(shù)組和 HashEntry 數(shù)組和鏈表組成

• Segment 是基于重入鎖（ReentrantLock）：一個(gè)數(shù)據(jù)段競(jìng)爭(zhēng)鎖。每個(gè) HashEntry 一個(gè)鏈表結(jié)構(gòu)的元素，利用 Hash 算法得到索引確定歸屬的數(shù)據(jù)段，也就是對(duì)應(yīng)到在修改時(shí)需要競(jìng)爭(zhēng)獲取的鎖。ConcurrentHashMap 支持 CurrencyLevel（Segment 數(shù)組數(shù)量）的線程并發(fā)。每當(dāng)一個(gè)線程占用鎖訪問(wèn)一個(gè) Segment 時(shí)，不會(huì)影響到其他的 Segment

• 核心數(shù)據(jù)如 value，以及鏈表都是 volatile 修飾的，保證了獲取時(shí)的可見(jiàn)性

• 首先是通過(guò) key 定位到 Segment，之后在對(duì)應(yīng)的 Segment 中進(jìn)行具體的 put 操作如下：

將當(dāng)前 Segment 中的 table 通過(guò) key 的 hashcode 定位到 HashEntry。

遍歷該 HashEntry，如果不為空則判斷傳入的? key 和當(dāng)前遍歷的 key 是否相等，相等則覆蓋舊的 value

不為空則需要新建一個(gè) HashEntry 并加入到 Segment 中，同時(shí)會(huì)先判斷是否需要擴(kuò)容

最后會(huì)解除在 1 中所獲取當(dāng)前 Segment 的鎖

雖然 HashEntry 中的 value 是用 volatile 關(guān)鍵詞修飾的，但是并不能保證并發(fā)的原子性，所以 put 操作時(shí)仍然需要加鎖處理

首先第一步的時(shí)候會(huì)嘗試獲取鎖，如果獲取失敗肯定就有其他線程存在競(jìng)爭(zhēng)，則利用 scanAndLockForPut() 自旋獲取鎖

• 嘗試自旋獲取鎖

• 如果重試的次數(shù)達(dá)到了 MAX_SCAN_RETRIES 則改為阻塞鎖獲取，保證能獲取成功。最后解除當(dāng)前 Segment 的鎖

14、CocurrentHashMap（JDK 1.8）

CocurrentHashMap?拋棄了原有的 Segment 分段鎖，采用了?CAS + synchronized?來(lái)保證并發(fā)安全性。其中的?val next?都用了 volatile 修飾，保證了可見(jiàn)性。

最大特點(diǎn)是引入了 CAS

借助 Unsafe 來(lái)實(shí)現(xiàn) native code。CAS有3個(gè)操作數(shù)，內(nèi)存值 V、舊的預(yù)期值 A、要修改的新值 B。當(dāng)且僅當(dāng)預(yù)期值 A 和內(nèi)存值 V 相同時(shí)，將內(nèi)存值V修改為 B，否則什么都不做。Unsafe 借助 CPU 指令 cmpxchg 來(lái)實(shí)現(xiàn)。

CAS 使用實(shí)例

對(duì) sizeCtl 的控制都是用 CAS 來(lái)實(shí)現(xiàn)的：

• -1 代表 table 正在初始化

• N 表示有 -N-1 個(gè)線程正在進(jìn)行擴(kuò)容操作

• 如果 table 未初始化，表示table需要初始化的大小

• 如果 table 初始化完成，表示table的容量，默認(rèn)是table大小的0.75倍，用這個(gè)公式算 0.75（n – (n >>> 2)）

CAS 會(huì)出現(xiàn)的問(wèn)題：ABA

解決：對(duì)變量增加一個(gè)版本號(hào)，每次修改，版本號(hào)加 1，比較的時(shí)候比較版本號(hào)。

put 過(guò)程

• 根據(jù) key 計(jì)算出 hashcode

• 判斷是否需要進(jìn)行初始化

• 通過(guò) key 定位出的 Node，如果為空表示當(dāng)前位置可以寫(xiě)入數(shù)據(jù)，利用 CAS 嘗試寫(xiě)入，失敗則自旋保證成功

• 如果當(dāng)前位置的 hashcode == MOVED == -1,則需要進(jìn)行擴(kuò)容

• 如果都不滿足，則利用 synchronized 鎖寫(xiě)入數(shù)據(jù)

• 如果數(shù)量大于 TREEIFY_THRESHOLD 則要轉(zhuǎn)換為紅黑樹(shù)

get 過(guò)程

• 根據(jù)計(jì)算出來(lái)的 hashcode 尋址，如果就在桶上那么直接返回值

• 如果是紅黑樹(shù)那就按照樹(shù)的方式獲取值

• 就不滿足那就按照鏈表的方式遍歷獲取值

此時(shí)躺著床上的張飛哄了一聲：睡覺(jué)了睡覺(jué)了~

見(jiàn)此不太妙：小魯班立馬回到床上把被子蓋過(guò)頭，心里有一絲絲愉悅感。不對(duì)，好像還沒(méi)洗澡……

by the way

ConcurrentHashMap 在 Java 8 中存在一個(gè) bug 會(huì)進(jìn)入死循環(huán)，原因是遞歸創(chuàng)建 ConcurrentHashMap 對(duì)象，但是在 JDK 1.9 已經(jīng)修復(fù)了。場(chǎng)景重現(xiàn)如下：

public class ConcurrentHashMapDemo{
? ?private Map<Integer,Integer> cache =new ConcurrentHashMap<>(15);

? ?public static void main(String[]args){
? ? ? ?ConcurrentHashMapDemo ch = ? ?new ConcurrentHashMapDemo();
? ? ? ?System.out.println(ch.fibonaacci(80)); ? ? ? ?
? ?}

? ?public int fibonaacci(Integer i){ ? ? ? ?
? ? ? ?if(i==0||i ==1) { ? ? ? ? ? ? ? ?
? ? ? ? ? ?return i; ? ? ? ?
? ? ? ?}

? ? ? ?return cache.computeIfAbsent(i,(key) -> {
? ? ? ? ? ?System.out.println("fibonaacci : "+key);
? ? ? ? ? ?return fibonaacci(key -1)+fibonaacci(key - 2); ? ? ? ?
? ? ? ?}); ? ? ?
? ?}
}

（完）

Java團(tuán)長(zhǎng)

專注于Java干貨分享

掃描上方二維碼獲取更多Java干貨

總結(jié)

以上是生活随笔為你收集整理的HashMap？面试？我是谁？我在哪？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。