jdk 1.6 / 1.7 / 1.8 之HashMap & ConcurrentHashMap對(duì)比
HashMap
1.6
負(fù)載因子默認(rèn)0.75,默認(rèn)容量是16
當(dāng)容量使用占比>=(16*0.75)時(shí)宿刮，進(jìn)行擴(kuò)容（resize(2 * table.length)）
基于數(shù)組和鏈表實(shí)現(xiàn),hash碰撞時(shí)私蕾，會(huì)添加到鏈表中
key為null時(shí)，數(shù)據(jù)添加到數(shù)組索引0的位置
缺點(diǎn)：
1：hash碰撞多較多時(shí)磕潮，獲取數(shù)據(jù)會(huì)變慢
2：hash算法復(fù)雜
3：new HashMap時(shí)容贝，開辟了內(nèi)存空間，如果不使用膏潮，則浪費(fèi)內(nèi)存
1.7
同1.6基本沒太大差異满力，不過改成了懶漢初始化,意味著new HashMap并沒有開辟內(nèi)存空間
容量達(dá)到負(fù)載閥值時(shí)，會(huì)擴(kuò)容（resize(2 * table.length)）
1.8
相比1.7叠纷，進(jìn)一步優(yōu)化了new HashMap的過程
hash算法改為了XORs算法(x ^ (x>>>16))
擴(kuò)容算法改為ewThr = oldThr << 1
解決了hash碰撞較多情況下的性能問題(鏈表長度限制為8潦嘶，過長時(shí)請(qǐng)將鏈表轉(zhuǎn)換為TreeNode(紅黑樹))
鑒于hashMap擴(kuò)容問題，如果確定業(yè)務(wù)數(shù)據(jù)大于默認(rèn)負(fù)載時(shí)航厚，建議new HashMap時(shí)锰蓬，指定容量，防止擴(kuò)容時(shí)的性能損耗
ConcurrentHashMap
key & value都不允許為null，但是1.6/1.7沒做前置檢查
1.6
默認(rèn)容量16，負(fù)載因子0.75澈蚌，并發(fā)度16(相當(dāng)于數(shù)據(jù)分片),默認(rèn)構(gòu)造開辟了內(nèi)存空間
hash算法難看的一比灼狰，懶得去理解什么意思了
基于分片+鏈表數(shù)組結(jié)構(gòu)（分片竟然繼承了ReentrantLock，表示無奈）
根據(jù)hash值份汗，得到對(duì)應(yīng)的分片蝴簇，然后將值插入分片中
插入數(shù)據(jù)時(shí)，使用了父類的lock方法(可重入鎖)
不得不說ConcurrentHashMap的擴(kuò)容過程是相當(dāng)復(fù)雜,并且和HashMap一樣旁钧，碰撞比較多時(shí)互拾，影響性能
1.7
相比1.6，無大變化寄猩，但是數(shù)據(jù)存取依賴了UNSAFE
1.8
修正1.6/1.7骑疆，put數(shù)據(jù)時(shí)key為null沒有前置檢查的問題
hash算法采用XORs
丟棄了1.6/1.7中那個(gè)并發(fā)級(jí)別定義(concurrency level)，改用動(dòng)態(tài)分片
分片鎖采用synchronized,1.6/1.7都是可重入鎖
數(shù)據(jù)結(jié)構(gòu)構(gòu)造采用懶漢方法斯辰，避免new但不使用的內(nèi)存浪費(fèi)情況
分片(鏈表長度)大8時(shí)坡疼，采用TreeNode(紅黑樹)，提高檢索效率
最后的建議：如果用Map做緩存使用時(shí)闸氮，請(qǐng)注意擴(kuò)容問題教沾，盡量初始化指定大小，防止擴(kuò)容導(dǎo)致的性能問題
深夜碼字或悲，很累巡语，如有錯(cuò)誤請(qǐng)指正，不喜勿噴.
