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

同步容器

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

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

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

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

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

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

并發容器

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

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

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

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

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

總結

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

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

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

總結

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

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