CopyOnWriteArrayList 簡介

除了加鎖外，其實還有一種方式能夠防止併發修改異常，這就是將讀寫分離技術（不是數據庫上的）。

先回顧一下一個常識：

一、JAVA中「=」操做只是將引用和某個對象關聯，假如同時有一個線程將引用指向另一個對象，一個線程獲取這個引用指向的對象，那麼他們之間不會發生ConcurrentModificationException，他們是在虛擬機層面阻塞的，並且速度很是快，幾乎不須要CPU時間。

二、JAVA中兩個不一樣的引用指向同一個對象，當第一個引用指向另一個對象時，第二個引用還將保持原來的對象。

 

基於上面這個常識，咱們再來探討下面這個問題：

在CopyOnWriteArrayList裏處理寫操做（包括add、remove、set等）是先將原始的數據經過JDK1.6的Arrays.copyof()來生成一份新的數組

而後在新的數據對象上進行寫，寫完後再將原來的引用指向到當前這個數據對象（這裏應用了常識1），這樣保證了每次寫都是在新的對象上（由於要保證寫的一致性，這裏要對各類寫操做要加一把鎖，JDK1.6在這裏用了重入鎖），

而後讀的時候就是在引用的當前對象上進行讀（包括get，iterator等），不存在加鎖和阻塞，針對iterator使用了一個叫 COWIterator的閹割版迭代器，由於不支持寫操做，當獲取CopyOnWriteArrayList的迭代器時，是將迭代器裏的數據引用指向當前 引用指向的數據對象，不管將來發生什麼寫操做，都不會再更改迭代器裏的數據對象引用，因此迭代器也很安全（這裏應用了常識2）。

CopyOnWriteArrayList中寫操做須要大面積複製數組，因此性能確定不好，可是讀操做由於操做的對象和寫操做不是同一個對象，讀之 間也不須要加鎖，讀和寫之間的同步處理只是在寫完後經過一個簡單的「=」將引用指向新的數組對象上來，這個幾乎不須要時間，這樣讀操做就很快很安全，適合 在多線程裏使用，絕對不會發生ConcurrentModificationException，因此最後得出結論：CopyOnWriteArrayList適合使用在讀操做遠遠大於寫操做的場景裏，好比緩存。

 

 

 

 

 

   在你的應用中有一個列表（List），它被頻繁的遍歷，可是不多被修改。像「你的主頁上的前十個分類，它被頻繁的訪問，可是每一個小時經過Quartz的Job來調度更新」。

若是你使用ArrayList來做爲該列表的數據結構而且不使用同步（synchronization），你可能會遇到ConcurrentModificationException，由於在你使用Quartz的Job修改該列表時，其餘的代碼可能正在遍歷該列表。

 

    有些開發人員可能使用Vector或Collections.synchronizedList(List<T>)的方式來解決該問題。可是 這並無效果!雖然在列表上add(),remove()和get()方法如今對線程是安全的，但遍歷時仍然會拋出 ConcurrentModificationException！在你遍歷在列表時，你須要在該列表上使用同步，同時，在使用Quartz修改它時，也 須要使用同步機制。這對性能和可擴展性來講是一個噩夢。同步須要在全部的地方出現，僅僅是由於每一個小時都須要作更新。

 

     幸運的是，這裏有更好的解決方案。使用CopyOnWriteArrayList。

當列表上的一個結構修改發生時，一個新的拷貝（copy）就會被建立。這在常常發生修改的地方使用，將會很低效。遍歷該列表將不會出現ConcurrentModificationException，由於該列表在遍歷時將不會被作任何的修改。

另外一種避免添加同步代碼但能夠避免併發修改問題的方式是在調度任務中構建一個新的列表，而後將原來指向到列表上的引用賦值給新的列表。在JVM中，賦值一 個新的引用是原子操做。這種方式在使用舊的遍歷方式（for (int i=0; i<list.size(); i++) { … list.get(i) …}）時將無效（也會出錯）。切換的列表中的大小將引起新的錯誤產生。更加糟糕的是由於改變是在不一樣的線程中發生的，因此還會有不少潛在的問題。使用 volatile關鍵字可能會有所幫助，可是對列表大小的改變依然會有問題。

 

     內存一致性和剛發生後保證了CopyOnWriteArrayList的可用性。同時，代碼變得更簡單，由於根本不須要使用volatile關鍵字或同步。更少的代碼，更少的bug！