今天看到一篇博客：jdk1.8的HashMap和ConcurrentHashMap，我想起了前段時間面試的一個問題：ConcurrentHashMap(JDK1.8)為什麽要使用synchronized而不是可重入鎖？

我想從下面幾個角度討論這個問題：

1. 鎖的粒度
   首先鎖的粒度並沒有變粗，甚至變得更細了。每當擴容一次，ConcurrentHashMap的並發度就擴大一倍。
2. Hash沖突
   JDK1.7中，ConcurrentHashMap從過二次hash的方式（Segment -> HashEntry）能夠快速的找到查找的元素。在1.8中通過鏈表加紅黑樹的形式彌補了put、get時的性能差距。
3. 擴容
   JDK1.8中，在ConcurrentHashmap進行擴容時，其他線程可以通過檢測數組中的節點決定是否對這條鏈表（紅黑樹）進行擴容，減小了擴容的粒度，提高了擴容的效率。

下面是我對面試中的那個問題的一下看法：

為什麽是synchronized，而不是可重入鎖
1. 減少內存開銷
假設使用可重入鎖來獲得同步支持，那麽每個節點都需要通過繼承AQS來獲得同步支持。但並不是每個節點都需要獲得同步支持的，只有鏈表的頭節點（紅黑樹的根節點）需要同步，這無疑帶來了巨大內存浪費。
2. 獲得JVM的支持
可重入鎖畢竟是API這個級別的，後續的性能優化空間很小。
synchronized則是JVM直接支持的，JVM能夠在運行時作出相應的優化措施：鎖粗化、鎖消除、鎖自旋等等。這就使得synchronized能夠隨著JDK版本的升級而不改動代碼的前提下獲得性能上的提升。

ConcurrentHashMap(JDK1.8)為什麽要放棄Segment