1)ConcurrentHashMap對整個桶數(shù)組進行了分割分段(Segment)，然后在每一個分段上都用lock鎖進行保護，相對于HashTable的synchronized鎖的粒度更精細(xì)了一些，并發(fā)性能更好，而HashMap沒有鎖機制，不是線程安全的。（JDK1.8之后ConcurrentHashMap啟用了一種全新的方式實現(xiàn),利用CAS算法。）
2)HashMap的鍵值對允許有null，但是ConCurrentHashMap都不允許。
ConcurrentHashMap 結(jié)合了 HashMap 和 HashTable 二者的優(yōu)勢。HashMap 沒有考慮同步，HashTable 考慮了同步的問題。但是 HashTable 在每次同步執(zhí)行時都要鎖住整個結(jié)構(gòu)。ConcurrentHashMap 鎖的方式是稍微細(xì)粒度的。ConcurrentHashMap 和 Hashtable 的區(qū)別主要體現(xiàn)在實現(xiàn)線程安全的方式上不同。
底層數(shù)據(jù)結(jié)構(gòu)：JDK1.7的 ConcurrentHashMap 底層采用 分段的數(shù)組+鏈表 實現(xiàn)，JDK1.8 采用的數(shù)據(jù)結(jié)構(gòu)跟HashMap1.8的結(jié)構(gòu)一樣，數(shù)組+鏈表/紅黑二叉樹。Hashtable 和 JDK1.8 之前的 HashMap 的底層數(shù)據(jù)結(jié)構(gòu)類似都是采用 數(shù)組+鏈表 的形式，數(shù)組是 HashMap 的主體，鏈表則是主要為了解決哈希沖突而存在的；
實現(xiàn)線程安全的方式（重要）：① 在JDK1.7的時候，ConcurrentHashMap（分段鎖） 對整個桶數(shù)組進行了分割分段(Segment)，每一把鎖只鎖容器其中一部分?jǐn)?shù)據(jù)，多線程訪問容器里不同數(shù)據(jù)段的數(shù)據(jù)，就不會存在鎖競爭，提高并發(fā)訪問率。（默認(rèn)分配16個Segment，比Hashtable效率提高16倍。） 到了 JDK1.8 的時候已經(jīng)摒棄了Segment的概念，而是直接用 Node 數(shù)組+鏈表+紅黑樹的數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)，并發(fā)控制使用 synchronized 和 CAS 來操作。（JDK1.6以后 對 synchronized鎖做了很多優(yōu)化） 整個看起來就像是優(yōu)化過且線程安全的 HashMap，雖然在JDK1.8中還能看到 Segment 的數(shù)據(jù)結(jié)構(gòu)，但是已經(jīng)簡化了屬性，只是為了兼容舊版本；② Hashtable(同一把鎖) :使用 synchronized 來保證線程安全，效率非常低下。當(dāng)一個線程訪問同步方法時，其他線程也訪問同步方法，可能會進入阻塞或輪詢狀態(tài)，如使用 put 添加元素，另一個線程不能使用 put 添加元素，也不能使用 get，競爭會越來越激烈效率越低。
程序運行時能夠同時更新ConccurentHashMap且不產(chǎn)生鎖競爭的最大線程數(shù)。默認(rèn)為16,且可以在構(gòu)造函數(shù)中設(shè)置。當(dāng)用戶設(shè)置并發(fā)度時,ConcurrentHashMap會使用大于等于該值的最小2冪指數(shù)作為實際并發(fā)度(假如用戶設(shè)置并發(fā)度為17,實際并發(fā)度則為32)。
不行，如果key或者value為null會拋出空指針異常。
jdk1.7：Segment+HashEntry來進行實現(xiàn)的；
jdk1.8：放棄了Segment臃腫的設(shè)計，采用Node+CAS+Synchronized來保證線程安全；
不需要，get方法采用了unsafe方法，來保證線程安全。
HashTable : 使用了synchronized關(guān)鍵字對put等操作進行加鎖;
ConcurrentHashMap JDK1.7: 使用分段鎖機制實現(xiàn);
ConcurrentHashMap JDK1.8: 則使用數(shù)組+鏈表+紅黑樹數(shù)據(jù)結(jié)構(gòu)和CAS原子操作實現(xiàn);
官方微信
官方抖音
京公網(wǎng)安備 11030102010736號