由於專案中常用的集合是hashmap和concurrenthashmap，hashmap的原始碼之前已經寫過 ，今天看下concurrenthashmap的訪問和兩者之間的一些比較。
concurrenthashmap(jdk1.7和1.8的變化)
在jdk1.7以及之前concurrenthashmap採用的是segment+hashentry的分段鎖策略進行設計的 ，segment繼承 了可重入鎖，在1.8中改變了這一設計 將hashentry改為和hashmap一樣的node節點 作為基本變數 還是陣列+鍊錶+紅黑樹的設計手法。
在這張 的注釋中可以看到 在乙個hash槽存放8個節點的可能性為小於百萬分之一，所以節點個數一般按7為分界線 將小於7(小於6退化為鍊錶)，大於等於8存放到紅黑樹中。
首先根據傳入的key進行hash運算找到對應的鍊錶節點或者說紅黑樹節點（都是用node存的） 對當前鍊錶節點進行判斷key，如果key和key'的hash運算都是相同的 ，那就說明是要替換掉這個值 如**中，直接將值進行更新，否則 將整個節點替換到當前節點的next。在此之前首先要先判斷是否要進行擴容 以為concurrenthasmap和hashmap一樣有載入因子和初始容量。
helptransfer這個方法是進行重組的方法 往裡看的話 再存入節點的迴圈中也對節點加了synchronized進行加鎖處理，保證併發狀態下的執行緒安全。 因為hashmap執行緒不安全也是因為存值的時候擴容有可能導致鍊錶的內迴圈。取值相對簡單 跟hashmap差別不大，讀取值不需要加鎖。
有個疑問是為什麼concurrenthashmap不使用lock進行加鎖 而是使用synchronized？
ConcurrentHashMap原始碼分析
hashmap 先說hashmap，hashmap是執行緒不安全 的，在併發環境下，可能會形成環狀鍊錶 hashtable hashtable和hashmap的實現原理幾乎一樣，差別無非是1.hashtable不允許key和value為null 2.hashtable是執行緒安全的。但是hashta...
ConcurrentHashMap原始碼詳解
成員變數private static final int maximum capacity 1 30 private static final int default capacity 16 static final int max array size integer.max value 8 pr...
concurrentHashMap原始碼分析
concurrenthashmap是hashmap的執行緒安全版本，內部也是使用 陣列 鍊錶 紅黑樹 的結構來儲存元素。相比於同樣執行緒安全的hashtable來說，效率等各方面都有極大地提高。在這裡可以使用上篇那個 進行測試,根據結果可以知道concurrenthashmap是執行緒安全的,由於分...