ConcurrentHashmap

重寫equals方法需同時重寫hashCode方法
object物件中的 public boolean equals(Object obj)，對於任何非空引用值 x 和 y，當且僅當 x 和 y 引用同一個物件時，此方法才返回 true；
注意：當此方法被重寫時，通常有必要重寫 hashCode 方法，以維護 hashCode 方法的常規協定，該協定宣告相等物件必須具有相等的雜湊碼。
如下：
(1)當obj1.equals(obj2)為true時，obj1.hashCode() == obj2.hashCode()必須為true
(2)當obj1.hashCode() == obj2.hashCode()為false時，obj1.equals(obj2)必須為false

如果不重寫equals，那麼比較的將是物件的引用是否指向同一塊記憶體地址，重寫之後目的是為了比較兩個物件的value值是否相等。特別指出利用equals比較八大包裝物件（如int，float等）和String類（因為該類已重寫了equals和hashcode方法）物件時，預設比較的是值，在比較其它自定義物件時都是比較的引用地址

hashcode是用於雜湊資料的快速存取，如利用HashSet/HashMap/Hashtable類來儲存資料時，都是根據儲存物件的hashcode值來進行判斷是否相同的。

這樣如果我們對一個物件重寫了euqals，意思是隻要物件的成員變數值都相等那麼euqals就等於true，但不重寫hashcode，那麼我們再new一個新的物件，當原物件.equals（新物件）等於true時，兩者的hashcode卻是不一樣的，由此將產生了理解的不一致，如在儲存雜湊集合時（如Set類），將會儲存了兩個值一樣的物件，導致混淆，因此，就也需要重寫hashcode()

比如，hashmap中，put一個新的物件，當原物件.equals（新物件）等於true時，兩者的hashcode卻是不一樣的，如果不重寫hashcode，put操作會put到兩個桶，get操作會歧義

原理分析

HashMap是非synchronized，執行緒不安全，
而Hashtable是執行緒安全的,對table加鎖;
conCurrentHashmap:對桶加鎖，保證執行緒安全的。

JDK6,7中的ConcurrentHashmap主要使用Segment來實現減小鎖粒度，把HashMap分割成若干個Segment，在put的時候需要鎖住Segment，get時候不加鎖，使用volatile來保證可見性，當要統計全域性時（比如size），首先會嘗試多次計算modcount來確定，這幾次嘗試中，是否有其他執行緒進行了修改操作，如果沒有，則直接返回size。如果有，則需要依次鎖住所有的Segment來計算。

jdk7中ConcurrentHashmap中，當長度過長碰撞會很頻繁，連結串列的增改刪查操作都會消耗很長的時間，影響效能,

所以 JDK8 中完全重寫了concurrentHashmap,程式碼量從原來的1000多行變成了 6000多 行，實現上也和原來的分段式儲存有很大的區別。

主要設計上的變化有以下幾點:
1 、不採用segment而採用node，鎖住node來實現減小鎖粒度。(桶鎖？)
2 、設計了MOVED狀態 當resize的中過程中 執行緒2還在put資料，執行緒2會幫助resize。
3 、使用3個CAS操作來確保node的一些操作的原子性，這種方式代替了鎖。
4、 sizeCtl的不同值來代表不同含義，起到了控制的作用。

至於為什麼JDK8中使用synchronized而不是ReentrantLock，我猜是因為JDK8中對synchronized有了足夠的優化吧。