JUC - CopyOnWriteArrayList

    在你的应用中有一个列表（List），它被频繁的遍历，但是很少被修改。像“你的主页上的前十个分类，它被频繁的访问，但是每个小时通过Quartz的Job来调度更新”。如果你使用ArrayList来作为该列表的数据结构并且不使用同步（synchronization），你可能会遇到ConcurrentModificationException，因为在你使用Quartz的Job修改该列表时，其他的代码可能正在遍历该列表。

有些开发人员可能使用Vector或Collections.synchronizedList(List)的方式来解决该问题。但是这并没有效果!虽然在列表上add(),remove()和get()方法现在对线程是安全的，但遍历时仍然会抛出ConcurrentModificationException！在你遍历在列表时，你需要在该列表上使用同步，同时，在使用Quartz修改它时，也需要使用同步机制。这对性能和可扩展性来说是一个噩梦。同步需要在所有的地方出现，仅仅是因为每个小时都需要做更新。

除了加锁外，其实还有一种方式可以防止并发修改异常，这就是将读写分离技术（不是数据库上的）。先回顾一下一个常识：

1、JAVA中“=”操作只是将引用和某个对象关联，假如同时有一个线程将引用指向另外一个对象，一个线程获取这个引用指向的对象，那么他们之间不会发生ConcurrentModificationException，他们是在虚拟机层面阻塞的，而且速度非常快，几乎不需要CPU时间。

2、JAVA中两个不同的引用指向同一个对象，当第一个引用指向另外一个对象时，第二个引用还将保持原来的对象。

基于上面这个常识，我们再来探讨下面这个问题： 在CopyOnWriteArrayList里处理写操作（包括add、remove、set等）是先将原始的数据通过JDK1.6的Arrays.copyof()来生成一份新的数组然后在新的数据对象上进行写，写完后再将原来的引用指向到当前这个数据对象（这里应用了常识1），这样保证了每次写都是在新的对象上（因为要保证写的一致性，这里要对各种写操作要加一把锁，JDK1.6在这里用了重入锁），然后读的时候就是在引用的当前对象上进行读（包括get，iterator等），不存在加锁和阻塞，针对iterator使用了一个叫COWIterator的阉割版迭代器，因为不支持写操作，当获取CopyOnWriteArrayList的迭代器时，是将迭代器里的数据引用指向当前引用指向的数据对象，无论未来发生什么写操作，都不会再更改迭代器里的数据对象引用，所以迭代器也很安全（这里应用了常识2）。

CopyOnWriteArrayList中写操作需要大面积复制数组，所以性能肯定很差，但是读操作因为操作的对象和写操作不是同一个对象，读之间也不需要加锁，读和写之间的同步处理只是在写完后通过一个简单的“=”将引用指向新的数组对象上来，这个几乎不需要时间，这样读操作就很快很安全，适合在多线程里使用，绝对不会发生ConcurrentModificationException，所以最后得出结论：CopyOnWriteArrayList适合使用在读操作远远大于写操作的场景里，比如缓存。

CopyOnWrite容器有很多优点，但是同时也存在两个问题：

1. 内存占用问题。因为CopyOnWrite的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新写入的对象（注意:在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存）。如果这些对象占用的内存比较大，比如说200M左右，那么再写入100M数据进去，内存就会占用300M，那么这个时候很有可能造成频繁的Yong GC和Full GC。之前我们系统中使用了一个服务由于每晚使用CopyOnWrite机制更新大对象，造成了每晚15秒的Full GC，应用响应时间也随之变长。

2. 数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。