摘要：發(fā)生了線程不安全情況。本來在中，發(fā)生哈希沖突是可以用鏈表法或者紅黑樹來解決的，但是在多線程中，可能就直接給覆蓋了。中，當(dāng)同一個(gè)值上元素的鏈表節(jié)點(diǎn)數(shù)不小于時(shí)，將不再以單鏈表的形式存儲(chǔ)了，會(huì)被調(diào)整成一顆紅黑樹。

List 和 Set 的區(qū)別

List , Set 都是繼承自 Collection 接口 List 特點(diǎn)：元素有放入順序，元素可重復(fù) ，

Set 特點(diǎn)：元素?zé)o放入順序，元素不可重復(fù)，重復(fù)元素會(huì)覆蓋掉，（元素雖然無放入順序，但是元素在set中的位 置是有該元素的 HashCode 決定的，其位置其實(shí)是固定的，加入Set 的 Object 必須定義 equals ()方法 ，另外list 支持for循環(huán)，也就是通過下標(biāo)來遍歷，也可以用迭代器，但是set只能用迭代，因?yàn)樗麩o序，無法用下標(biāo)來取得想 要的值。） Set和List對(duì)比 Set：檢索元素效率低下，刪除和插入效率高，插入和刪除不會(huì)引起元素位置改變。

List：和數(shù)組類似，List可以動(dòng)態(tài)增長(zhǎng)，查找元素效率高，插入刪除元素效率低，因?yàn)闀?huì)引起其他元素位置改變

HashSet 是如何保證不重復(fù)的

向 HashSet 中 add ()元素時(shí)，判斷元素是否存在的依據(jù)，不僅要比較hash值，同時(shí)還要結(jié)合 equles 方法比較。 HashSet 中的 add ()方法會(huì)使用 HashMap 的 add ()方法。以下是 HashSet 部分源碼：

HashMap 的 key 是唯一的，由上面的代碼可以看出 HashSet 添加進(jìn)去的值就是作為 HashMap 的key。所以不會(huì) 重復(fù)（ HashMap 比較key是否相等是先比較 hashcode 在比較 equals ）。

HashMap 是線程安全的嗎，為什么不是線程安全的（最好畫圖說明多線程 環(huán)境下不安全）?

不是線程安全的；

如果有兩個(gè)線程A和B，都進(jìn)行插入數(shù)據(jù)，剛好這兩條不同的數(shù)據(jù)經(jīng)過哈希計(jì)算后得到的哈希碼是一樣的，且該位 置還沒有其他的數(shù)據(jù)。所以這兩個(gè)線程都會(huì)進(jìn)入我在上面標(biāo)記為1的代碼中。假設(shè)一種情況，線程A通過if判斷，該 位置沒有哈希沖突，進(jìn)入了if語句，還沒有進(jìn)行數(shù)據(jù)插入，這時(shí)候 CPU 就把資源讓給了線程B，線程A停在了if語句 里面，線程B判斷該位置沒有哈希沖突（線程A的數(shù)據(jù)還沒插入），也進(jìn)入了if語句，線程B執(zhí)行完后，輪到線程A執(zhí) 行，現(xiàn)在線程A直接在該位置插入而不用再判斷。這時(shí)候，你會(huì)發(fā)現(xiàn)線程A把線程B插入的數(shù)據(jù)給覆蓋了。發(fā)生了線 程不安全情況。本來在 HashMap 中，發(fā)生哈希沖突是可以用鏈表法或者紅黑樹來解決的，但是在多線程中，可能 就直接給覆蓋了。

上面所說的是一個(gè)圖來解釋可能更加直觀。如下面所示，兩個(gè)線程在同一個(gè)位置添加數(shù)據(jù)，后面添加的數(shù)據(jù)就覆蓋 住了前面添加的。

如果上述插入是插入到鏈表上，如兩個(gè)線程都在遍歷到最后一個(gè)節(jié)點(diǎn)，都要在最后添加一個(gè)數(shù)據(jù)，那么后面添加數(shù) 據(jù)的線程就會(huì)把前面添加的數(shù)據(jù)給覆蓋住。則

在擴(kuò)容的時(shí)候也可能會(huì)導(dǎo)致數(shù)據(jù)不一致，因?yàn)閿U(kuò)容是從一個(gè)數(shù)組拷貝到另外一個(gè)數(shù)組。

HashMap 的擴(kuò)容過程

當(dāng)向容器添加元素的時(shí)候，會(huì)判斷當(dāng)前容器的元素個(gè)數(shù)，如果大于等于閾值(知道這個(gè)閾字怎么念嗎？不念 fa 值， 念 yu 值四聲)---即當(dāng)前數(shù)組的長(zhǎng)度乘以加載因子的值的時(shí)候，就要自動(dòng)擴(kuò)容啦。

擴(kuò)容( resize )就是重新計(jì)算容量，向 HashMap 對(duì)象里不停的添加元素，而 HashMap 對(duì)象內(nèi)部的數(shù)組無法裝載更 多的元素時(shí)，對(duì)象就需要擴(kuò)大數(shù)組的長(zhǎng)度，以便能裝入更多的元素。當(dāng)然 Java 里的數(shù)組是無法自動(dòng)擴(kuò)容的，方法 是使用一個(gè)新的數(shù)組代替已有的容量小的數(shù)組，就像我們用一個(gè)小桶裝水，如果想裝更多的水，就得換大水桶。

HashMap hashMap=new HashMap(cap);
cap =3， hashMap 的容量為4；

cap =4， hashMap 的容量為4；

cap =5， hashMap 的容量為8；

cap =9， hashMap 的容量為16；

如果 cap 是2的n次方，則容量為 cap ，否則為大于 cap 的第一個(gè)2的n次方的數(shù)。

HashMap 1.7 與 1.8 的 區(qū)別，說明 1.8 做了哪些優(yōu)化，如何優(yōu)化的？

HashMap結(jié)構(gòu)圖

在 JDK1.7 及之前的版本中， HashMap 又叫散列鏈表：基于一個(gè)數(shù)組以及多個(gè)鏈表的實(shí)現(xiàn)，hash值沖突的時(shí)候， 就將對(duì)應(yīng)節(jié)點(diǎn)以鏈表的形式存儲(chǔ)。

JDK1.8 中，當(dāng)同一個(gè)hash值（ Table 上元素）的鏈表節(jié)點(diǎn)數(shù)不小于8時(shí)，將不再以單鏈表的形式存儲(chǔ)了，會(huì)被 調(diào)整成一顆紅黑樹。這就是 JDK7 與 JDK8 中 HashMap 實(shí)現(xiàn)的最大區(qū)別。

其下基于 JDK1.7.0_80 與 JDK1.8.0_66 做的分析

JDK1.7中

使用一個(gè) Entry 數(shù)組來存儲(chǔ)數(shù)據(jù)，用key的 hashcode 取模來決定key會(huì)被放到數(shù)組里的位置，如果 hashcode 相 同，或者 hashcode 取模后的結(jié)果相同（ hash collision ），那么這些 key 會(huì)被定位到 Entry 數(shù)組的同一個(gè) 格子里，這些 key 會(huì)形成一個(gè)鏈表。

在 hashcode 特別差的情況下，比方說所有key的 hashcode 都相同，這個(gè)鏈表可能會(huì)很長(zhǎng)，那么 put/get 操作 都可能需要遍歷這個(gè)鏈表，也就是說時(shí)間復(fù)雜度在最差情況下會(huì)退化到 O(n)

JDK1.8中

使用一個(gè) Node 數(shù)組來存儲(chǔ)數(shù)據(jù)，但這個(gè) Node 可能是鏈表結(jié)構(gòu)，也可能是紅黑樹結(jié)構(gòu)

如果插入的 key 的 hashcode 相同，那么這些key也會(huì)被定位到 Node 數(shù)組的同一個(gè)格子里。

如果同一個(gè)格子里的key不超過8個(gè)，使用鏈表結(jié)構(gòu)存儲(chǔ)。

如果超過了8個(gè)，那么會(huì)調(diào)用 treeifyBin 函數(shù)，將鏈表轉(zhuǎn)換為紅黑樹。

那么即使 hashcode 完全相同，由于紅黑樹的特點(diǎn)，查找某個(gè)特定元素，也只需要O(log n)的開銷

也就是說put/get的操作的時(shí)間復(fù)雜度最差只有 O(log n) 聽起來挺不錯(cuò)，但是真正想要利用 JDK1.8 的好處，有一個(gè)限制： key的對(duì)象，必須正確的實(shí)現(xiàn)了 Compare 接口 如果沒有實(shí)現(xiàn) Compare 接口，或者實(shí)現(xiàn)得不正確（比方說所有 Compare 方法都返回0） 那 JDK1.8 的 HashMap 其實(shí)還是慢于 JDK1.7 的

簡(jiǎn)單的測(cè)試數(shù)據(jù)如下：

向 HashMap 中 put/get 1w 條 hashcode 相同的對(duì)象 JDK1.7: put 0.26s ， get 0.55s JDK1.8 （未實(shí)現(xiàn) Compare 接口）： put 0.92s ， get 2.1s 但是如果正確的實(shí)現(xiàn)了 Compare 接口，那么 JDK1.8 中的 HashMap 的性能有巨大提升，這次 put/get 100W條 hashcode 相同的對(duì)象 JDK1.8 （正確實(shí)現(xiàn) Compare 接口，）： put/get 大概開銷都在320 ms 左右

final finally finalize final

可以修飾類、變量、方法，修飾類表示該類不能被繼承、修飾方法表示該方法不能被重寫、修飾變量表 示該變量是一個(gè)常量不能被重新賦值。

finally一般作用在try-catch代碼塊中，在處理異常的時(shí)候，通常我們將一定要執(zhí)行的代碼方法finally代碼塊 中，表示不管是否出現(xiàn)異常，該代碼塊都會(huì)執(zhí)行，一般用來存放一些關(guān)閉資源的代碼。

finalize是一個(gè)方法，屬于Object類的一個(gè)方法，而Object類是所有類的父類，該方法一般由垃圾回收器來調(diào) 用，當(dāng)我們調(diào)用 System.gc() 方法的時(shí)候，由垃圾回收器調(diào)用finalize()，回收垃圾，一個(gè)對(duì)象是否可回收的 最后判斷。

感謝你耐心看完了文章…

關(guān)注作者，我會(huì)不定期在思否分享Java，Spring，MyBatis，Redis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)，BATJ面試 等資料…