HashMap的31連環(huán)炮，我倒在第5個(gè)上
關(guān)注“Java后端技術(shù)全棧”
回復(fù)“000”獲取大量電子書(shū)
寫(xiě)在前面
在面試中，HashMap基本必問(wèn)，只是問(wèn)法各有不同而已。曾經(jīng)我也和很多面試官聊過(guò)關(guān)于HashMap的話題，使用HashMap就能考察面試者的很多知識(shí)點(diǎn)。不幸的是，很大部分人都拜倒在HashMap的石榴裙底下
。
HashMap為什么如此受面試官青睞？
我覺(jué)得其中有4個(gè)原因：
HashMap在我們工作中使用頻率相當(dāng)高。 Java基礎(chǔ)（可以通過(guò)此Java集合） 線程安全問(wèn)題（可以通過(guò)這個(gè)問(wèn)題引入多線程并發(fā)編程的相關(guān)問(wèn)題） 大廠都在問(wèn)，豈能不問(wèn)？（不問(wèn)的話，顯得面試官?zèng)]有水平 
）
下面就是我給大家準(zhǔn)備的HashMap連環(huán)炮，這個(gè)連環(huán)炮就相當(dāng)于高考真題演練一樣，可能沒(méi)有完全一樣的，只是問(wèn)法不同罷了，這個(gè)主要得益于咱們漢語(yǔ)博大精深。
下面是HashMap的25連環(huán)炮：
1：說(shuō)說(shuō)HashMap 底層數(shù)據(jù)結(jié)構(gòu)是怎樣的？
2：談一下HashMap的特性？
3：使用HashMap時(shí)，當(dāng)兩個(gè)對(duì)象的 hashCode 相同怎么辦？
4：HashMap 的哈希函數(shù)怎么設(shè)計(jì)的嗎？
5：HashMap遍歷方法有幾種？
6：為什么采用 hashcode 的高 16 位和低 16 位異或能降低 hash 碰撞？hash 函數(shù)能不能直接用 key 的 hashcode？
7：解決hash沖突的有幾種方法？
8：為什么要用異或運(yùn)算符？
9.：HashMap 的 table 的容量如何確定？
10：請(qǐng)解釋一下HashMap的參數(shù)loadFactor，它的作用是什么
11：說(shuō)說(shuō)HashMap中put方法的過(guò)程
12：當(dāng)鏈表長(zhǎng)度 >= 8時(shí)，為什么要將鏈表轉(zhuǎn)換成紅黑樹(shù)？
13：new HashMap(18);此時(shí)HashMap初始容量為多少？
14：說(shuō)說(shuō)resize擴(kuò)容的過(guò)程
15：說(shuō)說(shuō)hashMap中g(shù)et是如何實(shí)現(xiàn)的？
16：拉鏈法導(dǎo)致的鏈表過(guò)深問(wèn)題為什么不用二叉查找樹(shù)代替，而選擇紅黑樹(shù)？為什么不一直使用紅黑樹(shù)？
17：說(shuō)說(shuō)你對(duì)紅黑樹(shù)的了解
18：JDK8中對(duì)HashMap做了哪些改變？
19：HashMap 中的 key 我們可以使用任何類(lèi)作為 key 嗎？
20：HashMap 的長(zhǎng)度為什么是 2 的 N 次方呢？
21：HashMap，LinkedHashMap，TreeMap 有什么區(qū)別？
22：說(shuō)說(shuō)什么是 fail-fast？
23：HashMap 和 HashTable 有什么區(qū)別？
24：HashMap 是線程安全的嗎？
25：如何規(guī)避 HashMap 的線程不安全？
26：HashMap 和 ConcurrentHashMap 的區(qū)別？
27：為什么 ConcurrentHashMap 比 HashTable 效率要高？
28：說(shuō)說(shuō) ConcurrentHashMap中 鎖機(jī)制
29：在 JDK 1.8 中，ConcurrentHashMap 為什么要使用內(nèi)置鎖 synchronized 來(lái)代替重入鎖 ReentrantLock？
30：能對(duì)ConcurrentHashMap 做個(gè)簡(jiǎn)單介紹嗎？
31：熟悉ConcurrentHashMap 的并發(fā)度嗎？
....
java集合知識(shí)總結(jié)
（需要思維導(dǎo)圖的，請(qǐng)加我微信tj20120622，免費(fèi)贈(zèng)予）
下面我們正式開(kāi)始連環(huán)炮
1、說(shuō)說(shuō)HashMap 底層數(shù)據(jù)結(jié)構(gòu)是怎樣的？
HashMap 底層是 hash 數(shù)組和單向鏈表實(shí)現(xiàn)，jdk8后采用數(shù)組+鏈表+紅黑樹(shù)的數(shù)據(jù)結(jié)構(gòu)。
2、說(shuō)說(shuō)HashMap 的工作原理
如果第一題沒(méi)問(wèn)，直接問(wèn)原理，那就必須把HashMap的數(shù)據(jù)結(jié)構(gòu)說(shuō)清楚。
HashMap 底層是 hash 數(shù)組和單向鏈表實(shí)現(xiàn)，JDK8后采用數(shù)組+鏈表+紅黑樹(shù)的數(shù)據(jù)結(jié)構(gòu)。
我們通過(guò)put和get存儲(chǔ)和獲取對(duì)象。當(dāng)我們給put()方法傳遞鍵和值時(shí)，先對(duì)鍵做一個(gè)hashCode()的計(jì)算來(lái)得到它在bucket數(shù)組中的位置來(lái)存儲(chǔ)Entry對(duì)象。當(dāng)獲取對(duì)象時(shí)，通過(guò)get獲取到bucket的位置，再通過(guò)鍵對(duì)象的equals()方法找到正確的鍵值對(duì)，然后在返回值對(duì)象。
3、使用HashMap時(shí)，當(dāng)兩個(gè)對(duì)象的 hashCode 相同怎么辦？
因?yàn)镠ashCode 相同，不一定就是相等的（equals方法比較），所以?xún)蓚€(gè)對(duì)象所在數(shù)組的下標(biāo)相同，"碰撞"就此發(fā)生。又因?yàn)?HashMap 使用鏈表存儲(chǔ)對(duì)象，這個(gè) Node 會(huì)存儲(chǔ)到鏈表中。
4、HashMap 的哈希函數(shù)怎么設(shè)計(jì)的嗎？
hash 函數(shù)是先拿到通過(guò) key 的 hashCode ，是 32 位的 int 值，然后讓 hashCode 的高 16 位和低 16 位進(jìn)行異或操作。兩個(gè)好處：
一定要盡可能降低 hash 碰撞，越分散越好； 算法一定要盡可能高效，因?yàn)檫@是高頻操作, 因此采用位運(yùn)算；
5、HashMap遍歷方法有幾種？
Iterator 迭代器 最常見(jiàn)的使用方式，可同時(shí)得到 key、value 值 使用 foreach 方式（JDK1.8 才有） 通過(guò) key 的 set 集合遍歷
6、為什么采用 hashcode 的高 16 位和低 16 位異或能降低 hash 碰撞？
因?yàn)?key.hashCode()函數(shù)調(diào)用的是 key 鍵值類(lèi)型自帶的哈希函數(shù)，返回 int 型散列值。int 值范圍為**-2147483648~2147483647**，前后加起來(lái)大概 40 億的映射空間。只要哈希函數(shù)映射得比較均勻松散，一般應(yīng)用是很難出現(xiàn)碰撞的。但問(wèn)題是一個(gè) 40 億長(zhǎng)度的數(shù)組，內(nèi)存是放不下的。
設(shè)想，如果 HashMap 數(shù)組的初始大小才 16，用之前需要對(duì)數(shù)組的長(zhǎng)度取模運(yùn)算，得到的余數(shù)才能用來(lái)訪問(wèn)數(shù)組下標(biāo)。
7、解決hash沖突的有幾種方法？
比較浪費(fèi)空間，消耗效率。根本原因還是數(shù)組的長(zhǎng)度是固定不變的，不斷hash找出空的index，可能越界，這時(shí)就要?jiǎng)?chuàng)建新數(shù)組，而老數(shù)組的數(shù)據(jù)也需要遷移。隨著數(shù)組越來(lái)越大，消耗不可小覷。 get不到，或者說(shuō)get算法復(fù)雜。進(jìn)是進(jìn)去了，想出來(lái)就沒(méi)那么容易了。
8、為什么要用異或運(yùn)算符？
保證了對(duì)象的 hashCode 的 32 位值只要有一位發(fā)生改變，整個(gè) hash() 返回值就會(huì)改變。盡可能的減少碰撞。
9、HashMap 的 table 的容量如何確定？
①、table 數(shù)組大小是由 capacity 這個(gè)參數(shù)確定的，默認(rèn)是16，也可以構(gòu)造時(shí)傳入，最大限制是1<<30；
②、loadFactor 是裝載因子，主要目的是用來(lái)確認(rèn)table 數(shù)組是否需要?jiǎng)討B(tài)擴(kuò)展，默認(rèn)值是0.75，比如table 數(shù)組大小為 16，裝載因子為 0.75 時(shí)，threshold 就是12，當(dāng) table 的實(shí)際大小超過(guò) 12 時(shí)，table就需要?jiǎng)討B(tài)擴(kuò)容；
③、擴(kuò)容時(shí)，調(diào)用 resize() 方法，將 table 長(zhǎng)度變?yōu)樵瓉?lái)的兩倍（注意是 table 長(zhǎng)度，而不是 threshold）；
④、如果數(shù)據(jù)很大的情況下，擴(kuò)展時(shí)將會(huì)帶來(lái)性能的損失，在性能要求很高的地方，這種損失很可能很致命。
10、請(qǐng)解釋一下HashMap的參數(shù)loadFactor，它的作用是什么
loadFactor表示HashMap的擁擠程度，影響hash操作到同一個(gè)數(shù)組位置的概率。
默認(rèn)loadFactor等于0.75，當(dāng)HashMap里面容納的元素已經(jīng)達(dá)到HashMap數(shù)組長(zhǎng)度的75%時(shí)，表示HashMap太擠了，需要擴(kuò)容，在HashMap的構(gòu)造器中可以定制loadFactor。
11、說(shuō)說(shuō)HashMap中put方法的過(guò)程
由于JDK版本中HashMap設(shè)計(jì)上存在差異，這里說(shuō)說(shuō)JDK7和JDK8中的區(qū)別：
具體put流程，請(qǐng)參照下圖進(jìn)行回答：
12、當(dāng)鏈表長(zhǎng)度 >= 8時(shí)，為什么要將鏈表轉(zhuǎn)換成紅黑樹(shù)？
因?yàn)榧t黑樹(shù)的平均查找長(zhǎng)度是log(n)，長(zhǎng)度為8的時(shí)候，平均查找長(zhǎng)度為3，如果繼續(xù)使用鏈表，平均查找長(zhǎng)度為8/2=4，所以，當(dāng)鏈表長(zhǎng)度 >= 8時(shí) ，有必要將鏈表轉(zhuǎn)換成紅黑樹(shù)。
13、new HashMap(18);此時(shí)HashMap初始容量為多少？
容量為32。
在HashMap中有個(gè)靜態(tài)方法tableSizeFor ，tableSizeFor方法保證函數(shù)返回值是大于等于給定參數(shù)initialCapacity最小的2的冪次方的數(shù)值 。
static final int tableSizeFor(int cap) {
int n = cap - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n = MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}
14、說(shuō)說(shuō)resize擴(kuò)容的過(guò)程
創(chuàng)建一個(gè)新的數(shù)組，其容量為舊數(shù)組的兩倍，并重新計(jì)算舊數(shù)組中結(jié)點(diǎn)的存儲(chǔ)位置。結(jié)點(diǎn)在新數(shù)組中的位置只有兩種，原下標(biāo)位置或原下標(biāo)+舊數(shù)組的大小。
15、說(shuō)說(shuō)hashMap中g(shù)et是如何實(shí)現(xiàn)的？
對(duì)key的hashCode進(jìn)行hash值計(jì)算，與運(yùn)算計(jì)算下標(biāo)獲取bucket位置，如果在桶的首位上就可以找到就直接返回，否則在樹(shù)中找或者鏈表中遍歷找，如果有hash沖突，則利用equals方法去遍歷鏈表查找節(jié)點(diǎn)。
16、拉鏈法導(dǎo)致的鏈表過(guò)深問(wèn)題為什么不用二叉查找樹(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ù)快，解決鏈表查詢(xún)深度的問(wèn)題，我們知道紅黑樹(shù)屬于平衡二叉樹(shù)，但是為了保持“平衡”是需要付出代價(jià)的，但是該代價(jià)所損耗的資源要比遍歷線性鏈表要少，所以當(dāng)長(zhǎng)度大于8的時(shí)候，會(huì)使用紅黑樹(shù)，如果鏈表長(zhǎng)度很短的話，根本不需要引入紅黑樹(shù)，引入反而會(huì)慢。
17、說(shuō)說(shuō)你對(duì)紅黑樹(shù)的了解
紅黑樹(shù)是一種自平衡的二叉查找樹(shù)，是一種高效的查找樹(shù)。
紅黑樹(shù)通過(guò)如下的性質(zhì)定義實(shí)現(xiàn)自平衡：
節(jié)點(diǎn)是紅色或黑色。 根是黑色。 所有葉子都是黑色（葉子是NIL節(jié)點(diǎn)）。 每個(gè)紅色節(jié)點(diǎn)必須有兩個(gè)黑色的子節(jié)點(diǎn)。（從每個(gè)葉子到根的所有路徑上不能有兩個(gè)連續(xù)的紅色節(jié)點(diǎn)。） 從任一節(jié)點(diǎn)到其每個(gè)葉子的所有簡(jiǎn)單路徑都包含相同數(shù)目的黑色節(jié)點(diǎn)（簡(jiǎn)稱(chēng)黑高）。
18、JDK8中對(duì)HashMap做了哪些改變？
1.在java 1.8中，如果鏈表的長(zhǎng)度超過(guò)了8，那么鏈表將轉(zhuǎn)換為紅黑樹(shù)。（桶的數(shù)量必須大于64，小于64的時(shí)候只會(huì)擴(kuò)容）
2.發(fā)生hash碰撞時(shí)，java 1.7 會(huì)在鏈表的頭部插入，而java 1.8會(huì)在鏈表的尾部插入
3.在java 1.8中，Entry被Node替代(換了一個(gè)馬甲)。
19、HashMap 中的 key 我們可以使用任何類(lèi)作為 key 嗎？
平時(shí)可能大家使用的最多的就是使用 String 作為 HashMap 的 key，但是現(xiàn)在我們想使用某個(gè)自定 義類(lèi)作為 HashMap 的 key，那就需要注意以下幾點(diǎn)：
如果類(lèi)重寫(xiě)了 equals 方法，它也應(yīng)該重寫(xiě) hashCode 方法。
類(lèi)的所有實(shí)例需要遵循與 equals 和 hashCode 相關(guān)的規(guī)則。
如果一個(gè)類(lèi)沒(méi)有使用 equals，你不應(yīng)該在 hashCode 中使用它。
咱們自定義 key 類(lèi)的最佳實(shí)踐是使之為不可變的，這樣，hashCode 值可以被緩存起來(lái)，擁有
更好的性能。不可變的類(lèi)也可以確保 hashCode 和 equals 在未來(lái)不會(huì)改變，這樣就會(huì)解決與可變相關(guān)的問(wèn)題了。
20、HashMap 的長(zhǎng)度為什么是 2 的 N 次方呢？
為了能讓 HashMap 存數(shù)據(jù)和取數(shù)據(jù)的效率高，盡可能地減少 hash 值的碰撞，也就是說(shuō)盡量把數(shù) 據(jù)能均勻的分配，每個(gè)鏈表或者紅黑樹(shù)長(zhǎng)度盡量相等。我們首先可能會(huì)想到 % 取模的操作來(lái)實(shí)現(xiàn)。下面是回答的重點(diǎn)喲：
取余（%）操作中如果除數(shù)是 2 的冪次，則等價(jià)于與其除數(shù)減一的與（&）操作（也就是說(shuō) hash % length == hash &(length - 1) 的前提是 length 是 2 的 n 次方）。并且，采用二進(jìn) 制位操作 & ，相對(duì)于 % 能夠提高運(yùn)算效率。
這就是為什么 HashMap 的長(zhǎng)度需要 2 的 N 次方了。
21、HashMap，LinkedHashMap，TreeMap 有什么區(qū)別？
LinkedHashMap是繼承于HashMap，是基于HashMap和雙向鏈表來(lái)實(shí)現(xiàn)的。 HashMap無(wú)序；LinkedHashMap有序，可分為插入順序和訪問(wèn)順序兩種。如果是訪問(wèn)順序，那put和get操作已存在的Entry時(shí)，都會(huì)把Entry移動(dòng)到雙向鏈表的表尾(其實(shí)是先刪除再插入)。 LinkedHashMap存取數(shù)據(jù)，還是跟HashMap一樣使用的Entry[]的方式，雙向鏈表只是為了保證順序。 LinkedHashMap是線程不安全的。
22、說(shuō)說(shuō)什么是 fail-fast？
fail-fast 機(jī)制是 Java 集合（Collection）中的一種錯(cuò)誤機(jī)制。當(dāng)多個(gè)線程對(duì)同一個(gè)集合的內(nèi)容進(jìn)行 操作時(shí)，就可能會(huì)產(chǎn)生 fail-fast 事件。
例如：當(dāng)某一個(gè)線程 A 通過(guò) iterator 去遍歷某集合的過(guò)程中，若該集合的內(nèi)容被其他線程所改變 了，那么線程 A 訪問(wèn)集合時(shí)，就會(huì)拋出 ConcurrentModificationException 異常，產(chǎn)生 fail-fast 事 件。這里的操作主要是指 add、remove 和 clear，對(duì)集合元素個(gè)數(shù)進(jìn)行修改。
解決辦法
建議使用“java.util.concurrent 包下的類(lèi)”去取代“java.util 包下的類(lèi)”?？梢赃@么理解：在遍歷之前，把 modCount 記下來(lái) expectModCount，后面 expectModCount 去 和 modCount 進(jìn)行比較，如果不相等了，證明已并發(fā)了，被修改了，于是拋出 ConcurrentModificationException 異常。
23、HashMap 和 HashTable 有什么區(qū)別？
①、HashMap 是線程不安全的，HashTable 是線程安全的；
②、由于線程安全，所以 HashTable 的效率比不上 HashMap；
③、HashMap最多只允許一條記錄的鍵為null，允許多條記錄的值為null，而 HashTable不允許；
④、HashMap 默認(rèn)初始化數(shù)組的大小為16，HashTable 為 11，前者擴(kuò)容時(shí)，擴(kuò)大兩倍，后者擴(kuò)大兩倍+1；
⑤、HashMap 需要重新計(jì)算 hash 值，而 HashTable 直接使用對(duì)象的 hashCode；
24、HashMap 是線程安全的嗎？
不是，在多線程環(huán)境下，1.7 會(huì)產(chǎn)生死循環(huán)、數(shù)據(jù)丟失、數(shù)據(jù)覆蓋的問(wèn)題，1.8 中會(huì)有數(shù)據(jù)覆蓋的問(wèn)題，以 1.8 為例，當(dāng) A 線程判斷 index 位置為空后正好掛起，B 線程開(kāi)始往 index 位置的寫(xiě)入節(jié)點(diǎn)數(shù)據(jù)，這時(shí) A 線程恢復(fù)現(xiàn)場(chǎng)，執(zhí)行賦值操作，就把 A 線程的數(shù)據(jù)給覆蓋了；還有++size 這個(gè)地方也會(huì)造成多線程同時(shí)擴(kuò)容等問(wèn)題。
25、如何規(guī)避 HashMap 的線程不安全？
單線程條件下，為避免出現(xiàn)ConcurrentModificationException，需要保證只通過(guò)HashMap本身或者只通過(guò)Iterator去修改數(shù)據(jù)，不能在Iterator使用結(jié)束之前使用HashMap本身的方法修改數(shù)據(jù)。因?yàn)橥ㄟ^(guò)Iterator刪除數(shù)據(jù)時(shí)，HashMap的modCount和Iterator的expectedModCount都會(huì)自增，不影響二者的相等性。如果是增加數(shù)據(jù)，只能通過(guò)HashMap本身的方法完成，此時(shí)如果要繼續(xù)遍歷數(shù)據(jù)，需要重新調(diào)用iterator()方法從而重新構(gòu)造出一個(gè)新的Iterator，使得新Iterator的expectedModCount與更新后的HashMap的modCount相等。
多線程條件下，可使用兩種方式：
Collections.synchronizedMap方法構(gòu)造出一個(gè)同步Map 直接使用線程安全的ConcurrentHashMap。
26、HashMap 和 ConcurrentHashMap 的區(qū)別？
都是 key-value 形式的存儲(chǔ)數(shù)據(jù)；
HashMap 是線程不安全的，ConcurrentHashMap 是 JUC 下的線程安全的；
HashMap 底層數(shù)據(jù)結(jié)構(gòu)是數(shù)組 + 鏈表（JDK 1.8 之前）。JDK 1.8 之后是數(shù)組 + 鏈表 + 紅黑 樹(shù)。當(dāng)鏈表中元素個(gè)數(shù)達(dá)到 8 的時(shí)候，鏈表的查詢(xún)速度不如紅黑樹(shù)快，鏈表會(huì)轉(zhuǎn)為紅黑樹(shù)，紅 黑樹(shù)查詢(xún)速度快；
HashMap 初始數(shù)組大小為 16（默認(rèn)），當(dāng)出現(xiàn)擴(kuò)容的時(shí)候，以 0.75 * 數(shù)組大小的方式進(jìn)行擴(kuò) 容；
ConcurrentHashMap 在 JDK 1.8 之前是采用分段鎖來(lái)現(xiàn)實(shí)的 Segment + HashEntry， Segment 數(shù)組大小默認(rèn)是 16，2 的 n 次方；JDK 1.8 之后，采用 Node + CAS + Synchronized 來(lái)保證并發(fā)安全進(jìn)行實(shí)現(xiàn)。
27、為什么 ConcurrentHashMap 比 HashTable 效率要高？
HashTable：使用一把鎖（鎖住整個(gè)鏈表結(jié)構(gòu)）處理并發(fā)問(wèn)題，多個(gè)線程競(jìng)爭(zhēng)一把鎖，容易阻塞；
ConcurrentHashMap：
JDK 1.7 中使用分段鎖（ ReentrantLock + Segment + HashEntry），相當(dāng)于把一個(gè) HashMap 分成多個(gè)段，每段分配一把鎖，這樣支持多線程訪問(wèn)。鎖粒度：基于 Segment，包含多個(gè) HashEntry。JDK 1.8 中使用 CAS + synchronized + Node + 紅黑樹(shù)。鎖粒度：Node（首結(jié)點(diǎn)）（實(shí)現(xiàn) Map.Entry<K,V>）。鎖粒度降低了。
28、說(shuō)說(shuō) ConcurrentHashMap中 鎖機(jī)制
JDK 1.7 中，采用分段鎖的機(jī)制，實(shí)現(xiàn)并發(fā)的更新操作，底層采用數(shù)組+鏈表的存儲(chǔ)結(jié)構(gòu)，包括兩個(gè)核心靜態(tài)內(nèi)部類(lèi) Segment 和 HashEntry。
①、Segment 繼承 ReentrantLock（重入鎖） 用來(lái)充當(dāng)鎖的角色，每個(gè) Segment 對(duì)象守護(hù)每個(gè)散列映射表的若干個(gè)桶；
②、HashEntry 用來(lái)封裝映射表的鍵-值對(duì)；
③、每個(gè)桶是由若干個(gè) HashEntry 對(duì)象鏈接起來(lái)的鏈表
JDK 1.8 中，采用Node + CAS + Synchronized來(lái)保證并發(fā)安全。取消類(lèi) Segment，直接用 table 數(shù)組存儲(chǔ)鍵值對(duì)；當(dāng) HashEntry 對(duì)象組成的鏈表長(zhǎng)度超過(guò) TREEIFY_THRESHOLD 時(shí)，鏈表轉(zhuǎn)換為紅黑樹(shù)，提升性能。底層變更為數(shù)組 + 鏈表 + 紅黑樹(shù)。
29、在 JDK 1.8 中，ConcurrentHashMap 為什么要使用內(nèi)置鎖 synchronized 來(lái)代替重入鎖 ReentrantLock？
①、粒度降低了；
②、JVM 開(kāi)發(fā)團(tuán)隊(duì)沒(méi)有放棄 synchronized，而且基于 JVM 的 synchronized 優(yōu)化空間更大，更加自然。
③、在大量的數(shù)據(jù)操作下，對(duì)于 JVM 的內(nèi)存壓力，基于 API 的 ReentrantLock 會(huì)開(kāi)銷(xiāo)更多的內(nèi)存。
30、能對(duì)ConcurrentHashMap 做個(gè)簡(jiǎn)單介紹嗎？
①、重要的常量：
private transient volatile int sizeCtl;
當(dāng)為負(fù)數(shù)時(shí)，-1 表示正在初始化，-N 表示 N - 1 個(gè)線程正在進(jìn)行擴(kuò)容；
當(dāng)為 0 時(shí)，表示 table 還沒(méi)有初始化；
當(dāng)為其他正數(shù)時(shí)，表示初始化或者下一次進(jìn)行擴(kuò)容的大小。
②、數(shù)據(jù)結(jié)構(gòu)：
Node 是存儲(chǔ)結(jié)構(gòu)的基本單元，繼承 HashMap 中的 Entry，用于存儲(chǔ)數(shù)據(jù)；
TreeNode 繼承 Node，但是數(shù)據(jù)結(jié)構(gòu)換成了二叉樹(shù)結(jié)構(gòu)，是紅黑樹(shù)的存儲(chǔ)結(jié)構(gòu)，用于紅黑樹(shù)中存儲(chǔ)數(shù)據(jù)；
TreeBin 是封裝 TreeNode 的容器，提供轉(zhuǎn)換紅黑樹(shù)的一些條件和鎖的控制。
③、存儲(chǔ)對(duì)象時(shí)（put() 方法）：
如果沒(méi)有初始化，就調(diào)用 initTable() 方法來(lái)進(jìn)行初始化；
如果沒(méi)有 hash 沖突就直接 CAS 無(wú)鎖插入；
如果需要擴(kuò)容，就先進(jìn)行擴(kuò)容；
如果存在 hash 沖突，就加鎖來(lái)保證線程安全，兩種情況：一種是鏈表形式就直接遍歷到尾端插入，一種是紅黑樹(shù)就按照紅黑樹(shù)結(jié)構(gòu)插入；
如果該鏈表的數(shù)量大于閥值 8，就要先轉(zhuǎn)換成紅黑樹(shù)的結(jié)構(gòu)，break 再一次進(jìn)入循環(huán)
如果添加成功就調(diào)用 addCount() 方法統(tǒng)計(jì) size，并且檢查是否需要擴(kuò)容。
④、擴(kuò)容方法 transfer()：默認(rèn)容量為 16，擴(kuò)容時(shí)，容量變?yōu)樵瓉?lái)的兩倍?！ elpTransfer()：調(diào)用多個(gè)工作線程一起幫助進(jìn)行擴(kuò)容，這樣的效率就會(huì)更高。
⑤、獲取對(duì)象時(shí)（get()方法）：
計(jì)算 hash 值，定位到該 table 索引位置，如果是首結(jié)點(diǎn)符合就返回；
如果遇到擴(kuò)容時(shí)，會(huì)調(diào)用標(biāo)記正在擴(kuò)容結(jié)點(diǎn) ForwardingNode.find()方法，查找該結(jié)點(diǎn)，匹配就返回；
以上都不符合的話，就往下遍歷結(jié)點(diǎn)，匹配就返回，否則最后就返回 null。
31、熟悉ConcurrentHashMap 的并發(fā)度嗎？
程序運(yùn)行時(shí)能夠同時(shí)更新 ConccurentHashMap 且不產(chǎn)生鎖競(jìng)爭(zhēng)的最大線程數(shù)。默認(rèn)為 16，且可以在構(gòu)造函數(shù)中設(shè)置。當(dāng)用戶(hù)設(shè)置并發(fā)度時(shí)，ConcurrentHashMap 會(huì)使用大于等于該值的最小2冪指數(shù)作為實(shí)際并發(fā)度（假如用戶(hù)設(shè)置并發(fā)度為17，實(shí)際并發(fā)度則為32）。
參考：http://ii081.cn/gFInl
總結(jié)
好了，就寫(xiě)這么多了，文章中很多已經(jīng)不是HashMap知識(shí)點(diǎn)了，但，面試很有可能會(huì)問(wèn)這些知識(shí)點(diǎn)，多準(zhǔn)備點(diǎn)也算是有備無(wú)患。
所謂天才，只不過(guò)是把別人喝咖啡的功夫都用在工作上了。
——魯迅
推薦閱讀：
數(shù)據(jù)庫(kù)跟緩存的雙寫(xiě)一致性
歡迎關(guān)注微信公眾號(hào)：互聯(lián)網(wǎng)全棧架構(gòu)，收取更多有價(jià)值的信息。