最近在生产上,需要用多线程去处理大量的数据,这个数据在一个list里面,为了避免多个线程拉取同一个list造成多次读写,避免资源同步的问题。决定将数据分割,然后就想到了subList(int from,int to)这个方法。但是发现subList 没有根据for循环的位置进行更新,在此对subList方法进行梳理以及记录。
List接口中有subList(int fromIndex, int toIndex)方法,这个方法返回实现了List接口的SubList的实例,而非当前同类型的实例。Sublist可以简单理解是子List,这个SubList是在AbstractList中定义的,因此只能是包内可见,我们在外面没办法直接访问
它返回原来list的从[fromIndex, toIndex)之间这一部分的视图,之所以说是视图,是因为实际上,返回的list是靠原来的list支持的。所以,你对原来的list和返回的list做的“非结构性修改”(non-structural changes),都会影响到彼此对方。所谓的“非结构性修改”,是指不涉及到list的大小改变的修改。相反,结构性修改,指改变了list大小的修改。
那么,如果涉及到结构性修改会怎么样呢?
如果发生结构性修改的是返回的子list,那么原来的list的大小也会发生变化;而如果发生结构性修改的是原来的list(不包括由于返回的子list导致的改变),那么返回的子list语义上将会是undefined。在AbstractList(ArrayList的父类)中,undefined的具体表现形式是抛出一个ConcurrentModificationException。因此,如果你在调用了sublist返回了子list之后,如果修改了原list的大小,那么之前产生的子list将会失效,变得不可使用。
如果你对一个 List 进行过 subList() 的操作之后,
1. 千万不要再对原 List 进行任何改动的操作(例如: 增删改), 查询和遍历倒是可以. 因为如果对原 List 进行了改动, 那么后续只要是涉及到子 List 的操作就一定会出问题. 而至于会出现什么问题呢? 具体来说就是:
(1) 如果是对原 List 进行修改 (即: 调用 set() 方法) 而不是增删, 那么子 List 的元素也可能会被修改 (这种情况下不会抛出并发修改异常).
(2) 如果是对原 List 进行增删, 那么此后只要操作了子 List , 就一定会抛出并发修改异常.
2. 千万不要直接对子 List 进行任何改动的操作(例如: 增删改), 但是查询和间接改动倒是可以. 不要对子 List 进行直接改动, 是因为如果在对子 List 进行直接改动之前, 原 List 已经被改动过, 那么此后在对子 List 进行直接改动的时候就会抛出并发修改异常.
如果想要实现String.split的效果,争取的截取List的subList ,需要按照如下的方法:
List sub=one.subList(...);
List two=new XxxList(sub);
sub.clear();
————————————————
参考链接:https://blog.csdn.net/clevergump/article/details/51105235
本文转载自: https://blog.csdn.net/u012429005/article/details/120287947
版权归原作者 ranjinghang 所有, 如有侵权,请联系我们删除。
版权归原作者 ranjinghang 所有, 如有侵权,请联系我们删除。