語言是會隨著時代的發(fā)展而發(fā)展的，而Vector與Hashtable又是如何隨著Java的發(fā)展而不再使用的呢？

同步容器

在Java發(fā)展的早期就在支持多線程了，也提供了一些線程安全的容器，比如在最早jdk1.2提供的集合容器類比如Vector、Hashtable，他們的實現機制都差不多，都是在方法層面上加synchronized關鍵字來實現線程安全。

在早期jdk還提供了Collections.synchronizedXxx系列方法來創(chuàng)建同步容器，具體如下圖：

這幾個方法的實現方式都差不多，都是把集合對象作為參數設置進一個新對象里，然后將傳遞進去的集合作為新建對象的屬性封裝起來，最后通過訪問新建對象的方法(通過synchronized實現同步)去訪問傳遞進去的集合。

這類通過鎖實現同步的叫著同步容器，同步容器對于他自身來說是線程安全的，但是我們在進行一些復合操作的時候就可能并不是線程安全的了，比如"int size = vector.size(); vector.remove(size);"這類操作，在多線程情況下如果也有get最后一個元素，就很容易出現異常。

在比如"for (int i = 0; i < vector.size(); i++)"雖然vector是線程安全的，但是可以能在遍歷的過程中其他線程對vector進行了操作，比如移除了最后一個，那么這個遍歷就會出現異常。

那么要解決這類復合操作就必須額外加鎖去控制。同步容器是通過把所有對容器的狀態(tài)訪問都通過加鎖來實現串行化訪問，最終實現容器的線程安全，這種方式的缺點就是嚴重降低了容器的并發(fā)性，在多線程競爭容器的鎖時就會嚴重影響程序的性能。

并發(fā)容器

在jdk1.5開始提供了多種并發(fā)容器用來改進同步容器的性能，并發(fā)容器是針對多個線程并發(fā)訪問設計，常見的比如ConcurrentHashMap來代替同步的Map系列，CopyOnWriteArrayList來代替同步的List系列，CopyOnWriteArraySet來代替同步的Set系列，這些并發(fā)容器還提供了一些復合操作，比如"沒有則添加"、替換、刪除；

先來簡單看下并發(fā)容器是如何優(yōu)化的，以ConcurrentHashMap為例，要想了解ConcurrentHashMap是如何優(yōu)化的就必須先了解他的數據結構，在jdk8以前與hashtable這里畫了一個簡單的對比圖，如下圖：

hashtable底層是一個數組結構，數組每個元素又是一個鏈表結構，每次訪問hashtable方法都會針對hashtable這個對象加鎖，一次只能一個線程訪問，而在ConcurrentHashMap把數據分成了多個Segment數組，在每個Segment中在保存一個HashEntry數組，HashEntry數組中元素又是一個鏈表結構，每次訪問都是訪問某個Segment元素下的數據，每次只針對對應的Segment加鎖，也就是ConcurrentHashMap下有多少個Segment那么他就最多支持同時多少個線程訪問。

在jdk8對ConcurrentHashMap進一步進行了優(yōu)化，它的真正結構已經和hashmap差不多了，而且是針對每個node進行加鎖，可以支持更高的并發(fā)，底層數組有多長就最多支持多大的并發(fā)。

同時ConcurrentHashMap還支持了一些復合操作，比如putIfAbsent、remove(Object key, Object value)(存在才刪除)這類的更加安全的方法。

總結

經常看到一些資料在說Vector與Hashtable這類的不要使用，而是應該使用這樣那樣的容器，雖然知道是因為他們的實現機制不夠好的原因，卻很少知道是因為歷史發(fā)展原因，出現了更加優(yōu)化的容器。

在最開始只考慮到多線程的安全問題，所以實現了一堆同步容器，知道多線程、高并發(fā)越來越多，同步容器的性能影響了整體性能，所以才有了并發(fā)容器的發(fā)展。

Java程序員日常學習筆記，如理解有誤歡迎各位交流討論！

總結

以上是生活随笔為你收集整理的c++vector替换元素_从发展来看Vector与Hashtable的淘汰的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。