同步集合可以簡單地理解為通過synchronized來實現同步的集合。如果有多個執行緒呼叫同步集合的方法，它們將會序列執行。

arrayList和vector、stack

• Vector是執行緒安全的，原始碼中有很多的synchronized可以看出，而ArrayList不是。導致Vector效率無法和ArrayList相比
• ArrayList和Vector都採用線性連續儲存空間，當儲存空間不足的時候，ArrayList預設增加為原來的50%，Vector預設增加為原來的一倍
• Vector可以設定capacityIncrement，而ArrayList不可以，從字面理解就是capacity容量，Increment增加，容量增長的引數
• Stack是繼承於Vector，基於動態陣列實現的一個執行緒安全的棧
• arrayList、vector、Stack的共性特點：隨機訪問速度快，插入和移除效能較差(這是陣列的特點，三者的底層均為陣列實現)

HashMap和Hashtable

• HashMap是非synchronized的，而Hashtable是synchronized的。這說明Hashtable是執行緒安全的，而且多個執行緒可以共享一個Hashtable
• 由於Hashtable是執行緒安全的，也是synchronized的，所以在單執行緒環境下比HashMap要慢
• HashMap可以存在null的鍵值(key)和值(value), 但是Hashtable是不可以的

Collections

Collections是為集合提供各種方便操作的工具類，通過它，可以實現集合排序、查詢、替換、同步控制、設定不可變集合

Collections.synchronizedCollection(Collection<T>t)
Collections.synchronizedList(List<T>list)
Collections.synchronizedMap(Map<K, V>map)
Collections.synchronizedSet(Set<T> t)

上面幾個方法是Collections工具類將集合變為同步集合，從而解決集合的執行緒安全問題.

同步集合在單執行緒的環境下能夠保證執行緒安全，但是通過synchronized同步方法將訪問操作序列化，導致併發環境下效率低下。而且同步集合在多執行緒環境下的複合操作（迭代、條件運算如沒有則新增等）是非執行緒安全，需要客戶端程式碼來實現加鎖。

併發集合是jdk5.0重要的特性，增加了併發包java.util.concurrent.*。Java記憶體模型、volatile變數及AbstractQueuedSynchronizer(簡稱AQS同步器)，是併發包眾多實現的基礎。

常見的併發集合：

• ConcurrentHashMap：執行緒安全的HashMap的實現
• CopyOnWriteArrayList：執行緒安全且在讀操作時無鎖的ArrayList
• CopyOnWriteArraySet：基於CopyOnWriteArrayList，不新增重複元素
• ArrayBlockingQueue：基於陣列、先進先出、執行緒安全，可實現指定時間的阻塞讀寫，並且容量可以限制
• LinkedBlockingQueue：基於連結串列實現，讀寫各用一把鎖，在高併發讀寫操作都多的情況下，效能優於ArrayBlockingQueue

CopyOnWrite集合即寫時複製的集合

通俗的理解是當我們往一個集合新增元素的時候，不直接往當前集合新增，而是先將當前集合進行Copy，複製出一個新的集合，然後新的集合裡新增元素，新增完元素之後，再將原集合的引用指向新的集合。這樣做的好處是我們可以對CopyOnWrite集合進行併發的讀，而不需要加鎖，因為當前集合不會新增任何元素。所以CopyOnWrite集合也是一種讀寫分離的思想，讀和寫不同的集合。

CopyOnWrite的應用場景

CopyOnWrite併發容器用於讀多寫少的併發場景。比如白名單，黑名單，商品類目的訪問和更新場景，假如我們有一個搜尋網站，使用者在這個網站的搜尋框中，輸入關鍵字搜尋內容，但是某些關鍵字不允許被搜尋。這些不能被搜尋的關鍵字會被放在一個黑名單當中，黑名單每天晚上更新一次。當用戶搜尋時，會檢查當前關鍵字在不在黑名單當中，如果在，則提示不能搜尋。

示例程式碼

package com.ifeve.book;  

import java.util.Map;  
import com.ifeve.book.forkjoin.CopyOnWriteMap;  

/** 
 * 黑名單服務 
 * 
 * @author fangtengfei 
 * 
 */  
public class BlackListServiceImpl {  

    private static CopyOnWriteMap<String, Boolean> blackListMap = new CopyOnWriteMap<String, Boolean>(  
            1000);  

    public static boolean isBlackList(String id) {  
        return blackListMap.get(id) == null ? false : true;  
    }  

    public static void addBlackList(String id) {  
        blackListMap.put(id, Boolean.TRUE);  
    }  

    /** 
     * 批量新增黑名單 
     * 
     * @param ids 
     */  
    public static void addBlackList(Map<String,Boolean> ids) {  
        blackListMap.putAll(ids);  
    }  
}  

注意兩點：

• 減少擴容開銷。根據實際需要，初始化CopyOnWriteMap的大小，避免寫時CopyOnWriteMap擴容的開銷。
• 使用批量新增。因為每次新增，容器每次都會進行復制，所以減少新增次數，可以減少容器的複製次數。如使用上面程式碼裡的addBlackList方法。

CopyOnWrite的缺點

記憶體佔用問題

因為CopyOnWrite的寫時複製機制，所以在進行寫操作的時候，記憶體裡會同時駐紮兩個物件的記憶體，舊的物件和新寫入的物件（注意:在複製的時候只是複製容器裡的引用，只是在寫的時候會建立新物件新增到新容器裡，而舊容器的物件還在使用，所以有兩份物件記憶體）。如果這些物件佔用的記憶體比較大，比如說200M左右，那麼再寫入100M資料進去，記憶體就會佔用300M，那麼這個時候很有可能造成頻繁的Yong GC和Full GC。之前我們系統中使用了一個服務由於每晚使用CopyOnWrite機制更新大物件，造成了每晚15秒的Full GC，應用響應時間也隨之變長。

針對記憶體佔用問題，可以通過壓縮容器中的元素的方法來減少大物件的記憶體消耗，比如，如果元素全是10進位制的數字，可以考慮把它壓縮成36進位制或64進位制。或者不使用CopyOnWrite容器，而使用其他的併發容器，如ConcurrentHashMap。

資料一致性問題

CopyOnWrite容器只能保證資料的最終一致性，不能保證資料的實時一致性。所以如果你希望寫入的的資料，馬上能讀到，請不要使用CopyOnWrite容器。