參考 ：http://www.importnew.com/28263.html
https://www.cnblogs.com/lijiasnong/p/9963808.html
其實可以看出JDK1.8版本的ConcurrentHashMap的數據結構已經接近HashMap，相對而言，ConcurrentHashMap只是增加了同步的操作來控制併發，從JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+紅黑樹,相對而言，總結如下思考
JDK1.8的實現降低鎖的粒度，JDK1.7版本鎖的粒度是基於Segment的，包含多個HashEntry，而JDK1.8鎖的粒度就是HashEntry（首節點）
JDK1.8版本的數據結構變得更加簡單，使得操作也更加清晰流暢，因爲已經使用synchronized來進行同步，所以不需要分段鎖的概念，也就不需要Segment這種數據結構了，由於粒度的降低，實現的複雜度也增加了
JDK1.8使用紅黑樹來優化鏈表，基於長度很長的鏈表的遍歷是一個很漫長的過程，而紅黑樹的遍歷效率是很快的，代替一定閾值的鏈表，這樣形成一個最佳拍檔
JDK1.8爲什麼使用內置鎖synchronized來代替重入鎖ReentrantLock，我覺得有以下幾點
因爲粒度降低了，在相對而言的低粒度加鎖方式，synchronized並不比ReentrantLock差，在粗粒度加鎖中ReentrantLock可能通過Condition來控制各個低粒度的邊界，更加的靈活，而在低粒度中，Condition的優勢就沒有了
JVM的開發團隊從來都沒有放棄synchronized，而且基於JVM的synchronized優化空間更大，使用內嵌的關鍵字比使用API更加自然
在大量的數據操作下，對於JVM的內存壓力，基於API的ReentrantLock會開銷更多的內存，雖然不是瓶頸，但是也是一個選擇依據