一个ConcurrentModificationException的原因分析

在迭代List时，如果不通过iterator去修改list，那么将得到ConcurrentModificationException。

所以一般自己写的代码都会尽力避免这样的事情。但如果迭代和修改被分布在不同类的方法里，那么问题就很隐蔽了。

有一个同事写了一段这样的代码：

拿到一个大的List，然后按照给定的大小拆分成多个小的list，再清空原有的list，然后循环多个小的list。

这货自己能产生ConcurrentModificationException吗？普通的实现下，肯定不会有问题。

但是悲剧还是出现了。

sliceList的实现导致代码段1出现ConcurrentModificationException。

原因：sliceList方法调用了list.subList，[b][color=red]subList其实不过是原有somelist的视图[/color][/b]，但是subList保存了somelist的modCount（修改操作的数量）。

在代码段1中，

sliceList方法之后clear方法被调用了，导致someList的modCount发生了变化。

在随后的“迭代subList进行其他处理”中，subList将被迭代，而subList不过是somelist的视图，它持有someList的modcount。

迭代subList时，迭代器的next方法将被调用，而next的第一步就是checkForComodification()，它检查someList的modCount是否与自身持有的modCount，很显然因为视图中记录了modCount之后，代码段1中clear操作已经将modCount增加了，所以不相等。

再来捋一捋：

1、sliceList方法先执行，其中的subList方法返回了someList的视图，视图记录了someList的modCount。具体参考SubList的构造方法。

2、clear方法被执行，modCount加1；

3、“迭代subList进行其他处理”开始执行，开始遍历subList方法返回的视图，该视图的next方法把自己持有的宝贝modCount与someList的modCount进行了比较。发现了不一致，抛出异常。具体参考AbstractList中Itr的next方法

综上，sliceList的实现是一个悲剧。它的实现埋下了一个隐秘的大坑。其实，在代码段2中只要subList替换成一个new一个list即可避免这样的问题。具体实现很简单。

List的具体实现可参考：AbstractList的方法subList和内部类SubList。