隊列先進先出，棧先進后出。

　　遍歷數據速度不同。

　　棧只能從頭部取數據 也就最先放入的需要遍歷整個棧最后才能取出來，而且在遍歷數據的時候還得為數據開辟臨時空間，保持數據在遍歷前的一致性;

　　隊列則不同，他基于地址指針進行遍歷，而且可以從頭或尾部開始遍歷，但不能同時遍歷，無需開辟臨時空間，因為在遍歷的過程中不影像數據結構，速度要快的多。

　　Java8開始ConcurrentHashMap,為什么舍棄分段鎖?

　　ConcurrentHashMap的原理是引用了內部的 Segment ( ReentrantLock ) 分段鎖，保證在操作不同段 map 的時候， 可以并發執行， 操作同段 map 的時候，進行鎖的競爭和等待。從而達到線程安全， 且效率大于 synchronized。

　　但是在 Java 8 之后， JDK 卻棄用了這個策略，重新使用了 synchronized+CAS。

　　棄用原因:

　　通過 JDK 的源碼和官方文檔看來， 他們認為的棄用分段鎖的原因由以下幾點：

　　加入多個分段鎖浪費內存空間;

　　生產環境中， map 在放入時競爭同一個鎖的概率非常小，分段鎖反而會造成更新等操作的長時間等待;

　　為了提高 GC 的效率;

　　提供了新的同步方案：既然棄用了分段鎖， 那么一定由新的線程安全方案， 我們來看看源碼是怎么解決線程安全的呢?(源碼保留了segment 代碼， 但并沒有使用)。

　　ConcurrentHashMap(JDK1.8)為什么要使用synchronized而不是如ReentranLock這樣的可重入鎖?

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

　　1. 鎖的粒度

　　首先鎖的粒度并沒有變粗，甚至變得更細了。每當擴容一次，ConcurrentHashMap的并發度就擴大一倍。

　　2. Hash沖突

　　JDK1.7中，ConcurrentHashMap從過二次hash的方式(Segment -> HashEntry)能夠快速的找到查找的元素。在1.8中通過鏈表加紅黑樹的形式彌補了put、get時的性能差距。

　　JDK1.8中，在ConcurrentHashmap進行擴容時，其他線程可以通過檢測數組中的節點決定是否對這條鏈表(紅黑樹)進行擴容，減小了擴容的粒度，提高了擴容的效率。

　　下面是我對那個面試問題的一些看法，即為什么是synchronized，而不是ReentranLock?

　　1. 減少內存開銷

　　假設使用可重入鎖來獲得同步支持，那么每個節點都需要通過繼承AQS來獲得同步支持。但并不是每個節點都需要獲得同步支持的，只有鏈表的頭節點(紅黑樹的根節點)需要同步，這無疑帶來了巨大內存浪費。

　　2. 獲得JVM的支持

　　可重入鎖畢竟是API這個級別的，后續的性能優化空間很小。

　　synchronized則是JVM直接支持的，JVM能夠在運行時作出相應的優化措施：鎖粗化、鎖消除、鎖自旋等等。這就使得synchronized能夠隨著JDK版本的升級而不改動代碼的前提下獲得性能上的提升。

　　更多關于“Java培訓”的問題，歡迎咨詢千鋒教育在線名師。千鋒已有十余年的培訓經驗，課程大綱更科學更專業，有針對零基礎的就業班，有針對想提升技術的好程序員班，高品質課程助力你實現java程序員夢想。