1700444410
1700444411
System.out.println（“原列表长度：”+list.size（））；
1700444412
1700444413
System.out.println（“子列表长度：”+subList.size（））；
1700444414
1700444415
}
1700444416
1700444417
程序中有一个原始列表，生成了一个子列表，然后在原始列表中增加一个元素，最后打印出原始列表和子列表的长度，大家想一下，这段程序什么地方会出现错误呢？
1700444418
1700444419
list. add（“D”）会报错吗？不会，subList并没有锁定原列表，原列表当然可以继续修改。
1700444420
1700444421
难道有两个size方法？正确，确实是size方法出错了，输出结果如下：
1700444422
1700444423
原列表长度：4
1700444424
1700444425
Exception in thread”main”java.util.ConcurrentModifcationException
1700444426
1700444427
at java.util.SubList.checkForComodification（AbstractList.java：752）
1700444428
1700444429
at java.util.SubList.size（AbstractList.java：625）
1700444430
1700444431
什么？居然是subList的size方法出现了异常，而且还是并发修改异常？这没道理呀，这里根本就没有多线程操作，何来并发修改呢？这个问题很容易回答，那是因为subList取出的列表是原列表的一个视图，原数据集（代码中的list变量）修改了，但是subList取出的子列表不会重新生成一个新列表（这点与数据库视图是不相同的），后面在对子列表继续操作时，就会检测到修改计数器与预期的不相同，于是就抛出了并发修改异常。
1700444432
1700444433
出现这个问题的最终原因还是在子列表提供的size方法的检查上，还记得上面几个例子中经常提到的修改计数器吗？原因就在这里，我们来看看size的源代码：
1700444434
1700444435
public int size（）{
1700444436
1700444437
checkForComodifcation（）；
1700444438
1700444439
return size；
1700444440
1700444441
}
1700444442
1700444443
其中的checkForComodification方法就是用于检测是否并发修改的，代码如下：
1700444444
1700444445
private void checkForComodification（）{
1700444446
1700444447
//判断当前修改计数器是否与子列表生成时一致
1700444448
1700444449
if（l.modCount！=expectedModCount）
1700444450
1700444451
throw new ConcurrentModificationException（）；
1700444452
1700444453
}
1700444454
1700444455
expectedModCount是从什么地方来的呢？它是在SubList子列表的构造函数中赋值的，其值等于生成子列表时的修改次数（modCount变量）。因此在生成子列表后再修改原始列表，l.modCount的值就必然比expectedModCount大1，不再保持相等了，于是也就抛出了ConcurrentModificationException异常。
1700444456
1700444457
subList的其他方法也会检测修改计数器，例如set、get、add等方法，若生成子列表后，再修改原列表，这些方法也会抛出ConcurrentModificationException异常。
1700444458
1700444459
对于子列表操作，因为视图是动态生成的，生成子列表后再操作原列表，必然会导致“视图”的不稳定，最有效的办法就是通过Collections.unmodifiableList方法设置列表为只读状态，代码如下：
[
上一页 ]
[ :1.70044441e+09 ]
[
下一页 ]