### JDK1.7 ConcurrentHashMap結構 JDK1.7 ConcurrentHashMap 數據結構如下所示：  Segament 是一個ConcurrentHashMap內部類，底層結構與 HashMap 一致。另外Segament 繼承自 ReentrantLock。 當新元素加入 ConcurrentHashMap 時，首先根據 key hash 值找到相應的 Segament。接著直接對 Segament 上鎖，若獲取成功，后續操作步驟如同 HashMap。 由于鎖的存在，Segament 內部操作都是并發安全，同時由于其他 Segament 未被占用，因此可以支持 concurrencyLevel 個線程安全的并發讀寫 #### size統計問題 雖然 ConcurrentHashMap 引入分段鎖解決多線程并發的問題，但是同時引入新的復雜度，導致計算 ConcurrentHashMap 元素數量將會變得復雜。 由于 ConcurrentHashMap 元素實際分布在 Segament 中，為了統計實際數量，只能遍歷 Segament數組求和。 為了數據的準確性，這個過程過我們需要鎖住所有的 Segament，計算結束之后，再依次解鎖。不過這樣做，將會導致寫操作被阻塞，一定程度降低 ConcurrentHashMap性能。 所以這里對 ConcurrentHashMap#size 統計方法進行一定的優化。 Segment 每次被修改（寫入，刪除）,都會對 modCount（更新次數）加 1。只要相鄰兩次計算獲取所有的 Segment modCount 總和一致，則代表兩次計算過程并無寫入或刪除，可以直接返回統計數量。 如果三次計算結果都不一致，那沒辦法只能對所有 Segment 加鎖，重新計算結果。 這里需要注意的是，這里求得 size 數量不能做到 100% 準確。這是因為最后依次對 Segment 解鎖后，可能會有其他線程進入寫入操作。這樣就導致返回時的數量與實際數不一致。 不過這也能被接受，總不能因為為了統計元素停止所有元素的寫入操作 #### 性能問題 極端情況下所有寫入都落在同一個`Segment`中，這就導致`ConcurrentHashMap`退化成`SynchronizedMap`，共同搶一把鎖