前言:一次帮同事调bug的经历,同事开发了一个批量上传的模块,一次性传入很多数据,上传到另外一个系统。结果发现上传了100条数据,最终上传到另外一个系统的数据总是小于100条。看后台日志还没有报错,奇怪了。不报错,那就看日志上到底有没有传相应的数据吧,结果拿相应的数据去搜索,发现找不到。也就断定是程序哪里把数据弄丢了。直接就是看他写的代码。
他的思路:首先是将所有数据放在了list中,然而他还想用这个list做其他操作,他就使用了sublist做数据截取获取他想要的数据,这里是没有问题的,但是代码的最后他使用了clear方法清除数据(问题就是出在这里了)【他的初衷是这个截取的list用完了,需要制空,好垃圾回收,想法是好的】。看过sublist源码的肯定知道了为什么会这样。这里先举个例子:
clear后,原始数据中的数据也被清除了。这里就要看下sublist的源码了。
从源码中可以看得出sublist中有个this,这个this就是调用sublist方法的对象,之后直接将this对象引用到新的子视图的list,这里也就证明我在对子视图的list做操作时,this也会随之改变。(我的同事就是这里入坑,因为他认为是一个全新的list)。
除了上面这点,还有一个很大的坑,当你对原list做结构性修改时,你再去获取子list会抛出ConcurrentModificationException异常。
也就是说如果你在调用了sublist返回了子list之后,如果修改了原list的大小,那么之前产生的子list将会失效,变得不可使用。
总结:
- 使用sublist一定要注意它会影响原list的数据(无论你是添加,删除)
- 在你使用sublist之后,一定不要对原list进行结构性操作(如添加,删除),否则会造成之前sublist产生的子list失效。