由于之前在弄 eventbus的源码分析时,源码中有用到CopyOnWriteArray 由于时间问题,知道现在才做了一个相应的整理:
---------------------------------------------------------做一枚健康的小码畜--------------------------------------------------
CopyOnWriteArrayList是ArrayList 的一个线程安全的变体(ArrayList不是线程安全的哦)，其中所有可变操作（add、set等等）都是通过对底层数组进行一次新的复制来实现的。
在源码中可以看到:
1 public CopyOnWriteArrayList(Collection<? extends E> c) {
2 Object[] elements = c.toArray();
3 // c.toArray might (incorrectly) not return Object[] (see 6260652)
4 if (elements.getClass() != Object[].class) //这里是copyof,
5 elements = Arrays.copyOf(elements, elements.length, Object[].class);
6 setArray(elements);
7 }
CopyOnWriteArrayList 其实是做了一份拷贝,所以一般需要很大的开销，在android中不建议将context或者activity放到CopyOnWriteArrayList中
尽管需要很大的开销，但是当遍历操作的数量大大超过可变操作的数量时，这种方法可能比其他替代方法更 有效。在不能或不想进行同步遍历，但又需要从并发线程中排除冲突时，它也很有用。“快照”风格的迭代器方法在创建迭代器时使用了对数组状态的引用。此数组在迭代器的生存期内不会更改，因此不可能发生冲突，并且迭代器保证不会抛出ConcurrentModificationException。创建迭代器以后，迭代器就不会反映列表的添加、移除或者更改。在迭代器上进行的元素更改操作（remove、set和add）不受支持。这些方法将抛出UnsupportedOperationException。允许使用所有元素，包括null。
在CopyOnWriteArrayList里处理写操作（包括add、remove、set等）是先将原始的数据通过JDK1.6的Arrays.copyof()来生成一份新的数组
然后在新的数据对象上进行写，写完后再将原来的引用指向到当前这个数据对象，这样保证了每次写都是在新的对象上（因为要保证写的一致性，这里要对各种写操作要加一把锁，JDK1.6在这里用了重入锁），
然后读的时候就是在引用的当前对象上进行读（包括get，iterator等），不存在加锁和阻塞，针对iterator使用了一个叫 COWIterator的阉割版迭代器，因为不支持写操作，当获取CopyOnWriteArrayList的迭代器时，是将迭代器里的数据引用指向当前 引用指向的数据对象，无论未来发生什么写操作，都不会再更改迭代器里的数据对象引用，所以迭代器也很安全。
CopyOnWriteArrayList中写操作需要大面积复制数组，所以性能肯定很差，但是读操作因为操作的对象和写操作不是同一个对象，读之 间也不需要加锁，读和写之间的同步处理只是在写完后通过一个简单的“=”将引用指向新的数组对象上来，这个几乎不需要时间，这样读操作就很快很安全，适合 在多线程里使用，绝对不会发生ConcurrentModificationException ，所以最后得出结论：CopyOnWriteArrayList适合使用在读操作远远大于写操作的场景里，比如缓存。
内存一致性效果：当存在其他并发 collection 时，将对象放入CopyOnWriteArrayList之前的线程中的操作 happen-before 随后通过另一线程从CopyOnWriteArrayList中访问或移除该元素的操作。
这种情况一般在多线程操作时，一个线程对list进行修改。一个线程对list进行fore时会出现java.util.ConcurrentModificationException错误。
比如：两个线程一个线程fore一个线程修改list的值。