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！